Vert DNS-en til VPN-en din faktisk brukt? Fang port 53 og sjå

Spør dei fleste kva ein VPN-klient gjer med DNS, og dei seier han set resolveren, slik at spørjingar fer inni tunnelen. Pushet er ekte; føresetnaden om at det blir ei spørjing er det ikkje. Mellom eit pusht val og ein pakke på leiinga ligg tre trinn, og kvart trinn feilar uavhengig på måtar som alle ser ut som ein øydelagd DNS-tenar. Difor kan ei lekktestside og ein nettlesar som verkar vere usamde om same maskin i same augneblink.

Eit pusht val er ikkje ei spørjing

Trinn éin er at tenaren tilbyr innstillingar, til dømes eit pusht DNS-val som nemner ein resolver inne i tunnelen. Trinn to er at klienten brukar desse innstillingane på eit grensesnitt. Trinn tre er at eit program faktisk sender ei spørjing til den adressa. Ein feil i trinn to lèt valet stå synleg i sambandsloggen medan resolverlista er uendra, og ein feil i trinn tre lèt ei heilt korrekt resolverliste stå ubrukt.

Mesteparten av feilsøking slår dei tre saman til éin og gir VPN-tenaren skulda, som vanlegvis er den einaste parten som kan prove at han gjorde sin del. Les i staden den faktiske resolvertilstanden til klienten, og sjå så éi spørjing gå ut. Dei to observasjonane skil konfigurasjon frå ruting og frå policy, og dei kostar om lag fem minutt. Ta vare på opptaka, for den neste ingeniøren vil ha før og etter i staden for ei skildring av dei.

Sjekk kva grensesnittet faktisk held

På Linux kan systemresolveren vere den vanlege fila, NetworkManager eller systemd-resolved, og kven av dei som eig henne avgjer kvar ein pusht tenar landar. Ein OpenVPN-prosess på kommandolinja oppdaterer ikkje systemresolveren av seg sjølv, så den dokumenterte integrasjonen er eit up/down-skript eller ein sambandsbehandlar som alt veit korleis innstillingane skal brukast. Å køyre begge er ein effektiv måte å skape eit kappropp på.

resolvectl status
cat /etc/resolv.conf

På Windows er lista per adapter, så tunneladapteren kan halde dei interne tenarane medan den fysiske adapteren held dei lokale og vinn for nokre namn. Samanlikn begge adapterane i staden for den du trur er aktiv.

Følg éi spørjing ut av maskinen

Ta opp begge grensesnitta samstundes, og slå så opp eitt namn som skal bruke den interne resolveren. Det paret med opptak svarar på det ingen konfigurasjonsutskrift kan.

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

Ei spørjing som dukkar opp på det fysiske grensesnittet og aldri i tunnelen, tyder på at klienten valde feil resolver. Ei spørjing på ingen av dei tyder på at programmet svara frå hurtiglageret, spurde ein stub som lyttar på loopback, eller brukte ein kryptert resolver der trafikken aldri visest som port 53. Ta også opp svar, ikkje berre spørjingar, for ei spørjing som går ut gjennom tunnelen med eit svar frå ei open adresse er ein annan feil enn at det ikkje kjem noko svar.

Brannmuren som berre godtek sin eigen DNS

Kommersielle klientar installerer stundom eigne filterkjeder. Eitt dokumentert mønster lèt DNS til klienten sin eigen resolver og kastar all attverande UDP-trafikk på port 53 som prøver å forlate eit grensesnitt som ikkje er loopback, også trafikk brukaren med vilje har ruta ein annan stad. Daemon-spørjingar forsvinn sporlaust, noko som blir lese som ein resolverfeil og ikkje som eit filter.

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

Vert ein forkastingsregel vurdert før unntaket ditt, blir ein tilføydd regel aldri nådd, så set han inn på første plass og avgrens målet til resolveren du faktisk meiner.

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

Det unntaket er diagnostisk og ikkje policy. Er regelen til leverandøren med vilje, er den støtta reparasjonen å konfigurere klienten til å tillate den resolveren og registrere avgjerda, for ein innsett regel overlever ikkje neste klientoppgradering.

Kvifor ei lekkside provar mindre enn ho ser ut til

Det ei lekktestside viser, er resolveren som snakka med testoperatøren, ikkje den maskinen din spurde. Ein lokal vidaresendar som rekurserer utover set si eiga utgangsadresse på den sida, og krypterte spørjingar kan la sida stå heilt tom. Begge resultata blir lesne feil, det eine som lekkasje og det andre som garanti, og ingen av lesingane følgjer av observasjonen.

Det forsvarlege provet er opptaket: grensesnitt, måladdresse, svar og tidsstempel. Ta eitt før tunnelen kjem opp og eitt etter, og samanlikn dei neste gong eit namn feilar. Det paret fortel også den neste personen om feilen var i oppslag, ruting eller i resolveren sin eigen tilgangspolicy.