Brukes DNS-en til VPN-en din faktisk? Fang port 53 og se

Spør de fleste hva en VPN-klient gjør med DNS, og de sier den setter resolveren, slik at spørringer reiser inne i tunnelen. Pushet er ekte; antakelsen om at det blir en spørring er det ikke. Mellom et pushet alternativ og en pakke på ledningen ligger tre trinn, og hvert trinn feiler uavhengig på måter som alle ser ut som en ødelagt DNS-server. Derfor kan en lekktestside og en fungerende nettleser være uenige om samme maskin i samme øyeblikk.

Et pushet alternativ er ikke en spørring

Trinn én er at serveren tilbyr innstillinger, for eksempel et pushet DNS-alternativ som navngir en resolver inne i tunnelen. Trinn to er at klienten bruker disse innstillingene på et grensesnitt. Trinn tre er at et program faktisk sender en spørring til den adressen. En feil i trinn to lar alternativet stå synlig i tilkoblingsloggen mens resolverlisten forblir uendret, og en feil i trinn tre lar en helt korrekt resolverliste stå ubrukt.

Det meste av feilsøking slår de tre sammen til ett og gir VPN-serveren skylden, som vanligvis er den eneste parten som kan bevise at den gjorde sin del. Les i stedet klientens faktiske resolver-tilstand, og se så én spørring gå ut. De to observasjonene skiller konfigurasjon fra ruting og fra policy, og de koster omtrent fem minutter. Ta vare på opptakene, for den neste ingeniøren vil ha før og etter i stedet for en beskrivelse av dem.

Sjekk hva grensesnittet faktisk holder

På Linux kan systemresolveren være den vanlige filen, NetworkManager eller systemd-resolved, og hvilken av dem som eier den avgjør hvor en pushet server lander. En OpenVPN-prosess på kommandolinjen oppdaterer ikke systemresolveren av seg selv, så den dokumenterte integrasjonen er et up/down-skript eller en tilkoblingsbehandling som allerede vet hvordan innstillingene brukes. Å kjøre begge er en effektiv måte å skape et kappløp.

resolvectl status
cat /etc/resolv.conf

På Windows er listen per adapter, så tunneladapteren kan holde de interne serverne mens den fysiske adapteren beholder de lokale og vinner for noen navn. Sammenlign begge adapterne i stedet for den du antar er aktiv.

Følg én spørring ut av maskinen

Ta opp begge grensesnittene samtidig, og slå deretter opp ett navn som skal bruke den interne resolveren. Det paret med opptak svarer på det ingen konfigurasjonsutskrift kan.

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

En spørring som dukker opp på det fysiske grensesnittet og aldri i tunnelen, betyr at klienten valgte feil resolver. En spørring på ingen av dem betyr at programmet svarte fra hurtigbufferen, spurte en stub som lytter på loopback, eller brukte en kryptert resolver der trafikken aldri vises som port 53. Ta også opp svar, ikke bare spørringer, for en spørring som går ut gjennom tunnelen med et svar fra en offentlig adresse er en annen feil enn at det ikke kommer noe svar.

Brannmuren som bare godtar sin egen DNS

Kommersielle klienter installerer noen ganger egne filterkjeder. Ett dokumentert mønster tillater DNS til klientens egen resolver og kaster all gjenværende UDP-trafikk på port 53 som prøver å forlate et grensesnitt som ikke er loopback, inkludert trafikk brukeren bevisst har rutet et annet sted. Daemon-spørringer forsvinner sporløst, noe som leses som en resolverfeil og ikke som et filter.

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

Hvis en forkastningsregel vurderes før unntaket ditt, nås en tilføyd regel aldri, så sett den inn på første plass og begrens målet til resolveren du faktisk mener.

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

Det unntaket er diagnostisk og ikke policy. Hvis leverandørens regel er bevisst, er den støttede reparasjonen å konfigurere klienten til å tillate den resolveren og registrere beslutningen, for en innsatt regel overlever ikke neste klientoppgradering.

Hvorfor en lekkside beviser mindre enn den ser ut til

Det en lekktestside viser, er resolveren som snakket med testoperatøren, ikke den maskinen din spurte. En lokal videresender som rekurserer utover setter sin egen utgangsadresse på den siden, og krypterte spørringer kan la siden stå helt tom. Begge resultatene leses feil, det ene som lekkasje og det andre som garanti, og ingen av lesningene følger av observasjonen.

Det forsvarlige beviset er opptaket: grensesnitt, måladdresse, svar og tidsstempel. Ta ett før tunnelen kommer opp og ett etter, og sammenlign dem neste gang et navn feiler. Det paret forteller også den neste personen om feilen var i oppslag, ruting eller resolverens egen tilgangspolicy.