Mr. D

Виглядає так, що можлива ситуація, коли фізично ще буде можливість бути на зв'язку з точки зору потужності сигналу, але APs будуть вирішувати, що такого клієнта не будуть обслуговувати. Тобто фактично відбувається лімітування фізичних можливостей. Скажімо, телефон може бути десь в сумці або в кишені й тоді потужність сигналу зменшується. Можливий сценарій, коли один фізичний домен буде завантажений інші пристрої не зможуть використати інші AP, які знаходяться десь поряд. Мені здається контролер Ruckus також працює з таким сценарієм корегуючи потужність різних AP та пропонуючи окремим клієнтам перемкнутися на ті AP. Фактично знову ж маючи фізичний ресурс відбувається лімітування цього ресурсу. Увімкнув TP-Link під'єднав 10 Tuya IoT й ось з тих 10 Tuya на відстані до 10 метрів половина втрачає зв'язок періодично. Очевидно, все складніше. )

Якщо я правильно розумію, то індивідуальна зміна діаграми направленості для зв'язку з якимось окремим абонентом утворює ситуацію, коли в точці простору де знаходиться клієнт з'являється сигнал більшої потужності (за рахунок концентрації енергії в якомусь напрямку). В той час як під час приймання даних вимкнення непотрібних секторів зменшує шум від тих непотрібних секторів (одночасно збільшуючи gain антени приймача). Та й загалом MIMO та корегування діаграми направленості працюють одночасно. Або MIMO потребує саме omni-directional антену й буде менш ефективною у разі секторної антени?

Як саме відбувається балансування навантаження між AP в такій архітектурі? Скажімо, є 5 - 6 приміщень в кожному знаходяться якісь бездротові пристрої та відповідно є окрема AP в кожному приміщенні. До якої саме AP під'єднається клієнт спочатку? Що буде відбуватися, якщо бездротовий клієнт переміститься в інше приміщення? Буде виконано перемикання на іншу AP або ні? Якщо я правильно розумію, то швидкість бездротової мережі - це швидкість найповільнішого клієнта.

На хостах з цим питань немає, але зустрічались випадки з побутовим абонентським обладнанням. Скажімо, у когось є маршрутизатор, який повністю влаштовує, але WireGuard там не працює. Звісно, можливо змінити на інший пристрій, але тоді треба додатково виконати налаштування вже існуючих сервісів, хоча у разі якогось побутового використання таких налаштувань й не дуже багато. Загалом бачу, що nmap, дійсно, показує "open" у разі NTP або DNS (навіть може визначити тип сервісу) PORT STATE SERVICE VERSION 123/udp open ntp NTP v4 (secondary server) PORT STATE SERVICE VERSION 53/udp open domain (generic dns response: SERVFAIL) 1 service unrecognized despite returning data. If you know the service/version, please submit the following fingerprint at nmap.org/cgi-bin/submit.cgi?new-service : SF-Port53-UDP:V= Тобто "open" визначається\інтерпретується не у разі unusual відповідей

Особисто швидкість не вимірював, але бачу деяку кількість тестів, які це підтверджують. Але я не впевнений, що WireGuard існує для будь-якої архітектури, тому, можливо, в деяких ситуаціях можливі й не найкращі показники.

Можливо, також NTP, який здається за замовчуванням працює зі 123 портом

Завершуючи тему WireGuard та OpenVPN є ось ще така думка "...If you think about this 'stealth' result vs one that actively sends a 'reject' response, the more secure is the no-answer situation because it reveals nothing at all. You can compare it to answering the phone and saying "go away" vs not answering at all... if you answer, the caller knows that you're there, but if you don't answer at all, they have no idea if your number works at all..." forum.openwrt.org/t/increase-wireguard-security-udp-port-open-filtered-closed/113402/9 Тобто стан який nmap інтерпретує як "open|filtered" фактично, схоже, найбезпечніший. У той час, якщо сервер\маршрутизатор" надсилає відповідь у вигляді ICMP-пакету, що nmap вважає як "closed", можливо вважати як хтось відреагував на попередню операцію. Тому у разі WireGuard та OpenVPN (UDP) відбувається все однаково. Й, схоже, можливості зробити примусово так, щоб був надісланий пакет "ICMP port unreachable error (type 3, code 3)", якщо серверу (сервісу WireGuard або OpenVPN) не вдалося ідентифікувати\автентифікувати клієнта немає. Тому WireGuard не має ніякої переваги саме в цьому (відносно OpenVPN (UDP)).

Навіть Ви підтверджуєте, що на вулиці обговорюванні AP будуть працювати краще, ніж можливі аналоги

Нагадаю, що програма керування HDD працює з хостом в контексті LBA. HDD нічого не знає про те, яка саме файлова система використовується ОС або користувачем. Тому в деяких випадках користувач для портативних NAND'ів може застосувати спеціалізовані файлові системи, але все ще можливо використати традиційні файлові системи й на портативних NAND'ах.

Я звернув увагу, коли у Вас немає відповіді або Ви щось не знаєте, то відбувається знущання на 3 - 4 сторінки. Тому я не побачив того, про що Ви розказуєте на практиці. Що й де не вірно налаштовано? Я подивлюсь відповідні налаштування й ще раз протестую рішення.

Ваші знущання я переживу. Не бачу конкретної відповіді. Мій приклад показує, що ICMP працює, але все одно я отримую "ICMP port unreachable error (type 3, code 3) - closed" та відповідно бачу такий пакет в мережі.

Як раз я бачу різницю, а саме отримую очікувано "open|filtered" або "closed". Тому роблю висновок, що наявність чогось видно (WireGuard, OpenVPN або щось інше).

