DNS löser inte ut när VPN-killswitchen blockerar port 53
En killswitch kan blockera DNS med avsikt. Jämför uppslag bara i tunneln med ett undantag för en lokal resolver och ta sedan reda på vilket lager som faktiskt svek.
När killswitchen släpper tunneln tar den DNS-vägen med sig, och resolvern som blir kvar är sällan den du förväntar dig. Två konstruktioner hanterar det ögonblicket mycket olika: blockera varje DNS-paket som inte ligger i tunneln, eller låta en resolver stå kvar som undantag. Båda går att försvara. Från en webbläsarflik ser symptomen nästan identiska ut, så den första uppgiften är att ta reda på vilken konstruktion du faktiskt rullade ut.
Jag håller den skillnaden framför mig eftersom åtgärden är motsatt i varje fall. Den ena konstruktionen behöver ett vidare undantag, den andra ett snävare. Gissningar kostar dig antingen integritet eller en eftermiddag.
Två DNS-konstruktioner för samma avbrott
Konstruktion A behandlar resolvern som ännu en tjänst bakom tunneln. Brandväggsregler tillåter UDP och TCP 53 bara på tunnelns gränssnitt, och adressen klienten får är en resolver inne i tunneln. När tunneln faller stannar uppslagen, och det är det avsedda resultatet, inte ett fel.
Konstruktion B håller en resolver nåbar på det lokala nätet, oftast routern på 192.168.1.1 eller operativsystemets stub på 127.0.0.53, med motiveringen att namnuppslag inte borde dö med tunneln. Det är bekvämt på ett hemmanät där routern löser ut åt hela huset. På Wi-Fi på hotell eller flygplats pekar samma undantag på någon annans server, och varje namn du skriver avslöjas, även om din webbtrafik förblir blockerad.
Gränsen går vid vem som äger resolvern. Litar du på den lokala är ett undantag ett litet, ärligt hål. Gör du inte det är bara-tunnel-konstruktionen den enda som håller, och priset är att en fallen tunnel tar alla namn med sig.
Varför VPN-klientens eget uppslag fortfarande fungerar
Klienten måste lösa ut gatewayens värdnamn innan det finns en tunnel, så en strikt blockering får inte täcka klientens startväg. De flesta klienter cachar antingen slutpunktens adress eller levererar ett dokumenterat startundantag för just den värden. Blockerar din regeluppsättning det uppslaget kommer tunneln aldrig tillbaka och loggarna visar en klient som inte når sin egen server, vilket är ett policyfel och inte ett DNS-fel.
Delad DNS är den andra platsen där detta dyker upp. Klienten skjuter en intern zon till en privat resolver och lämnar allt annat till systemresolvern. Efter ett avbrott kan publika namn fortfarande lösas ut medan interna får timeout, eftersom den privata zonen inte har någon väg kvar. För användaren är det "VPN:en förstörde internet"; för resolverloggen är det en fråga som aldrig kom fram.
Under systemd-resolved ser du delningen direkt. resolvectl status listar DNS-servrarna per länk och routningsdomänerna, och när tunneln gått ner pekar den interna domänen fortfarande på en server på en länk som inte finns längre. Stubben på 127.0.0.53 tar fortfarande emot frågan och väntar sedan på ett upstream som inte kommer att svara, och därför tar felet sekunder i stället för att återvända direkt.
Krypterad DNS tar sig inte förbi ett paketfilter
DNS over HTTPS och DNS over TLS går över 443 och 853, så en regel som blockerar port 53 har inte sagt något om dem. Att blockera "DNS" per port är en policy om en port, inte om namnuppslag. Om din killswitch blockerar all trafik utanför tunneln täcks DoH av misstag. Har du gjort undantag för en captive portal eller en publik resolver gör den inte det.
Styrning på klientsidan är den billigare hävstången. Firefox överger sin DoH-resolver när kanariefågelsnamnet use-application-dns.net inte löses ut, och därför publicerar hanterade nät den domänen som NXDOMAIN; företagspolicy kan också låsa den avstängd. Android Private DNS och Chromes säkra DNS har egna reglage och egna standardvärden. Att stänga av dem är mer tillförlitligt än att jaga resolveradresser, eftersom adresslistan ändras och din regeluppsättning inte gör det.
Det finns en version av detta som inte alls handlar om läckage. Ett program med en fastnålad resolver behöver fortfarande en nätverksväg för att nå den. Kryptering ändrar vem som kan läsa frågan, inte om paketet kan lämna maskinen, så en blockering för hela enheten besegrar inställningen utan att röra den.
Koppla symptomet till lagret
De flesta rapporter kommer som en enda mening, och den meningen namnger oftast redan lagret. Tabellen nedan är vad jag går igenom innan jag rör en regel; poängen är att avgöra om frågan blockerades, styrs fel eller aldrig skickades.
| Symptom | Likely layer | First check |
|---|---|---|
| Every name fails at once, instantly | Resolver answering with a refusal | Query the resolver by address, not by name |
| Lookups hang for seconds, then time out | Packets dropped with no response | Watch port 53 on the physical link |
| Public names resolve, internal ones do not | Split-DNS routing domain | Per-link DNS servers on the tunnel |
| Names resolve, the page still fails | Not DNS: routing or MTU | Connect to the IP directly |
| Only one application fails | Pinned resolver or cached answer | Check that app's DNS setting |
De två första raderna är de som folk feldiagnostiserar. Ett tyst fall och en vägran ser båda ut som "DNS är trasigt" i en webbläsare, men bara en av dem betyder att din killswitch gör sitt jobb. En vägran betyder att något svarade, så blockeringen är inte där du tror.
Återställ resolverpolicyn och bevisa den sedan
Rätta konstruktionen, inte symptomet. För uppslag bara i tunneln, tillåt 53 på tunnelns gränssnitt, skjut ut den interna resolvern med tunnelkonfigurationen och lämna den fysiska länken utan någon DNS-tillåtelse. Med wg-quick är det raden DNS = som skriver resolvern till gränssnittets konfiguration, så en tunnel som utelämnar den lämnar den gamla resolvern på plats och varje fråga på fel väg. wg-quick-handboken dokumenterar det beteendet per plattform.
Kontrollera sedan i den här ordningen. På Linux visar resolvectl status den aktiva länken, dig +short example.com testar ett publikt namn, dig @10.8.0.1 internal.example.com testar det privata, och sudo tcpdump -ni any port 53 visar vilket gränssnitt paketen använder medan du kör båda. På Windows ger Get-DnsClientServerAddress -AddressFamily IPv4 och Resolve-DnsName example.com samma två fakta: vem som är konfigurerad och vem som svarar.
Avsluta med det negativa testet. Koppla från tunneln, bekräfta att ett färskt publikt namn misslyckas, bekräfta att det privata namnet misslyckas, och bekräfta att inget port 53-paket lämnade den fysiska adaptern. En blockering som bara håller för cachade svar håller inte alls.
Checklista innan du stänger ärendet:
- Resolvern som användes under avbrottet är den som policyn avser.
- Klientens eget slutpunktsuppslag är fortfarande tillåtet, via cache eller undantag.
- DoH och DoT täcks antingen av blockeringen eller är avstängda enligt policy.
- Privata zoner misslyckas stängda, inte öppna, när tunneln är borta.