Почему hotspot перенаправляет DNS ещё до подключения VPN?
Hotspot переписывает запросы в своей сети, а конечная точка в виде имени хоста разрешается ещё до появления любого туннеля. Проследите, какой резолвер ответил на каждый запрос.
Подключение к гостиничной сети ставит перед вами два решения по DNS в разные моменты: запросы, которые устройство делает при входе, и запросы, выполняемые после поднятия туннеля. Hotspot может влиять на первые через сеть, которой он управляет. Вторые зависят от политики самого клиента, что нужно проверять отдельно.
Пройдите соединение по порядку, от первой аренды DHCP до запроса, разрешившего частное имя. Тогда две неисправности, которые в обращении в поддержку выглядят одинаково, чётко разделяются: одна произошла до появления туннеля, другая — внутри него.
Чего hotspot может и не может касаться
Сеть доступа выдаёт адрес резолвера по DHCP и может перехватить порт 53 в сторону этого адреса. Этого достаточно, чтобы отвечать на каждый незащищённый запрос адресом портала или страницей блокировки. Этого также достаточно, чтобы сломать клиент VPN, конечная точка которого записана как имя хоста.
Чего hotspot не может — читать или переписывать запрос, когда тот идёт внутри установленного туннеля, при условии, что туннель действительно его несёт. Перехват зависит от возможности увидеть вопрос открытым текстом.
Запросы всё равно покидают туннель по причинам, не связанным с hotspot: настройка безопасного DNS в браузере, правило split-DNS, оставляющее корпоративный суффикс на локальном резолвере, или клиент, настроенный исключать DNS из туннеля. Каждый из них — выбор на стороне клиента, и каждый снаружи выглядит как вмешательство hotspot.
| Path | Who answers | What a failure looks like |
|---|---|---|
| Lookup before the tunnel is up | The network's resolver | The client never reaches its endpoint |
| Lookup inside the tunnel | The resolver pushed by the client | Local policy or tunnel DNS is misconfigured |
| Browser secure DNS | A DoH provider over port 443 | Both the hotspot and the tunnel policy are bypassed |
Начальный запрос происходит ещё до появления туннеля
Клиент, которому задано имя хоста, должен сначала разрешить его, и в этот момент никакой туннель не защищает запрос. Если hotspot отвечает адресом портала, согласование срывается или зависает. Если он не отвечает ничем, клиент сообщает об ошибке имени, и туннель не запускается. Любой из двух исходов объясняет пустой журнал туннеля, который иначе выглядит безобидно.
Операционные системы также выполняют собственные проверки связности и обнаружение портала, описанные в RFC 8910 и RFC 8952, и эти запросы уходят до того, как поднимется любой VPN. Видеть их в журнале прокси — ожидаемое поведение, а не доказательство утечки.
Практическое решение — дать клиенту конечную точку, которой не нужен запрос. Когда это невозможно, сначала завершите вход, а потом подключайтесь.
Выясните, какой резолвер ответил
Спросите систему, а не браузер, и выполните запрос дважды: один раз через тот резолвер, который устройство использует сейчас, один раз к фиксированному адресу.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Ответ первой команды, отличающийся от третьего, говорит, что локальный резолвер возвращает что-то другое, а именно это и делает перенаправляющий hotspot. Сбой третьего вместе с успехом первого указывает на портал: локальный резолвер выдал адрес входа, тогда как исходящий порт 53 был отброшен. Тайм-ауты в обоих случаях означают, что сеть отбрасывает DNS, пока не завершится аутентификация.
Повторите после подключения и сравните. Кэшированный ответ переживает переход, поэтому очистите кэш или запросите новое имя для второго наблюдения.
Держите последующие запросы на задуманном пути
Профиль полного туннеля, который также захватывает DNS, — простейшая схема: каждый запрос каждого приложения идёт к резолверу, который навязывает туннель, а локальная сеть видит только зашифрованный трафик. Докажите это, разрешив после подключения внутреннее и публичное имя, а затем сравнив оба ответа с тем, что резолвер туннеля возвращает сам по себе.
Split-DNS нуждается в списке доменов, написанном осознанно: корпоративные суффиксы через туннель, всё остальное локально, и без пересечения между ними.
Безопасный DNS браузера находится вне этой политики, поэтому если его нужно отключить, чтобы профиль вёл себя предсказуемо, отключите его для этого профиля, а не для машины. Делайте это в настройках браузера, а не редактируя системный резолвер, чтобы изменение было видно в следующий раз. Записывайте ответ, резолвер и этап подключения в одной строке на тест. Отчёт о том, что DNS не сработал в гостиничном Wi-Fi, описывает симптом как минимум с тремя разными причинами.