Тобто Ви вважаєте налаштування за замовчуванням Ubuntu Linux "кривими"? [administrator@localhost ~]$ ping -c 1 172.160.14.186 PING 172.16.4.186 (172.160.14.186) 56(84) bytes of data. 64 bytes from 172.160.14.186: icmp_seq=1 ttl=64 time=0.482 ms --- 172.16.4.186 ping statistics --- 1 packets transmitted, 1 received, 0% packet loss, time 0ms rtt min/avg/max/mdev = 0.482/0.482/0.482/0.000 ms [administrator@localhost ~]$ sudo nmap -sU -v 172.160.14.186 -p 25003 Starting Nmap 7.92 ( nmap.org ) at 2024-01-05 14:04 EET Initiating ARP Ping Scan at 14:04 Scanning 172.160.14.186 [1 port] Completed ARP Ping Scan at 14:04, 0.03s elapsed (1 total hosts) Initiating Parallel DNS resolution of 1 host. at 14:04 Completed Parallel DNS resolution of 1 host. at 14:04, 0.02s elapsed Initiating UDP Scan at 14:04 Scanning 172.160.14.186 [1 port] Completed UDP Scan at 14:04, 0.00s elapsed (1 total ports) Nmap scan report for 172.16.4.186 Host is up (0.00042s latency). PORT STATE SERVICE 25003/udp closed icl-twobase4 MAC Address: 08:08:08:08:08:E8 (Oracle NIC) Read data files from: /usr/bin/../share/nmap Nmap done: 1 IP address (1 host up) scanned in 0.16 seconds Raw packets sent: 2 (56B) | Rcvd: 2 (84B)

Тобто nmap має можливість відрізнити OpenVPN від WireGuard або ні?

Все що мені цікаво, я побачив, а саме nmap ідентифікує UDP-порт WireGuard та UDP-порт OpenVPN однаково, як "open|filtered" та ні WireGuard, ні OpenVPN не надсилає ніяких відповідей. У той час як UDP-порт, який ніхто не використовує ідентифікується як "closed". Тому будь-яке маскування WireGuard працює також як й з OpenVPN. Й ось щоб отримати інтерпретацію "closed" треба отримати "ICMP port unreachable error (type 3, code 3)" й, можливо, такі налаштування існують для firewall'ів.

Загалом мова була ось про ці визначення "...Table 5.3. How Nmap interprets responses to a UDP probe Probe ResponseAssigned State Any UDP response from target port (unusual) - open No response received (even after retransmissions) - open|filtered ICMP port unreachable error (type 3, code 3) - closed Other ICMP unreachable errors (type 3, code 1, 2, 9, 10, or 13) - filtered..." nmap.org/book/scan-methods-udp-scan.html Й саме про ці інтерпретування "open" або "open|filtered" і йшла мова

Мені здається, Ви не до кінця розумієте що і як працює. Ви розказуєте про 4-й рівень, але в одному з моїх практичних прикладів присутній пакет протоколу 3-го рівня.

Це, схоже, на рекламу Ruckus. Звернув увагу, що є деяка кількість дописувачів, які ніколи не працювали з Ruckus, але вважають Ruckus гарними пристроями. Про те, що MikroTik не підтримує 802.11k\v\r (або підтримує дуже обмежено були повідомлення вище). На рахунок інших пристроїв, будь ласка, зазначте, про які моделі йде мова. Тобто сучасні телефони, планшети або ноутбуки не підтримують ці протоколи? Я хотів би отримати велику площу покриття та Wi-Fi roaming на такому рівні, щоб не було значних пауз під час Voice over IP. Яке альтернативне обладнання Ви могли б запропонувати? Будь ласка, вкажіть моделі.

Згадування рівня OSI у цьому випадку немає значення. Чому не "open"?

Цікаво, що буде у разі OpenVPN (UDP). Думаю, просто "open" або "open|filtered".

Навіщо Ви тоді питаєте? Тому що ваші міркування на рівні користувача, а не на рівні block-пристрою зберігання даних Яке відношення мають events до запису відеоданих? Яка швидкість запису на HDD потрібна NVR? Є LBA, є транслятор в HDD. Тільки HDD знає, де саме фізично знаходяться якісь сектори. Користувач не має можливості записати дані фізично в будь-яке місце на поверхні пластин. Тому й впевнений, що все набагато складніше, ніж собі уявляє звичайний користувач. Нагадаю, що HDD не оперує файлами або директоріями.

Якісь тести показують, що WireGuard швидший, ніж OpenVPN та IPSec, але є приклади, коли немає можливості запустити WireGuard на ще достатньо потужних пристроях, яким хоч й 7 - 8 років, але вони підтримують 802.11ac та MIMO. Є сенс змінювати такі пристрої на інші, де вже WireGuard працює - це питання.

Програма nmap має можливість знайти серед усіх можливих UDP портів, порт який відкрито WireGuard. Але визначити, що це саме WireGuard можливості немає. Тому якщо бути точним порт WireGuard класифікується, як "open|filtered", а не "closed". Приклади з "open|filtered" та "closed" є вище.

Можливо, десь є якийсь перелік, тому й спитав. Якщо Zyxel, то, мабуть, й D-link.

Ніяке додаткове сканування нічого не дасть, WireGuard просто нічого не відповідає. Таким же чином інші сервіси можуть нічого не відповідати за тим же принципом. Але що заважає хосту надіслати "ICMP - Destination unreachable (Port unreachable)", якщо ключ WireGuard невірний?