UDP-сканирование говорит «отфильтровано»: ваш пир WireGuard действительно недоступен?

Сканеры выводят «открыт» или «отфильтрован» для порта 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. Правило межсетевого экрана хоста и группа безопасности в облаке — два независимых шлюза, и любой из них может отбросить пакет, который разрешил другой. Проверяйте оба против фактического порта в конфигурации, а не против порта, который вы помните.

Адрес важен не меньше порта. Сервер, слушающий на определённом адресе, не ответит на пакет, пришедший на другой, а хост с несколькими интерфейсами может получить пробу на том интерфейсе, который вы не имели в виду.

Держите каждую проверку внутри систем, которые вам разрешено тестировать. Полезное сравнение — между одной реальной попыткой клиента и ожидаемым путём сервера, а не более широкий перебор адресов, случайно принадлежащих тому же провайдеру.

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

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

Более сильное доказательство — завершённое рукопожатие от клиента, который вам действительно важен, а затем запрос, использующий туннель и получающий ответ. Эта последовательность за один раз задействует ключи, разрешённые адреса, оба межсетевых экрана и обратный путь.

Там, где реальная попытка терпит неудачу, сбой всё равно нужно диагностировать по счётчикам клиента и записи на сервере, а не по очередной пробе. Описание протокола объясняет, почему неаутентифицированный пакет не получает ответа, и это вся причина неоднозначности результата сканирования.