UDP блокирует провайдер или приложение внутри туннеля?

Кто-то сообщает, что VPN „блокирует UDP“, и эта фраза скрывает два совершенно разных утверждения. Одно касается транспорта, который видит сеть доступа, другое — пакетов приложения после их расшифровки внутри туннеля. Зашифрованный туннель можно фильтровать снаружи без всякого ключа, а внутреннее приложение UDP может сбоить по причинам, не имеющим никакого отношения к фильтрации. Определите, какое утверждение вы проверяете, прежде чем собирать доказательства.

Два заголовка, одно слово

В развёртывании IPsec с NAT-traversal внешний пакет — это UDP, адресованный между двумя конечными точками VPN, обычно на порту 4500. Внутри него зашифрованная полезная нагрузка несёт всё, что передаёт туннель, и это само может быть TCP или UDP. Поэтому слово UDP встречается дважды, с разным смыслом и разной видимостью.

Промежуточная сеть видит внешний заголовок и ничего из внутреннего. Она может разрешить, сформировать или отбросить внешний поток, и для этого ей не нужно ничего расшифровывать. Именно эта асимметрия — вся причина путаницы между двумя утверждениями: одно и то же слово описывает и то, что фильтрует сеть, и то, что отправляет приложение. Записывайте уровень рядом со словом каждый раз, когда фиксируете наблюдение, и путаница в основном исчезает.

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

Что сеть всё ещё может видеть

Шифрование скрывает полезную нагрузку и внутренний транспортный заголовок, а не сам факт существования потока. Адреса конечных точек, порты, размеры пакетов и время остаются видимыми, и этого достаточно, чтобы эвристически классифицировать трафик или заблокировать конкретное назначение.

sudo tcpdump -ni eth0 'udp port 4500'
sudo tcpdump -ni tun0 'udp port 5201'

Первая запись показывает внешний поток на физическом интерфейсе, а вторая — внутренний поток на интерфейсе туннеля. Запуск обеих одновременно прямо отвечает на вопрос: если внешний поток есть, а внутреннего нет, приложение ничего не отправило в туннель. Если есть оба, а ничего не возвращается, проблема за пределами туннеля — в пункте назначения или на обратном пути.

RFC 3948 определяет внешнюю инкапсуляцию UDP, а спецификация ESP определяет защищённую раскладку внутри неё. Ни один из документов не обещает, что сеть доступа пропустит внешний поток, поэтому тест доступности на внешнем кортеже стоит выполнить до любой теории о внутреннем. Заблокированный внешний кортеж даёт туннель, который никогда не формируется, а не туннель, который формируется и затем теряет одно приложение.

Почему одно приложение UDP сбоит внутри работающего туннеля

У туннеля, который передаёт веб-приложение, но не приложение UDP, есть несколько правдоподобных объяснений, и фильтрация внутреннего протокола провайдером не первое из них. Чаще всего это покрытие: оба приложения не попадают в один и тот же туннель, потому что маршрут к назначению UDP отсутствует или правила раздельного туннеля клиента исключают его.

Второе — конечная точка. VPN-сервер, разрешающий список протоколов, межсетевой экран в пункте назначения или служба, которая никогда не слушает ожидаемый порт, — все они дадут тайм-аут, выглядящий точно так же, как сетевая блокировка.

Третье — размер пакета. Приложения UDP часто отправляют датаграммы крупнее веб-запроса, а инкапсуляция уменьшает доступный MTU, поэтому после успешного рукопожатия может наступить тишина на первой полезной нагрузке полного размера. Этот шаблон легко прочитать как блокировку, потому что маленькие пакеты проходят, а большие исчезают. Быстрая проверка MTU решает вопрос меньше чем за минуту, и ответом обычно бывает меньшая нагрузка или исправленный MSS, а не сетевой фильтр.

ping -M do -s 1400 -c 2 10.60.0.20
iperf3 -u -c 10.60.0.20 -p 5201 -b 1M -t 5

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

Сообщайте уровень, а не протокол

Запишите наблюдение в одной из трёх форм: внешняя доставка не удалась, внутренняя передача не удалась или приложение не сработало. У каждой свой владелец, и их смешение отправляет заявку не той команде.

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

Держите вывод отдельно от наблюдения. Анализ трафика может подсказать, что представляет собой поток, не расшифровывая его, и это полезное наблюдение, но это не то же утверждение, что чтение внутреннего заголовка. Укажите, какое из двух у вас действительно есть.