Сканери виводять відкрито або відфільтровано для порту UDP, і висновок зазвичай надходить за секунди: тунель зламано. Можливо, так і є, але сканування цього не довело. UDP не несе жодного рукостискання з'єднання, а WireGuard не відповідає ні на що, чого не може автентифікувати, тому тиша — очікувана відповідь на більшість проб.

Працюйте натомість від клієнта назовні й ставтеся до сканування як до однієї слабкої точки даних серед кількох.

Що сканер може і чого не може побачити

Сканер UDP надсилає навантаження й чекає. Якщо повертається ICMP port-unreachable, він може повідомити порт як закритий. Якщо нічого не повертається, результат неоднозначний за задумом: відфільтрований шлях, відсутній хост і працююча служба, що проігнорувала навантаження, усе створює ту саму тишу. Три різні стани, один рядок виводу.

WireGuard навмисно погіршує цю неоднозначність. Протокол приймає пакет лише тоді, коли той автентифікується, тому проба з неправильними ключами відкидається без відповіді. Немає ні банера, ні рядка версії, ні повідомлення про помилку для зняття відбитка.

Перевірка TCP на тому самому номері порту не перевіряє нічого пов'язаного. Вона задіює іншого слухача, якого може й не бути, і її відмова нічого не каже про UDP.

Тож відкриті відфільтровані стани описують невизначеність сканера точніше, ніж ваш сервер.

Пройдіть справжнього клієнта від профілю всередину

Почніть із власного погляду клієнта. Чи має інтерфейс адресу, чи називає конфігурація правильну кінцеву точку і чи рухається лічильник рукостискань, коли намагаються з'єднатися? Клієнт, який ніколи не надсилав пакет, і клієнт, чиї пакети було відкинуто, виглядають у вікні стану однаково. Їх розрізняють лише лічильники, тому спершу читайте лічильники.

Далі спостерігайте за боком сервера під час однієї дозволеної спроби, замість того щоб запускати окреме сканування з третього місця:

wg show wg0 latest-handshakes
tcpdump -n -i eth0 udp port 51820 -c 10

Перша команда повідомляє останнє рукостискання для кожного партнера, що є прямим доказом завершеного автентифікованого обміну. Друга показує, чи доходять пакети для слухача взагалі, і це одним кроком відділяє проблему шляху від проблеми конфігурації.

Якщо запис нічого не показує, пакет так і не дійшов до хоста, і конфігурація тунелю не підозрюється. Якщо він показує пакети, що приходять з очікуваної адреси, поки рукостискання лишається на нулі, ключі або дозволені адреси партнера — наступне місце для перевірки.

Корелюйте на сервері, коли адмініструєте його

Підтвердьте, що слухач існує і що міжмережевий екран провайдера дозволяє порт UDP. Правило міжмережевого екрана хоста й група безпеки в хмарі — два незалежні шлюзи, і кожен із них може відкинути пакет, який дозволив інший. Перевіряйте обидва щодо фактичного порту в конфігурації, а не щодо порту, який ви пам'ятаєте.

Адреса важлива не менше за порт. Сервер, що слухає на певній адресі, не відповість на пакет, який прийшов на іншу, а хост із кількома інтерфейсами може отримати пробу на тому інтерфейсі, який ви не мали на увазі.

Тримайте кожну перевірку всередині систем, які вам дозволено тестувати. Корисне порівняння — між однією реальною спробою клієнта й очікуваним шляхом сервера, а не ширший перебір адрес, що випадково належать тому самому провайдеру.

Чесне читання результату сканування

Сканування — дешевий спосіб переконатися, що хост існує і що порт не блокується очевидно проміжним пристроєм. Це не доказ доступності для автентифікованого протоколу і точно не перевірка конфігурації.

Сильніший доказ — завершене рукостискання від клієнта, який вам справді важливий, а потім запит, що використовує тунель і отримує відповідь. Ця послідовність за один раз задіює ключі, дозволені адреси, обидва міжмережеві екрани й зворотний шлях.

Там, де реальна спроба зазнає невдачі, збій усе одно треба діагностувати за лічильниками клієнта й записом на сервері, а не за черговою пробою. Опис протоколу пояснює, чому неавтентифікований пакет не отримує відповіді, і це вся причина неоднозначності результату сканування.

Схожі статті