Varför omdirigerar ett hotspot DNS innan VPN:et ansluter?
Ett hotspot skriver om sökningar i sitt eget nätverk, och en värdnamnsslutpunkt löses upp innan någon tunnel existerar. Spåra vilken resolver som svarade på varje fråga.
Att ansluta till ett hotellnätverk ställer två DNS-beslut framför dig vid olika tillfällen: de sökningar enheten gör vid inloggning, och de sökningar som görs när tunneln är uppe. Ett hotspot kan påverka de första via nätverket det kontrollerar. De andra beror på klientens egen policy, vilket är något eget att undersöka.
Gå igenom anslutningen i ordning, från den första DHCP-leasen till frågan som löste upp ett privat namn. Då skiljs två fel som ser identiska ut i en supportbiljett rent: det ena hände innan tunneln fanns, det andra hände inuti den.
Vad hotspotet kan och inte kan röra
Åtkomstnätet delar ut en resolveradress i DHCP och kan avlyssna port 53 mot den adressen. Det räcker för att besvara varje oskyddad sökning med en portaladress eller en blockeringssida. Det räcker också för att bryta en VPN-klient vars slutpunkt är skriven som ett värdnamn.
Det hotspotet inte kan är att läsa eller skriva om en fråga när den väl färdas inne i en etablerad tunnel, förutsatt att tunneln verkligen bär den. Avlyssning bygger på att se frågan i klartext.
Frågorna lämnar ändå tunneln av skäl som inte har med hotspotet att göra: webbläsarens säkra DNS-inställning, en split-DNS-regel som håller ett företagssuffix hos den lokala resolvern, eller en klient konfigurerad att utesluta DNS från tunneln. Vart och ett är ett val på klientsidan, och vart och ett ser ut som hotspotstörning när man tittar utifrån.
| 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 |
Den första sökningen sker innan tunneln finns
En klient som får ett värdnamn måste först lösa upp det, och i det ögonblicket skyddar ingen tunnel frågan. Svarar hotspotet med en portaladress misslyckas förhandlingen eller hänger sig. Svarar det med ingenting rapporterar klienten ett namnfell och tunneln startar aldrig. Båda utfallen förklarar en tom tunnellogg som annars ser oskyldig ut.
Operativsystem kör också egna anslutningskontroller och portalupptäckt, beskrivna i RFC 8910 och RFC 8952, och dessa förfrågningar går ut innan någon VPN är uppe. Att se dem i en proxylogg är förväntat beteende och inte bevis på en läcka.
Den praktiska lösningen är att ge klienten en slutpunkt som inte behöver någon sökning. När det är omöjligt, slutför inloggningen först och anslut efteråt.
Ta reda på vilken resolver som svarade
Fråga systemet och inte webbläsaren, och kör frågan två gånger: en gång genom vilken resolver enheten använder nu, en gång mot en fast adress.
resolvectl query vpn.example.com dig +short vpn.example.com dig +short vpn.example.com @1.1.1.1
Ett svar från det första kommandot som skiljer sig från det tredje säger att den lokala resolvern returnerar något annat, vilket är precis vad ett omdirigerande hotspot gör. Ett fel från det tredje tillsammans med en framgång från det första pekar på portalen: den lokala resolvern levererade en inloggningsadress medan den utgående porten 53 kastades. Tidsgränser på båda betyder att nätverket kastar DNS tills autentiseringen är klar.
Upprepa efter anslutning och jämför. Ett cachat svar överlever övergången, så töm cachen eller fråga efter ett nytt namn för den andra observationen.
Håll senare sökningar på den väg du avsåg
En fulltunnelprofil som också fångar DNS är den enklaste ordningen: varje fråga från varje program går till resolvern som tunneln skjuter fram, och det lokala nätverket ser bara krypterad trafik. Bevisa det genom att lösa upp ett internt och ett offentligt namn efter anslutningen och sedan jämföra båda svaren med vad tunnelresolvern returnerar på egen hand.
Split-DNS behöver en domänlista skriven med avsikt: företagssuffix genom tunneln, allt annat lokalt, och ingen överlappning mellan de två.
Webbläsarens säkra DNS står utanför den policyn, så om den måste vara av för att profilen ska bete sig förutsägbart, stäng av den för den profilen och inte för maskinen. Gör det i webbläsarens inställningar, inte genom att redigera systemresolvern, så att ändringen syns nästa gång. Anteckna svaret, resolvern och anslutningsfasen på en rad per test. En rapport som säger att DNS misslyckades på hotell-Wi-Fi beskriver ett symptom med minst tre olika orsaker.