Зошто хотспотот го пренасочува 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 во хотелот опишува симптом со најмалку три различни причини.