openfortivpn skriv heile tida over DNS? Finn den verkelege eigaren

Følg sambandet frå det augneblinken det kjem opp: klienten autentiserer, pppd forhandlar, og deretter skriv noko DNS-innstillingar inn i operativsystemet. Viss du berre veit at VPN-en endra resolvaren din, veit du enno ikkje kva av desse trinna som gjorde det. To av dei kan, og på ein klient med den dokumenterte pppd-integreringa køyrer dei tett nok saman til å sjå ut som éin aktør. Å namngje skrivaren er det første trinnet; å velje erstattaren er det andre, og det er eit eige vedtak med sine eigne feilmodusar.

Rekkjefølgja nedanfor følgjer klienten utover: kva sambandet endra, kva brytar som dempar kva skrivar, kven som skal ta over, og korleis du stadfestar at resultatet overlever ein gjenoppkopling. Kvart trinn etterlet eit ulikt spor, og sporet er det som fortel deg om overleveringa faktisk skjedde.

Start med kva sambandet faktisk endra

Kople til éin gong med den vanlege kommandoen din og samanlikn oppslaget før og etter. På ein Linux-vert med systemd-resolved skriv resolvectl status ut DNS-tenarar og søkjedomene per samband, og eit nytt tun- eller ppp-samband med eigne tenarar er fingeravtrykket til ei oppdatering frå klientsida. På macOS viser scutil --dns resolverkonfigurasjonen i den rekkjefølgja programma rådspør han.

Samanlikn det med fila du venta ville endre seg. Ei sambandsbunden oppføring i visinga per samband og ein omskriven /etc/resolv.conf er to ulike utfall, og det andre kan vere ei symbolsk lenkje som noko heilt anna styrer. Noter resolveradressa, søkjedomena og grensesnittnamnet i same augneblink; ei endring i kva som helst av dei peikar på ein annan skrivar. Utan den grunnlinja er kvar seinare retting eit gjetting om kva av tre komponentar som flytta seg.

Dei to brytarane og skrivaren kvar av dei dempar

openfortivpn dokumenterer eit valfragment som slår av båe skrivarane det kan kontrollere, og kvar brytar har ein fullt utskriven ekvivalent som handboka behandlar som same innstilling.

openfortivpn gw.example.com:443 --no-dns --pppd-no-peerdns
# written out in long form
openfortivpn gw.example.com:443 --set-dns=0 --pppd-use-peerdns=0

--no-dns hindrar klienten i å bruke DNS-tenarane han lærte frå gatewayen, medan --pppd-no-peerdns hindrar pppd i å skyve peer-DNS inn i systemet. Handboka for upstream åtvara om at DNS-oppdateringar over PPP kan kappast med klienten sine eigne DNS-oppdateringar, og difor høyrer båe brytarane i fragmentet i staden for at nokon av dei blir rekna som tilstrekkeleg.

Ingen av brytarane namngjev ein erstatningsresolver, og ingen av dei hindrar ein nettverkshandsamar, ein DHCP-klient eller ein separat VPN-integrasjon i å skrive oppslag etterpå. Å dempe to skrivarar lèt feltet stå ope snarare enn eigd. Viss ein tredje komponent alt styrer DNS, endrar fragmentet ingenting du kan sjå; viss ingenting styrer det, har du nettopp fjerna den einaste kjelda til privat namneoppslag. Det er berre ei gyldig ordning når erstatningseigaren vart vald først og testa åleine.

Vel eigaren før du deaktiverer noko

Avgjer først kven som svarar på spørjingar om arbeidsnamn, fordi det valet avgrensar alt som kjem etter. Å halde den eksisterande resolvaren tyder at den private sona alt må vere nåbar frå der klienten sit, og ein privat resolver inne på kontoret treng ei rute som overlever at tunnelen kjem opp. Å sende kvar spørjing til éin intern teneste er ein tredje politikk med ein skarpare feilmodus: når den tenesta ikkje er nåbar, feilar offentlege namn saman med dei private.

Ruteeigarskap blir halde åtskilt med vilje. Rutevala er ikkje påkravde fordi du endra DNS, og å slå av ruteinstallasjon utan å installere ein erstatning kan gjere resolvaren du nettopp valde, unåbar. Kontroller rutetabellen spesifikt for resolveradressa, ikkje berre for applikasjonssubnettet du tilfeldigvis testa.

Kontroller oppslaget per samband, ikkje per fil

Ein einaste /etc/resolv.conf er ikkje ei oversikt over kva program faktisk brukar på ein vert med avgrensa eller per-domene-oppslag, så les tilstanden til resolvaren slik plattforma viser han.

resolvectl status
resolvectl query vpn.internal.example.com
resolvectl query example.com
ip route get 10.20.0.53

Spør etter eitt privat namn og eitt offentleg namn når sambandet er oppe, og noter kva samband som svara på kvart. Der VPN-sambandet ber ei søkjeliste per domene, kan eit privat namn slåast opp rett medan eit offentleg namn framleis går til den lokale resolvaren, og den delinga er designet som verkar, ikkje ein feil. Viss den private spørjinga feilar, undersøk ruta til resolvaren før du rører DNS igjen; viss ho lykkast medan eit program framleis feilar, les programmet kanskje sin eigen bufra eller separat konfigurerte resolver.

Kople til på nytt og stadfest den fråkopla tilstanden

Ta sambandet ned og gjer om båe spørjingane. Det den valde eigaren installerte, skal fjernast eller gjenopprettast av den eigaren, ikkje etterlatast av klienten du dempa. Ei utdatert oppføring per samband som overlever tunnelen, held fram med å sende private spørjingar til ei adresse som ikkje lenger er nåbar.

Kople så til på nytt og les dei same tre verdiane igjen: resolveradresse, søkjedomene, grensesnitt.

Viss dei svarar til politikken du skreiv ned, er overleveringa fullført og VPN-klienten er ikkje lenger ein av skrivarane. Viss ein verdi driv tilbake nokre sekund etter at sambandet kom opp, brukar noko anna framleis konfigurasjon, og neste steg er å identifisere den komponenten i staden for å leggje til endå eit flagg. Sluttilstanden du ønskjer er hendingsfri: éin eigar, éin dokumentert politikk og ein fråkopla vert som slår opp nøyaktig som før tunnelen fanst.