Prečo hotspot presmeruje DNS ešte pred pripojením VPN?
Hotspot prepisuje dopyty vo svojej vlastnej sieti a koncový bod zadaný ako názov hostiteľa sa prekladá skôr, než existuje akýkoľvek tunel. Sledujte, ktorý resolver odpovedal na každý dopyt.
Pripojenie k hotelovej sieti stavia pred vás dve rozhodnutia o DNS v rôznych okamihoch: dopyty, ktoré zariadenie vykoná pri prihlasovaní, a dopyty vykonané po postavení tunela. Hotspot môže ovplyvniť prvé cez sieť, ktorú ovláda. Druhé závisia od politiky samotného klienta, čo je samostatná vec na preskúmanie.
Prejdite spojenie po poradí, od prvého nájmu DHCP k dopytu, ktorý preložil súkromné meno. Potom sa dve poruchy, ktoré v tiketu podpory vyzerajú rovnako, čisto oddelia: jedna nastala pred vznikom tunela, druhá v jeho vnútri.
Čoho sa hotspot môže a nemôže dotknúť
Prístupová sieť prideľuje adresu resolvera cez DHCP a môže zachytiť port 53 smerom k tejto adrese. To stačí na to, aby každý nechránený dopyt dostal adresu portálu alebo blokovaciu stránku. Stačí to aj na zlomenie VPN klienta, ktorého koncový bod je zapísaný ako názov hostiteľa.
Čo hotspot nedokáže, je čítať alebo prepisovať dopyt, keď už putuje vnútri ustáleného tunela, za predpokladu, že tunel ho naozaj nesie. Zachytenie závisí od videnia otázky v otvorenom texte.
Dopyty napriek tomu opúšťajú tunel z dôvodov nesúvisiacich s hotspotom: nastavenie zabezpečeného DNS v prehliadači, pravidlo split-DNS, ktoré drží firemnú príponu na lokálnom resolveri, alebo klient nakonfigurovaný tak, aby vylúčil DNS z tunela. Každé je voľbou na strane klienta a každé zvonku vyzerá ako rušenie hotspotom.
| 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 |
Počiatočný dopyt nastáva pred vznikom tunela
Klient, ktorému je zadaný názov hostiteľa, ho musí najprv preložiť, a v tom okamihu dopyt nechráni žiadny tunel. Ak hotspot odpovie adresou portálu, vyjednávanie zlyhá alebo sa zasekne. Ak neodpovie ničím, klient ohlási chybu mena a tunel sa nikdy nespustí. Každý z oboch výsledkov vysvetľuje prázdny protokol tunela, ktorý inak vyzerá nevinne.
Operačné systémy vykonávajú aj vlastné kontroly pripojenia a zisťovanie portálu, opísané v RFC 8910 a RFC 8952, a tieto požiadavky odchádzajú skôr, než je spustený akýkoľvek VPN. Vidieť ich v protokole proxy je očakávané správanie a nie dôkaz úniku.
Praktickým riešením je dať klientovi koncový bod, ktorý nepotrebuje dopyt. Keď to nie je možné, najprv dokončite prihlásenie a potom sa pripojte.
Zistite, ktorý resolver odpovedal
Pýtajte sa systému, nie prehliadača, a spustite dopyt dvakrát: raz cez akýkoľvek resolver, ktorý zariadenie teraz používa, raz proti pevnej adrese.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Odpoveď prvého príkazu, ktorá sa líši od tretieho, vám hovorí, že lokálny resolver vracia niečo iné, a presne to robí presmerujúci hotspot. Zlyhanie tretieho spolu s úspechom prvého ukazuje na portál: lokálny resolver poslúžil prihlasovaciu adresu, kým bol odchádzajúci port 53 zahodený. Časové limity pri oboch znamenajú, že sieť zahadzuje DNS, kým sa nedokončí overenie.
Po pripojení to zopakujte a porovnajte. Uložená odpoveď prežije prechod, preto vyprázdnite medzipamäť alebo sa pre druhé pozorovanie opýtajte na nové meno.
Udržte neskoršie dopyty na zamýšľanej ceste
Profil plného tunela, ktorý zachytáva aj DNS, je najjednoduchšie usporiadanie: každý dopyt z každej aplikácie ide k resolveru, ktorý tunel pretláča, a lokálna sieť vidí len šifrovanú prevádzku. Dokážte to tak, že po pripojení preložíte interné a verejné meno a potom obe odpovede porovnáte s tým, čo resolver tunela vracia sám.
Split-DNS potrebuje zoznam domén napísaný s úmyslom: firemné prípony cez tunel, všetko ostatné lokálne a bez prekrývania medzi oboma.
Zabezpečené DNS prehliadača stojí mimo tejto politiky, takže ak musí byť vypnuté, aby sa profil správal predvídateľne, vypnite ho pre tento profil, nie pre celý počítač. Urobte to v nastaveniach prehliadača, nie úpravou systémového resolvera, aby bola zmena nabudúce viditeľná. Zaznamenajte odpoveď, resolver a fázu pripojenia do jedného riadku na test. Správa, že DNS zlyhalo v hotelovom Wi-Fi, opisuje príznak s najmenej tromi rôznymi príčinami.