Защо хотспотът пренасочва DNS, преди VPN да се свърже?
Хотспотът пренаписва заявките в собствената си мрежа, а името на хоста се разрешава, преди да съществува какъвто и да е тунел. Проследете кой резолвер е отговорил на всяка заявка.
Присъединяването към хотелска мрежа поставя две DNS решения пред вас в различни моменти: заявките, които устройството прави при влизане, и заявките, направени след като тунелът е готов. Хотспотът може да влияе на първото чрез мрежата, която контролира. Второто зависи от собствената политика на клиента, което е отделен въпрос за проверка.
Проследете връзката по ред, от първия DHCP наем до заявката, която е разрешила частно име. Тогава два отказа, които изглеждат еднакво в тикет за поддръжка, се разделят чисто: единият се е случил преди тунелът да съществува, а другият — вътре в него.
Какво хотспотът може и какво не може да докосне
Мрежата за достъп раздава адрес на резолвер чрез DHCP и може да прихване порт 53 към този адрес. Това е достатъчно, за да отговори на всяка незащитена заявка с адрес на портал или страница за блокиране. Достатъчно е също да счупи VPN клиент, чиято крайна точка е записана като име на хост.
Това, което хотспотът не може, е да чете или пренаписва заявка, след като тя пътува вътре в установен тунел, при условие че тунелът наистина я носи. Прихващането зависи от виждането на въпроса в открит текст.
Заявките напускат тунела така или иначе по причини, несвързани с хотспота: настройката за сигурен DNS в браузъра, правило за split-DNS, което задържа корпоративен суфикс на локалния резолвер, или клиент, конфигуриран да изключи DNS от тунела. Всяко от тях е избор от страната на клиента и всяко изглежда като намеса на хотспота, когато се гледа отвън.
| 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 |
Първоначалната заявка се случва преди да съществува тунел
Клиент, на който е дадено име на хост, трябва първо да го разреши и в този момент никакъв тунел не защитава заявката. Ако хотспотът отговори с адрес на портал, преговорите се провалят или увисват. Ако отговори с нищо, клиентът съобщава грешка в името и тунелът изобщо не стартира. Всеки от двата изхода обяснява празен дневник на тунела, който иначе изглежда невинен.
Операционните системи извършват и свои собствени проверки за свързаност и откриване на портал, описани в RFC 8910 и RFC 8952, и тези заявки излизат преди да е готов какъвто и да е VPN. Да ги видите в прокси дневник е очаквано поведение, а не доказателство за изтичане.
Практическото решение е да дадете на клиента крайна точка, която не се нуждае от заявка. Когато това е невъзможно, първо завършете влизането и след това се свържете.
Разберете кой резолвер е отговорил
Питайте системата, а не браузъра, и изпълнете заявката два пъти: веднъж през резолвера, който устройството използва в момента, и веднъж към фиксиран адрес.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Отговор от първата команда, който се различава от третата, ви казва, че локалният резолвер връща нещо друго, което е точно това, което прави пренасочващ хотспот. Провал от третата заедно с успех от първата сочи към портала: локалният резолвер е обслужил адрес за влизане, докато изходящият порт 53 е бил изхвърлен. Изтичане на времето и при двете означава, че мрежата изхвърля DNS, докато удостоверяването не завърши.
Повторете след свързване и сравнете. Кеширан отговор оцелява при прехода, затова изчистете кеша или попитайте за ново име при второто наблюдение.
Задръжте следващите заявки по пътя, който сте предвидили
Профил с пълен тунел, който също улавя DNS, е най-простата подредба: всяка заявка от всяко приложение отива при резолвера, който тунелът налага, и локалната мрежа вижда само криптиран трафик. Докажете го, като след свързване разрешите вътрешно и публично име и после сравните двата отговора с това, което резолверът на тунела връща сам.
Split-DNS се нуждае от списък с домейни, написан с намерение: корпоративни суфикси през тунела, всичко останало локално и без припокриване между двете.
Сигурният DNS на браузъра стои извън тази политика, така че ако трябва да е изключен, за да работи профилът предвидимо, изключете го за този профил, а не за машината. Правете го в настройките на браузъра, а не чрез редактиране на системния резолвер, за да е видима промяната следващия път. Записвайте отговора, резолвера и етапа на връзката в един ред за всеки тест. Доклад, който казва, че DNS се е провалил в хотелски Wi-Fi, описва симптом с поне три различни причини.