OpenVPN на порту 53: три разговора, которые путают
Определение адреса конечной точки, шифрованный транспорт и DNS после туннеля — это три разных разговора. Определите, какой этап отказал, прежде чем менять порт или резолвер.
Отчёты о том, что VPN заблокирован на порту 53, смешивают три наблюдения, которые отказывают по разным причинам. Определение имени конечной точки происходит до того, как появится туннель, шифрованный транспорт — отдельный разговор, а DNS-запросы, выполняемые после, — третий. У каждого своя подпись отказа, и только один из них вообще связан с DNS.
Прежде чем что-то менять, разложите пакеты по назначению, потому что исправление следует за этапом.
Три разговора, один номер порта
Первый разговор — это поиск имени конечной точки: ваша машина спрашивает у настроенного резолвера, где находится vpn.example.com, и этот ответ приходит по обычному DNS ещё до того, как клиент отправит хотя бы один туннельный пакет. Второй — сам транспорт OpenVPN, который подключается к адресу, полученному при поиске, по тому протоколу и порту, которые указаны в профиле. Третий происходит после поднятия туннеля, когда приложения запрашивают имена, а переданные настройки резолвера решают, кто отвечает.
Эти три могут успешно работать или отказывать независимо друг от друга. Клиент может прекрасно определить свою конечную точку и всё равно не достучаться до слушателя, а может установить туннель, когда каждый внутренний поиск имени отказывает из-за того, что настройки DNS так и не пришли.
| Conversation | When it happens | What has to be true |
|---|---|---|
| Endpoint lookup | Before the client contacts a hostname | An underlying resolver path can answer for the endpoint name |
| OpenVPN transport | During tunnel establishment | The gateway listens on its configured transport, address and port, and nothing filters it |
| Application DNS | During or after the protected session | A resolver the client can reach, plus routing that carries its queries |
Читайте таблицу как контрольный список, а не как описание. Если имя конечной точки не определяется, дальше ничего не может работать, и туннель вообще не начинается.
Номер порта не называет приложение
Порт 53 несёт DNS по соглашению, и оператор OpenVPN тоже может опубликовать там слушатель, и именно поэтому этот номер — плохой идентификатор. Сеанс OpenVPN на UDP 53 остаётся сеансом OpenVPN, а DNS-запрос к серверу на порту 53 ничего не говорит о том, разрешён ли туннель. Строки proto и remote профиля задают внешнюю конечную точку; номер порта сам по себе ничего не задаёт.
При диагностике это режет в обе стороны: общая UDP-проба на порт 53 доказывает, что порт отвечает, а не что отвечает служба VPN. Проверяйте настоящим клиентом и настоящим профилем, потому что только это тренирует рукопожатие, которого ждёт служба.
Докажите слушатель, прежде чем винить сеть
На сервере проверьте, что привязано, с помощью ss -lunp | grep 53, и сравните с протоколом и портом профиля. Из сети клиента запустите клиент с большей подробностью, чтобы журнал показал, какой адрес и транспорт он пробовал. Если сервер слушает, а пакеты клиента не приходят, их отклоняет путь или политика, и это разговор с владельцем сети, а не повод менять порт.
Другой порт помогает только тогда, когда служба действительно слушает там и развёртывание это разрешает. Перенос слушателя, чтобы обойти фильтрацию управляемой сети, — это решение политики, а не шаг диагностики. Спросите владельца сети, что разрешено, прежде чем менять службу, потому что обходной путь, нарушающий политику, всё равно позже закрывают. Запишите этот ответ рядом с профилем, чтобы следующий человек не повторял запрос.
Проверьте DNS после туннеля, отдельно
Когда туннель поднят, посмотрите состояние резолвера на интерфейсе VPN и запросите одно внутреннее и одно публичное имя. Если внутренние имена отказывают, пока туннель несёт трафик, значит переданные настройки DNS не применились, и это вопрос интеграции клиента, а не транспорта. Если публичные имена отказывают, а внутренние работают, политика раздельного туннеля делает то, для чего её настроили.
Оставьте изменения DNS владельцу резолвера. Перезапись управляемой конфигурации резолвера ради прохождения одного теста может сломать приватные имена для всего остального на машине. Если туннель передаёт резолвер, а клиент его игнорирует, исправьте интеграцию клиента вместо добавления статической записи в другом месте. Статические записи скрывают отказ, пока кто-нибудь не сменит сеть. Запишите, какой резолвер должен отвечать за каждое пространство имён.