openfortivpn overskriver hele tiden DNS? Finn den virkelige eieren

Følg forbindelsen fra det øyeblikket den kommer opp: klienten autentiserer, pppd forhandler, og deretter skriver noe DNS-innstillinger inn i operativsystemet. Hvis du bare vet at VPN-en endret resolveren din, vet du ennå ikke hvilket av disse trinnene som gjorde det. To av dem kan, og på en klient med den dokumenterte pppd-integrasjonen kjører de tett nok sammen til å se ut som én aktør. Å navngi skriveren er det første trinnet; å velge erstatningen er det andre, og det er en egen beslutning med sine egne feilmoduser.

Rekkefølgen nedenfor følger klienten utover: hva forbindelsen endret, hvilken bryter som demper hvilken skriver, hvem som skal overta, og hvordan du bekrefter at resultatet overlever en gjentilkobling. Hvert trinn etterlater et ulikt spor, og sporet er det som forteller deg om overleveringen faktisk skjedde.

Start med hva forbindelsen faktisk endret

Koble til én gang med din vanlige kommando og sammenlign oppslaget før og etter. På en Linux-vert med systemd-resolved skriver resolvectl status ut DNS-servere og søkedomener per forbindelse, og en ny tun- eller ppp-forbindelse med egne servere er fingeravtrykket til en oppdatering fra klientsiden. På macOS viser scutil --dns resolverkonfigurasjonen i den rekkefølgen programmene konsulterer den.

Sammenlign det med filen du forventet ville endre seg. En forbindelsesbundet oppføring i visningen per forbindelse og en omskrevet /etc/resolv.conf er to ulike utfall, og det andre kan være en symbolsk lenke som noe helt annet styrer. Noter resolveradressen, søkedomenene og grensesnittnavnet i samme øyeblikk; en endring i hvilken som helst av dem peker på en annen skriver. Uten den grunnlinjen er hver senere rettelse et gjetning om hvilken av tre komponenter som flyttet seg.

De to bryterne og skriveren hver av dem demper

openfortivpn dokumenterer et valgfragment som slår av begge skriverne den kan kontrollere, og hver bryter har en fullt utskrevet ekvivalent som håndboken behandler som samme 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 hindrer klienten i å anvende DNS-serverne den lærte fra gatewayen, mens --pppd-no-peerdns hindrer pppd i å skyve peer-DNS inn i systemet. Håndboken for upstream advarer om at DNS-oppdateringer over PPP kan kappes med klientens egne DNS-oppdateringer, og derfor hører begge bryterne i fragmentet i stedet for at noen av dem regnes som tilstrekkelig.

Ingen av bryterne navngir en erstatningsresolver, og ingen av dem hindrer en nettverksbehandler, en DHCP-klient eller en separat VPN-integrasjon i å skrive oppslag etterpå. Å dempe to skrivere lar feltet stå åpent snarere enn eid. Hvis en tredje komponent allerede styrer DNS, endrer fragmentet ingenting du kan observere; hvis ingenting styrer det, har du nettopp fjernet den eneste kilden til privat navneoppslag. Det er bare en gyldig ordning når erstatningseieren ble valgt først og testet alene.

Velg eieren før du deaktiverer noe

Avgjør først hvem som svarer på spørringer om arbeidsnavn, fordi det valget begrenser alt som kommer etter. Å beholde den eksisterende resolveren betyr at den private sonen allerede må være nåbar fra der klienten sitter, og en privat resolver inne på kontoret trenger en rute som overlever at tunnelen kommer opp. Å sende hver spørring til én intern tjeneste er en tredje policy med en skarpere feilmodus: når den tjenesten ikke er nåbar, feiler offentlige navn sammen med de private.

Ruteeierskap holdes adskilt med vilje. Rutevalgene er ikke påkrevd fordi du endret DNS, og å slå av ruteinstallasjon uten å installere en erstatning kan gjøre resolveren du nettopp valgte, unåelig. Kontroller rutetabellen spesifikt for resolveradressen, ikke bare for applikasjonssubnettet du tilfeldigvis testet.

Kontroller oppslaget per forbindelse, ikke per fil

En enkelt /etc/resolv.conf er ikke en oversikt over hva programmer faktisk bruker på en vert med begrenset eller per-domene-oppslag, så les resolverens tilstand slik plattformen viser den.

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

Spør etter ett privat navn og ett offentlig navn når forbindelsen er oppe, og noter hvilken forbindelse som svarte på hvert. Der VPN-forbindelsen bærer en søkeliste per domene, kan et privat navn slås opp riktig mens et offentlig navn fortsatt går til den lokale resolveren, og den delingen er designet som virker, ikke en feil. Hvis den private spørringen feiler, undersøk ruten til resolveren før du rører DNS igjen; hvis den lykkes mens et program fortsatt feiler, leser programmet kanskje sin egen bufrede eller separat konfigurerte resolver.

Koble til på nytt og bekreft den frakoblede tilstanden

Ta forbindelsen ned og gjenta begge spørringene. Det den valgte eieren installerte, skal fjernes eller gjenopprettes av den eieren, ikke etterlates av klienten du dempet. En utdatert oppføring per forbindelse som overlever tunnelen, fortsetter å sende private spørringer til en adresse som ikke lenger er nåbar.

Koble så til på nytt og les de samme tre verdiene igjen: resolveradresse, søkedomener, grensesnitt.

Hvis de samsvarer med policyen du skrev ned, er overleveringen fullført og VPN-klienten er ikke lenger en av skriverne. Hvis en verdi driver tilbake noen sekunder etter at forbindelsen kom opp, anvender noe annet fortsatt konfigurasjon, og neste trinn er å identifisere den komponenten i stedet for å legge til nok et flagg. Sluttilstanden du ønsker er hendelsesfri: én eier, én dokumentert policy og en frakoblet vert som slår opp nøyaktig som før tunnelen fantes.