DNS slår ikke opp når VPN-killswitchen blokkerer port 53
En killswitch kan blokkere DNS med vilje. Sammenlign oppslag bare i tunnelen med et unntak for en lokal resolver, og finn deretter ut hvilket lag som faktisk sviktet.
Når killswitchen slipper tunnelen, tar den DNS-stien med seg, og resolveren som blir igjen er sjelden den du forventer. To design håndterer det øyeblikket svært ulikt: blokker hver DNS-pakke som ikke er inne i tunnelen, eller la én resolver stå som unntak. Begge er forsvarlige. Fra en nettleserfane ser symptomene nesten identiske ut, så den første oppgaven er å finne ut hvilket design du faktisk har rullet ut.
Jeg holder den forskjellen for øyet fordi rettelsen er motsatt i hvert tilfelle. Det ene designet trenger et bredere unntak, det andre et smalere. Gjetting koster deg enten personvern eller en ettermiddag.
To DNS-design for samme utfall
Design A behandler resolveren som enda en tjeneste bak tunnelen. Brannmurregler tillater UDP og TCP 53 bare på tunnelegrensesnittet, og adressen klienten får er en resolver inne i tunnelen. Når tunnelen faller, stopper oppslagene, og det er det tilsiktede resultatet, ikke en feil.
Design B holder en resolver tilgjengelig på det lokale nettet, vanligvis ruteren på 192.168.1.1 eller operativsystemets stub på 127.0.0.53, ut fra at navneoppslag ikke bør dø med tunnelen. Det er praktisk på et hjemme-LAN der ruteren slår opp for hele huset. På Wi-Fi på hotell eller flyplass peker det samme unntaket på noen andres server, og hvert navn du skriver inn blir avslørt, selv om netttrafikken din forblir blokkert.
Grensen går ved hvem som eier resolveren. Stoler du på den lokale, er et unntak et lite, ærlig hull. Gjør du ikke det, er kun-tunnel-designet det eneste som holder, og prisen er at en falt tunnel tar alle navn med seg.
Hvorfor VPN-klientens eget oppslag fortsatt virker
Klienten må slå opp vertsnavnet til gatewayen før det finnes en tunnel, så en streng blokkering må ikke dekke klientens oppstartssti. De fleste klienter bufrer endepunktsadressen eller leverer et dokumentert oppstartsunntak for nettopp den ene verten. Blokkerer regelsettet ditt det oppslaget, kommer tunnelen aldri tilbake, og loggene viser en klient som ikke når sin egen server; det er en politikfeil og ikke en DNS-feil.
Delt DNS er det andre stedet hvor dette dukker opp. Klienten skyver en intern sone til en privat resolver og lar alt annet ligge hos systemresolveren. Etter et utfall kan offentlige navn fortsatt slås opp mens interne navn går ut på tid, fordi den private sonen ikke har noen rute igjen. For brukeren er det "VPN-en ødela internett"; for resolverloggen er det en forespørsel som aldri kom fram.
Under systemd-resolved kan du se delingen direkte.resolvectl status viser DNS-serverne per lenke og rutingsdomenene, og etter at tunnelen går ned, peker det interne domenet fortsatt på en server på en lenke som ikke finnes lenger. Stubben på 127.0.0.53 tar fortsatt imot forespørselen, og venter deretter på et oppstrøms som ikke vil svare, og derfor tar feilen sekunder i stedet for å komme tilbake med en gang.
Kryptert DNS kommer ikke rundt et pakkefilter
DNS over HTTPS og DNS over TLS går over 443 og 853, så en regel som blokkerer port 53 ikke har sagt noe om dem. Å blokkere "DNS" etter port er en politikk om en port, ikke om navneoppslag. Hvis killswitchen blokkerer all trafikk utenfor tunnelen, er DoH dekket ved et uhell. Hvis du har laget et unntak for en captive portal eller en offentlig resolver, er den ikke det.
Styringer på klientsiden er den billigere spaken. Firefox gir opp sin DoH-resolver når kanarifuglnavnet use-application-dns.net ikke slår opp, og derfor publiserer administrerte nett det domenet som NXDOMAIN; en bedriftspolicy kan også låse det av. Android Private DNS og Chromes sikre DNS har egne brytere og egne standardverdier. Å slå dem av er mer pålitelig enn å jage resolveradresser, fordi adresselisten endres og regelsettet ditt ikke gjør det.
Det finnes en versjon av dette som ikke handler om lekkasjer i det hele tatt. En applikasjon med en fastlåst resolver trenger fortsatt en nettverkssti for å nå den. Kryptering endrer hvem som kan lese forespørselen, ikke om pakken kan forlate maskinen, så en blokkering for hele enheten beseirer innstillingen uten å røre den.
Koble symptomet til laget
De fleste rapporter kommer som én setning, og den setningen navngir vanligvis laget allerede. Tabellen nedenfor er det jeg går gjennom før jeg rører en regel; poenget er å avgjøre om forespørselen ble blokkert, feilrutet eller aldri sendt.
| 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 to første radene er dem folk feildiagnostiserer. Et stille fall og en avvisning ser begge ut som "DNS er ødelagt" i en nettleser, men bare én av dem betyr at killswitchen gjør jobben sin. En avvisning betyr at noe svarte, så blokkeringen er ikke der du tror.
Gjenopprett resolverpolitikken, og bevis den
Rett på designet, ikke symptomet. For oppslag bare i tunnelen, tillat 53 på tunnelegrensesnittet, skyv den interne resolveren ut med tunnelkonfigurasjonen og la den fysiske lenken stå uten noen DNS-tillatelse. Med wg-quick er linjen DNS = den som skriver resolveren inn i grensesnittkonfigurasjonen, så en tunnel som utelater den, lar den gamle resolveren bli stående og hver forespørsel går på feil sti.wg-quick-håndboken dokumenterer den oppførselen per plattform.
Kontroller deretter i denne rekkefølgen. På Linux viser resolvectl status den aktive lenken,dig +short example.com tester et offentlig navn,dig @10.8.0.1 internal.example.com tester det private, og sudo tcpdump -ni any port 53 viser hvilket grensesnitt pakkene bruker mens du kjører begge. På Windows gir Get-DnsClientServerAddress -AddressFamily IPv4 og Resolve-DnsName example.com de samme to fakta: hvem som er konfigurert, og hvem som svarer.
Avslutt med den negative testen. Koble fra tunnelen, bekreft at et ferskt offentlig navn feiler, bekreft at det private navnet feiler, og bekreft at ingen port 53-pakke forlot den fysiske adapteren. En blokkering som bare holder for bufrede svar, holder ikke i det hele tatt.
Sjekkliste før du lukker saken:
- Resolveren som ble brukt under utfallet, er den politikken mener.
- Klientens eget endepunktsoppslag er fortsatt tillatt, via buffer eller unntak.
- DoH og DoT er enten dekket av blokkeringen eller slått av etter politikk.
- Private soner feiler lukket, ikke åpent, når tunnelen er borte.