Hvorfor omdirigerer et hotspot DNS, før VPN'et forbinder?
Et hotspot omskriver opslag på sit eget netværk, og et værtsnavn-endepunkt slås op, før der findes nogen tunnel. Spor hvilken resolver der svarede på hver forespørgsel.
Tilslutning til et hotelnetværk stiller to DNS-beslutninger foran dig på forskellige tidspunkter: de opslag, enheden laver under login, og de opslag, der laves efter tunnelens opstart. Et hotspot kan påvirke det første gennem det netværk, det styrer. Det andet afhænger af klientens egen politik, hvilket er noget særligt, man skal undersøge.
Gå forbindelsen igennem i rækkefølge, fra den første DHCP-leje til den forespørgsel, der slog et privat navn op. Så skilles to fejl, der ser identiske ud i en supportbillet, rent ad: den ene skete, før tunnelen fandtes, den anden skete inde i den.
Hvad hotspot'et kan og ikke kan røre
Adgangsnetværket uddeler en resolveradresse i DHCP og kan opsnappe port 53 mod den adresse. Det er nok til at besvare hvert ubeskyttet opslag med en portaladresse eller en blokeringsside. Det er også nok til at ødelægge en VPN-klient, hvis endepunkt er skrevet som et værtsnavn.
Det, hotspot'et ikke kan, er at læse eller omskrive en forespørgsel, når den rejser inde i en etableret tunnel, forudsat at tunnelen virkelig bærer den. Aflytning afhænger af at se spørgsmålet i klartekst.
Forespørgsler forlader alligevel tunnelen af grunde, der intet har med hotspot'et at gøre: browserens sikre DNS-indstilling, en split-DNS-regel, der holder et virksomhedssuffiks på den lokale resolver, eller en klient konfigureret til at udelukke DNS fra tunnelen. Hver af dem er et valg på klientsiden, og hver af dem ligner hotspot-forstyrrelse, når man ser det udefra.
| 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 indledende opslag sker, før tunnelen findes
En klient, der får et værtsnavn, skal først slå det op, og i det øjeblik beskytter ingen tunnel forespørgslen. Svarer hotspot'et med en portaladresse, fejler forhandlingen eller hænger. Svarer det med intet, rapporterer klienten en navnefejl, og tunnelen starter aldrig. Hvert af de to udfald forklarer en tom tunnel-log, der ellers ser uskyldig ud.
Styresystemer kører også deres egne forbindelsestjek og portalopdagelse, beskrevet i RFC 8910 og RFC 8952, og disse anmodninger forlader enheden, før nogen VPN er oppe. At se dem i en proxy-log er forventet adfærd og ikke bevis på en lækage.
Den praktiske løsning er at give klienten et endepunkt, der ikke kræver noget opslag. Når det er umuligt, så afslut login først og forbind derefter.
Find ud af, hvilken resolver der svarede
Spørg systemet i stedet for browseren, og kør forespørgslen to gange: én gang gennem den resolver, enheden bruger nu, og én gang mod 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 kommando, der afviger fra det tredje, fortæller dig, at den lokale resolver returnerer noget andet, hvilket er, hvad et omdirigerende hotspot gør. En fejl fra det tredje sammen med en succes fra det første peger på portalen: den lokale resolver leverede en loginadresse, mens udgående port 53 blev kasseret. Timeouts på begge betyder, at netværket kasserer DNS, indtil godkendelsen er fuldført.
Gentag efter tilslutning og sammenlign. Et cachet svar overlever skiftet, så tøm cachen eller spørg på et nyt navn til den anden observation.
Hold senere opslag på den vej, du havde til hensigt
En fuldtunnelprofil, der også fanger DNS, er den enkleste ordning: hver forespørgsel fra hver applikation går til den resolver, tunnelen skubber, og det lokale netværk ser kun krypteret trafik. Bevis det ved at slå et internt og et offentligt navn op efter tilslutning og derefter sammenligne begge svar med det, tunnelens resolver selv returnerer.
Split-DNS kræver en domæneliste skrevet med vilje: virksomhedssuffikser gennem tunnelen, alt andet lokalt, og ingen overlapning mellem de to.
Browserens sikre DNS står uden for den politik, så hvis den skal være slået fra, for at profilen opfører sig forudsigeligt, skal du slå den fra for den profil og ikke for maskinen. Gør det i browserindstillingerne, ikke ved at redigere systemets resolver, så ændringen er synlig næste gang. Notér svaret, resolveren og forbindelsesstadiet på én linje for hver test. En rapport, der siger, at DNS fejlede på hotel-Wi-Fi, beskriver et symptom med mindst tre forskellige årsager.