Чому hotspot перенаправляє DNS ще до підключення VPN?

Підключення до готельної мережі ставить перед вами два рішення щодо DNS у різні моменти: запити, які пристрій робить під час входу, і запити, що виконуються після підняття тунелю. Hotspot може впливати на перші через мережу, якою він керує. Другі залежать від політики самого клієнта, що треба перевіряти окремо.

Пройдіть з'єднання по порядку, від першої оренди DHCP до запиту, який розв'язав приватне ім'я. Тоді дві несправності, які в зверненні до підтримки виглядають однаково, чітко розділяються: одна сталася до появи тунелю, інша — усередині нього.

Чого hotspot може і не може торкатися

Мережа доступу видає адресу резолвера через DHCP і може перехопити порт 53 у напрямку цієї адреси. Цього достатньо, щоб відповідати на кожен незахищений запит адресою порталу або сторінкою блокування. Цього також достатньо, щоб зламати клієнт VPN, кінцева точка якого записана як ім'я хоста.

Чого hotspot не може — це читати або переписувати запит, коли той іде всередині встановленого тунелю, за умови, що тунель справді його несе. Перехоплення залежить від бачення питання відкритим текстом.

Запити все одно залишають тунель із причин, не пов'язаних із hotspot: налаштування безпечного DNS у браузері, правило split-DNS, що залишає корпоративний суфікс на локальному резолвері, або клієнт, налаштований виключати DNS з тунелю. Кожен із них — вибір на боці клієнта, і кожен ззовні виглядає як втручання hotspot.

Початковий запит відбувається ще до появи тунелю

Клієнт, якому задано ім'я хоста, має спершу розв'язати його, і в цей момент жоден тунель не захищає запит. Якщо 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, описує симптом щонайменше з трьома різними причинами.