Kvifor omdirigerer eit hotspot DNS før VPN-et koplar til?
Eit hotspot skriv om oppslag på sitt eige nettverk, og eit vertsnavn-endepunkt blir løyst opp før nokon tunnel finst. Spor kva resolver som svara på kvar førespurnad.
Å kopla seg til eit hotellnettverk set to DNS-avgjerder framfor deg på ulike tidspunkt: oppslaga eininga gjer under pålogging, og oppslaga som blir gjorde når tunnelen er oppe. Eit hotspot kan påverka dei første gjennom nettverket det kontrollerer. Dei andre avheng av klienten sin eigen politikk, som er noko eige å undersøkja.
Gå gjennom tilkoplinga i rekkjefølgje, frå den første DHCP-leiga til førespurnaden som løyste opp eit privat namn. Då skiljast to feil som ser identiske ut i ein støttebillett, reint: ein skjedde før tunnelen fanst, den andre skjedde inne i han.
Kva hotspotet kan og ikkje kan røra
Aksessnettet deler ut ei resolveradresse i DHCP og kan avskjera port 53 mot den adressa. Det er nok til å svara på kvart uverna oppslag med ei portaladresse eller ei blokkeringsside. Det er også nok til å øydeleggja ein VPN-klient der endepunktet er skrive som eit vertsnavn.
Det hotspotet ikkje kan, er å lesa eller skriva om ein førespurnad når han først fer inni ein etablert tunnel, føresett at tunnelen verkeleg ber han. Avskjering avheng av å sjå spørsmålet i klartekst.
Førespurnader forlèt likevel tunnelen av grunnar som ikkje har med hotspotet å gjera: den trygge DNS-innstillinga i nettlesaren, ei split-DNS-regel som held eit bedriftssuffiks på den lokale resolveren, eller ein klient konfigurert til å utelukka DNS frå tunnelen. Kvar av dei er eit val på klientsida, og kvar av dei ser ut som hotspot-forstyrring når ein ser det utanfrå.
| 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 |
Det første oppslaget skjer før tunnelen finst
Ein klient som får eit vertsnavn, må først løysa det opp, og i det augneblinken vernar ingen tunnel førespurnaden. Svarar hotspotet med ei portaladresse, feilar forhandlinga eller heng. Svarar det med ingenting, rapporterer klienten ein namnefeil, og tunnelen startar aldri. Kvar av dei to utfalla forklarer ein tom tunnellogg som elles ser uskuldig ut.
Operativsystem køyrer også eigne tilkoplingssjekkar og portaldeteksjon, skildra i RFC 8910 og RFC 8952, og desse førespurnadene går ut før nokon VPN er oppe. Å sjå dei i ein proxy-logg er forventa åtferd og ikkje prov på ein lekkasje.
Den praktiske løysinga er å gje klienten eit endepunkt som ikkje treng noko oppslag. Når det er umogleg, fullfør pålogginga først og kople til etterpå.
Finn ut kva resolver som svara
Spør systemet og ikkje nettlesaren, og køyr førespurnaden to gonger: éin gong gjennom kva resolver eininga brukar no, éin gong mot ei fast adresse.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Eit svar frå den første kommandoen som avvik frå det tredje, fortel deg at den lokale resolveren returnerer noko anna, som er nettopp det eit omdirigerande hotspot gjer. Ein feil frå det tredje saman med ein suksess frå det første peikar på portalen: den lokale resolveren leverte ei påloggingsadresse medan utgåande port 53 vart forkasta. Tidsavbrot på begge betyr at nettverket forkastar DNS til autentiseringa er fullført.
Gjenta etter tilkopling og samanlikn. Eit mellomlagra svar overlever overgangen, så tøm bufferen eller spør om eit nytt namn for den andre observasjonen.
Hald seinare oppslag på vegen du hadde tenkt
Ein fulltunnelprofil som også fangar DNS, er den enklaste ordninga: kvar førespurnad frå kvar applikasjon går til resolveren tunnelen skyv på, og det lokale nettverket ser berre kryptert trafikk. Prov det ved å løysa opp eit internt og eit offentleg namn etter tilkopling, og deretter samanlikna båe svara med det tunnelresolveren returnerer på eiga hand.
Split-DNS treng ei domeneliste skriven med vilje: bedriftssuffiks gjennom tunnelen, alt anna lokalt, og inga overlapping mellom dei to.
Trygg DNS i nettlesaren står utanfor den politikken, så om han må vera av for at profilen skal oppføra seg føreseieleg, slå han av for den profilen og ikkje for maskinen. Gjer det i nettlesarinnstillingane, ikkje ved å redigera systemresolveren, slik at endringa er synleg neste gong. Noter svaret, resolveren og tilkoplingstrinnet på éi linje per test. Ein rapport som seier at DNS feila på hotell-Wi-Fi, skildrar eit symptom med minst tre ulike årsaker.