openfortivpn overskriver hele tiden DNS? Find den rigtige ejer

Følg forbindelsen fra det øjeblik, den kommer op: klienten godkender, pppd forhandler, og derefter skriver noget DNS-indstillinger ind i operativsystemet. Hvis du kun ved, at VPN'en ændrede din resolver, ved du endnu ikke, hvilket af disse trin der gjorde det. To af dem kan, og på en klient med den dokumenterede pppd-integration kører de tæt nok sammen til at ligne én aktør. At navngive skriveren er det første skridt; at vælge dens erstatning er det andet, og det er en separat beslutning med sine egne fejltilstande.

Sekvensen nedenfor følger klienten udad: hvad forbindelsen ændrede, hvilken kontakt der dæmper hvilken skriver, hvem der skal overtage, og hvordan du bekræfter, at resultatet overlever en genopkobling. Hvert trin efterlader et forskelligt spor, og sporet er det, der fortæller dig, om overdragelsen faktisk skete.

Start med hvad forbindelsen faktisk ændrede

Forbind én gang med din sædvanlige kommando, og sammenlign opslaget før og efter. På en Linux-vært med systemd-resolved udskriver resolvectl status DNS-servere og søgedomæner pr. forbindelse, og en ny tun- eller ppp-forbindelse med sine egne servere er fingeraftrykket på en opdatering fra klientsiden. På macOS viser scutil --dns resolverkonfigurationen i den rækkefølge, programmerne konsulterer den.

Sammenlign det med den fil, du forventede ville ændre sig. En forbindelsesbundet post i visningen pr. forbindelse og en omskrevet /etc/resolv.conf er to forskellige udfald, og det andet kan være et symbolsk link, som noget helt andet styrer. Notér resolveradressen, søgedomænerne og grænsefladenavnet i samme øjeblik; en ændring i blot én af dem peger på en anden skriver. Uden den baseline er hver senere rettelse et gæt på, hvilken af tre komponenter der flyttede sig.

De to kontakter og den skriver, hver af dem dæmper

openfortivpn dokumenterer et valgmulighedsfragment, der slår begge de skrivere fra, den kan styre, og hver kontakt har en fuldt udskrevet ækvivalent, som manualen behandler som den samme indstilling.

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 forhindrer klienten i at anvende de DNS-servere, den lærte fra gatewayen, mens --pppd-no-peerdns forhindrer pppd i at skubbe peer-DNS ind i systemet. Manualen for upstream advarer om, at DNS-opdateringer over PPP kan kappes med klientens egne DNS-opdateringer, og derfor hører begge kontakter i fragmentet i stedet for at nogen af dem anses for tilstrækkelig.

Ingen af kontakterne peger på en erstatningsresolver, og ingen af dem forhindrer en netværksadministrator, en DHCP-klient eller en separat VPN-integration i at skrive opslag bagefter. At dæmpe to skrivere efterlader feltet åbent snarere end ejet. Hvis en tredje komponent allerede styrer DNS, ændrer fragmentet intet, du kan observere; hvis intet styrer det, har du netop fjernet den eneste kilde til privat navneopslag. Det er kun en gyldig ordning, når erstatningsejeren blev valgt først og testet alene.

Vælg ejeren, før du deaktiverer noget

Beslut først, hvem der svarer på forespørgsler om arbejdsnavne, for det valg begrænser alt derefter. At beholde den eksisterende resolver betyder, at den private zone allerede skal kunne nås fra hvor klienten end sidder, og en privat resolver inde i kontoret har brug for en rute, der overlever, at tunnelen kommer op. At sende hver forespørgsel til én intern tjeneste er en tredje politik med en skarpere fejltilstand: når den tjeneste ikke kan nås, fejler offentlige navne sammen med de private.

Ruteejerskab holdes adskilt med vilje. Rutevalgmulighederne er ikke påkrævet, fordi du ændrede DNS, og at slå ruteinstallation fra uden at installere en erstatning kan gøre den resolver, du netop valgte, utilgængelig. Kontrollér routingtabellen specifikt for resolveradressen, ikke kun for det applikationssubnet, du tilfældigvis testede.

Kontrollér opslag pr. forbindelse, ikke pr. fil

En enkelt /etc/resolv.conf er ikke en fortegnelse over, hvad programmer faktisk bruger på en vært med scoped eller pr.-domæne-opslag, så læs resolverens tilstand, som platformen viser den.

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

Spørg efter ét privat navn og ét offentligt navn, når forbindelsen er oppe, og notér, hvilken forbindelse der svarede på hvert. Hvor VPN-forbindelsen bærer en søgeliste pr. domæne, kan et privat navn slå korrekt op, mens et offentligt navn stadig går til den lokale resolver, og den opdeling er designet, der virker, ikke en fejl. Hvis den private forespørgsel fejler, undersøg ruten til resolveren, før du rører DNS igen; hvis den lykkes, mens et program stadig fejler, læser programmet måske en cachet eller særskilt konfigureret resolver af sin egen.

Genopkobl og bekræft den afbrudte tilstand

Tag forbindelsen ned, og gentag begge forespørgsler. Hvad den valgte ejer installerede, skal fjernes eller gendannes af den ejer, ikke efterlades af den klient, du fik til at tie. En forældet post pr. forbindelse, der overlever tunnelen, bliver ved med at sende private forespørgsler til en adresse, der ikke længere kan nås.

Genopkobl derefter, og læs de samme tre værdier igen: resolveradresse, søgedomæner, grænseflade.

Hvis de matcher den politik, du skrev ned, er overdragelsen fuldført, og VPN-klienten er ikke længere en af skriverne. Hvis en værdi driver tilbage få sekunder efter link-up, anvender noget andet stadig konfiguration, og næste skridt er at identificere den komponent i stedet for at tilføje endnu et flag. Den sluttilstand, du ønsker, er udramatisk: én ejer, én dokumenteret politik og en afbrudt vært, der slår op præcis som før, tunnelen fandtes.