VPN через UDP мовчить під час сканування портів? Чому так буває
WireGuard і посилений OpenVPN відкидають датаграми, що не пройшли автентифікацію, не відповідаючи. Тиша з боку сканера — очікувана поведінка, а не закритий порт.
Ви скануєте порт VPN, не отримуєте відповіді й робите висновок, що сервіс не працює або міжмережевий екран закритий. З WireGuard і з каналами керування OpenVPN, які несуть власну автентифікацію, такий висновок не випливає. Датаграма без чинного матеріалу автентифікації відкидається без відповіді, тому тиша — це те, як здоровий сервіс виглядає ззовні. Перевірка помилкова раніше, ніж тунель.
Тиша — це протокол, а не несправність
UDP не має встановлення з'єднання, тому немає ні SYN, ні підтвердження, яке дало б сканеру змогу відрізнити відкритий порт від фільтрованого. Перевірка надходить як ізольована датаграма, і сервіс звіряє, чи відповідає вона очікуваному протоколу. Якщо ні, пакет відкидається, і відкидання — це задокументована поведінка, а не збій.
WireGuard криптографічно перевіряє свої повідомлення рукостискання й ігнорує все, що не проходить. OpenVPN з tls-auth або tls-crypt робить те саме для свого каналу керування. В обох випадках довільне корисне навантаження ніколи не досягає етапу, зверненого до користувача, тому відповідати нічим і помилку повертати не потрібно.
TCP дав би вам скидання із закритого порту. UDP залишає невизначеність, яку сканери розв'язують, друкуючи «відкрито» або «фільтрується» замість здогадок.
Що сканер може й чого не може встановити
Результат сканування інформативний рівно настільки, наскільки інформативне надіслане корисне навантаження. Упорядкуйте можливі спостереження за тим, що кожне з них справді підтверджує:
| Probe | Observed result | What it supports |
|---|---|---|
| Empty datagram | No reply | Nothing beyond the fact that UDP was used |
| Random payload | No reply | Consistent with an authenticated service |
| Valid handshake from a real client | A protocol reply | The service is alive and reachable |
| ICMP port unreachable | Unreachable message | The host answered, usually because nothing listens |
Читайте третій рядок як єдиний позитивний тест у списку. Для нього потрібні справжній профіль, справжній ключ і правильна кінцева точка, а саме цього звичайний сканер не має.
Погляньте на обидва кінці шляху
Для сервера, яким ви керуєте, зніміть трафік на інтерфейсі, перш ніж робити будь-який висновок, а потім запитайте сервіс, що він побачив. Обидві команди потребують root на шлюзі:
tcpdump -ni any udp port 51820
tcpdump -ni any udp port 1194
wg showЯкщо на інтерфейсі не з'являється жодного пакета, шлях відкинув його раніше, ніж сервіс щось побачив, і наступна зупинка — маршрутизація та фільтрація. Якщо пакети надходять, але рукостискання не завершується, сервіс доступний, а розбіжність у ключах, конфігурації кінцевої точки або версії протоколу. Це порівняння відповідає на питання, на яке сканер не міг відповісти. Запускайте його, поки реальний клієнт намагається підключитися, а не поки сканер повторює сам себе.
Змініть перевірку, а не захист
Спокусливий короткий шлях — вимкнути захист каналу керування, щоб діагностика отримала відповідь. Це обмінює справжню властивість безпеки на гарніший результат сканування, і це хибний напрямок. Натомість використайте чинний профіль із схваленої мережі та запишіть кінцеву точку й час, щоб порівняння можна було повторити.
Найкорисніший тест — диференційний: той самий профіль на шляху, що працює, і на шляху, що не працює. Якщо робочий шлях дає рукостискання, а збійний шлях не дає на інтерфейсі нічого, ви знайшли місце розриву, нічого не послабивши.
Отже, пакет UDP без відповіді не доводить ні того, що сервер офлайн, ні того, що він безпечний. Він доводить, що ця перевірка, на цьому шляху, у цей момент не була прийнята.