Bruges din VPN-DNS faktisk? Fang port 53 og se efter

Spørg de fleste, hvad en VPN-klient gør med DNS, og de siger, at den sætter resolveren, så forespørgsler rejser inde i tunnelen. Skubbet er ægte; antagelsen om, at det bliver en forespørgsel, er ikke. Mellem en skubbet indstilling og en pakke på ledningen ligger tre trin, og hvert trin fejler uafhængigt på måder, der alle ligner en defekt DNS-server. Derfor kan en læk-testside og en fungerende browser være uenige om den samme maskine i samme øjeblik.

En skubbet indstilling er ikke en forespørgsel

Første trin er, at serveren tilbyder indstillinger, for eksempel en skubbet DNS-indstilling, der peger på en resolver inde i tunnelen. Andet trin er, at klienten anvender de indstillinger på en grænseflade. Tredje trin er, at et program faktisk sender en forespørgsel til den adresse. En fejl i andet trin lader indstillingen stå synlig i forbindelsesloggen, mens resolverlisten forbliver uændret, og en fejl i tredje trin lader en helt korrekt resolverliste stå ubrugt.

Det meste fejlfinding slår de tre sammen til én og giver VPN-serveren skylden, som normalt er den eneste part, der kan bevise, at den gjorde sit. Læs i stedet klientens faktiske resolver-tilstand, og se så én forespørgsel forlade maskinen. De to observationer adskiller konfiguration fra routing fra politik, og de koster omkring fem minutter. Gem optagelserne, for den næste ingeniør vil have før og efter frem for en beskrivelse af dem.

Se, hvad grænsefladen faktisk indeholder

På Linux kan systemresolveren være den almindelige fil, NetworkManager eller systemd-resolved, og hvilken af dem der ejer den, afgør, hvor en skubbet server lander. En OpenVPN-proces fra kommandolinjen opdaterer ikke systemresolveren af sig selv, så den dokumenterede integration er et up/down-script eller en forbindelsesmanager, der allerede ved, hvordan indstillingerne anvendes. At køre begge er en effektiv måde at skabe et kapløb.

resolvectl status
cat /etc/resolv.conf

På Windows er listen for hver adapter, så tunneladapteren kan holde de interne servere, mens den fysiske adapter beholder de lokale og vinder for nogle navne. Sammenlign begge adaptere i stedet for den, du antager er aktiv.

Følg én forespørgsel ud af maskinen

Optag begge grænseflader samtidigt, og slå derefter et navn op, som bør bruge den interne resolver. Det par optagelser besvarer det, ingen konfigurationsudskrift kan.

sudo tcpdump -ni tun0 port 53
sudo tcpdump -ni any port 53

En forespørgsel, der dukker op på den fysiske grænseflade og aldrig i tunnelen, betyder, at klienten valgte den forkerte resolver. En forespørgsel på ingen af dem betyder, at programmet svarede fra cachen, spurgte en stub, der lytter på loopback, eller brugte en krypteret resolver, hvis trafik slet ikke vises som port 53. Optag også svar, ikke kun forespørgsler, for en forespørgsel, der forlader gennem tunnelen med et svar fra en offentlig adresse, er en anden fejl end ingen ankommende svar.

Firewallen, der kun accepterer sin egen DNS

Kommercielle klienter installerer nogle gange deres egne filterkæder. Et dokumenteret mønster tillader DNS til klientens egen resolver og kasserer al resterende UDP-trafik på port 53, der forsøger at forlade en grænseflade, som ikke er loopback, inklusive trafik, som brugeren med vilje har rutet andre steder hen. Dæmonforespørgsler forsvinder uden spor, hvilket læses som en resolverfejl snarere end som et filter.

sudo iptables -S OUTPUT
sudo iptables -S | grep -i -E 'dns|53'

Hvis en kasseringsregel vurderes før din undtagelse, nås en tilføjet regel aldrig, så indsæt den på første position og begræns destinationen til den resolver, du faktisk mener.

sudo iptables -I OUTPUT 1 -p udp --dport 53 -d 172.20.8.1 -j ACCEPT

Den undtagelse er diagnostisk snarere end politik. Hvis leverandørens regel er bevidst, er den understøttede reparation at konfigurere klienten til at tillade den resolver og registrere beslutningen, fordi en indsat regel ikke overlever den næste klientopdatering.

Hvorfor en læk-side beviser mindre, end den ser ud til

Hvad en læk-testside viser, er den resolver, der talte med testoperatøren, ikke den, din maskine spurgte. En lokal videresender, der rekurserer udad, sætter sin egen udgangsadresse på den side, og krypterede forespørgsler kan lade siden stå helt tom. Begge resultater læses forkert, det ene som en lækage og det andet som en garanti, og ingen af læsningerne følger af observationen.

Det forsvarlige bevis er optagelsen: grænseflade, destinationsadresse, svar og tidsstempel. Tag en, før tunnelen kommer op, og en efter, og sammenlign dem næste gang, et navn fejler. Det par fortæller også den næste person, om fejlen var opløsning, routing eller resolverens egen adgangspolitik.