Hvorfor omdirigerer et hotspot DNS før VPN-et kobler til?
Et hotspot skriver om oppslag på sitt eget nettverk, og et vertsnavn-endepunkt løses opp før noen tunnel finnes. Spor hvilken resolver som svarte på hver forespørsel.
Å koble seg til et hotellnettverk stiller to DNS-beslutninger foran deg på ulike tidspunkter: oppslagene enheten gjør under pålogging, og oppslagene som gjøres når tunnelen er oppe. Et hotspot kan påvirke de første gjennom nettverket det kontrollerer. De andre avhenger av klientens egen policy, som er noe eget å undersøke.
Gå gjennom tilkoblingen i rekkefølge, fra den første DHCP-leien til forespørselen som løste opp et privat navn. Da skilles to feil som ser identiske ut i en støttebillett, rent: én skjedde før tunnelen fantes, den andre skjedde inne i den.
Hva hotspotet kan og ikke kan røre
Aksessnettet deler ut en resolveradresse i DHCP og kan avskjære port 53 mot den adressen. Det er nok til å svare på hvert ubeskyttet oppslag med en portaladresse eller en blokkeringsside. Det er også nok til å ødelegge en VPN-klient hvis endepunkt er skrevet som et vertsnavn.
Det hotspotet ikke kan, er å lese eller skrive om en forespørsel når den først reiser inne i en etablert tunnel, forutsatt at tunnelen virkelig bærer den. Avskjæring avhenger av å se spørsmålet i klartekst.
Forespørsler forlater likevel tunnelen av grunner som ikke har med hotspotet å gjøre: nettleserens sikre DNS-innstilling, en split-DNS-regel som holder et bedriftssuffiks på den lokale resolveren, eller en klient konfigurert til å utelukke DNS fra tunnelen. Hver av dem er et valg på klientsiden, og hver av dem ser ut som hotspot-forstyrrelse når man ser det utenfra.
| 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 finnes
En klient som får et vertsnavn, må først løse det opp, og i det øyeblikket beskytter ingen tunnel forespørselen. Svarer hotspotet med en portaladresse, feiler forhandlingen eller henger. Svarer det med ingenting, rapporterer klienten en navnefeil, og tunnelen starter aldri. Hver av de to utfallene forklarer en tom tunnellogg som ellers ser uskyldig ut.
Operativsystemer kjører også egne tilkoblingssjekker og portaldeteksjon, beskrevet i RFC 8910 og RFC 8952, og disse forespørslene går ut før noen VPN er oppe. Å se dem i en proxy-logg er forventet atferd og ikke bevis på en lekkasje.
Den praktiske løsningen er å gi klienten et endepunkt som ikke trenger noe oppslag. Når det er umulig, fullfør påloggingen først og koble til etterpå.
Finn ut hvilken resolver som svarte
Spør systemet og ikke nettleseren, og kjør forespørselen to ganger: én gang gjennom hvilken resolver enheten bruker nå, én gang mot en fast adresse.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Et svar fra den første kommandoen som avviker fra det tredje, forteller deg at den lokale resolveren returnerer noe annet, som er nettopp det en omdirigerende hotspot gjør. En feil fra det tredje sammen med en suksess fra det første peker på portalen: den lokale resolveren leverte en påloggingsadresse mens utgående port 53 ble forkastet. Tidsavbrudd på begge betyr at nettverket forkaster DNS til autentiseringen er fullført.
Gjenta etter tilkobling og sammenlign. Et bufret svar overlever overgangen, så tøm bufferen eller spør om et nytt navn for den andre observasjonen.
Hold senere oppslag på veien du hadde tenkt
En fulltunnelprofil som også fanger DNS, er den enkleste ordningen: hver forespørsel fra hver applikasjon går til resolveren tunnelen skyver på, og det lokale nettverket ser bare kryptert trafikk. Bevis det ved å løse opp et internt og et offentlig navn etter tilkobling, og deretter sammenligne begge svarene med det tunnelresolveren returnerer på egen hånd.
Split-DNS trenger en domeneliste skrevet med hensikt: bedriftssuffikser gjennom tunnelen, alt annet lokalt, og ingen overlapping mellom de to.
Sikker DNS i nettleseren står utenfor den policyen, så hvis den må være av for at profilen skal oppføre seg forutsigbart, slå den av for den profilen og ikke for maskinen. Gjør det i nettleserinnstillingene, ikke ved å redigere systemresolveren, slik at endringen er synlig neste gang. Noter svaret, resolveren og tilkoblingsstadiet på én linje per test. En rapport som sier at DNS feilet på hotell-Wi-Fi, beskriver et symptom med minst tre ulike årsaker.