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 без ответа не доказывает ни того, что сервер офлайн, ни того, что он безопасен. Он доказывает, что эта проверка, на этом пути, в этот момент не была принята.