openfortivpn skriver hela tiden över DNS? Hitta den riktiga ägaren

Följ anslutningen från det ögonblick den kommer upp: klienten autentiserar, pppd förhandlar och sedan skriver något DNS-inställningar i operativsystemet. Om du bara vet att VPN:en ändrade din resolver vet du ännu inte vilket av dessa steg som gjorde det. Två av dem kan, och på en klient med den dokumenterade pppd-integrationen kör de nära nog varandra för att se ut som en enda aktör. Att namnge skrivaren är det första steget; att välja dess ersättare är det andra, och det är ett eget beslut med sina egna fellägen.

Ordningen nedan följer klienten utåt: vad anslutningen ändrade, vilken brytare som dämpar vilken skrivare, vem som ska ta över och hur du bekräftar att resultatet överlever en återanslutning. Varje steg lämnar ett annat spår, och spåret är det som berättar om överlämningen faktiskt skedde.

Börja med vad anslutningen faktiskt ändrade

Anslut en gång med ditt vanliga kommando och jämför uppslaget före och efter. På en Linux-värd med systemd-resolved skriver resolvectl status ut DNS-servrar och sökdomäner per anslutning, och en ny tun- eller ppp-anslutning med egna servrar är fingeravtrycket för en uppdatering från klientsidan. På macOS visar scutil --dns resolverkonfigurationen i den ordning programmen rådfrågar den.

Jämför det med filen du förväntade dig skulle ändras. En anslutningsbunden post i vyn per anslutning och en omskriven /etc/resolv.conf är två olika utfall, och det andra kan vara en symbolisk länk som något helt annat hanterar. Anteckna resolveradressen, sökdomänerna och gränssnittsnamnet i samma ögonblick; en ändring i någon av dem pekar på en annan skrivare. Utan den baslinjen är varje senare rättelse en gissning om vilken av tre komponenter som flyttade sig.

De två brytarna och skrivaren som var och en tystar

openfortivpn dokumenterar ett alternativfragment som stänger av båda skrivarna som det kan kontrollera, och varje brytare har en fullt utskriven motsvarighet som handboken behandlar som samma inställning.

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 från att tillämpa de DNS-servrar den lärde sig från gatewayen, medan --pppd-no-peerdns hindrar pppd från att trycka in peer-DNS i systemet. Handboken för upstream varnar för att DNS-uppdateringar över PPP kan tävla med klientens egna DNS-uppdateringar, och därför hör båda brytarna till fragmentet i stället för att någon av dem anses tillräcklig.

Ingen av brytarna namnger en ersättningsresolver, och ingen av dem hindrar en nätverkshanterare, en DHCP-klient eller en separat VPN-integration från att skriva uppslag efteråt. Att tysta två skrivare lämnar fältet öppet snarare än ägt. Om en tredje komponent redan hanterar DNS ändrar fragmentet ingenting du kan observera; om ingenting hanterar det har du just tagit bort den enda källan till privat namnupslag. Det är bara en giltig ordning när ersättningsägaren valdes först och testades ensam.

Välj ägaren innan du inaktiverar något

Bestäm först vem som svarar på frågor om arbetsnamn, eftersom det valet begränsar allt som följer. Att behålla den befintliga resolvern innebär att den privata zonen redan måste vara nåbar där klienten sitter, och en privat resolver inne på kontoret behöver en rutt som överlever att tunneln kommer upp. Att skicka varje fråga till en enda intern tjänst är en tredje policy med ett skarpare felläge: när den tjänsten inte är nåbar misslyckas offentliga namn tillsammans med de privata.

Ruttägandet hålls åtskilt med avsikt. Ruttalternativen krävs inte för att du ändrade DNS, och att stänga av ruttinstallationen utan att installera en ersättare kan göra resolvern du just valde onåbar. Kontrollera routingtabellen specifikt för resolveradressen, inte bara för applikationssubnätet du råkade testa.

Kontrollera uppslaget per anslutning, inte per fil

En enda /etc/resolv.conf är inte en förteckning över vad program faktiskt använder på en värd med begränsat eller per-domän-uppslag, så läs resolverns tillstånd som plattformen visar det.

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

Fråga efter ett privat namn och ett offentligt namn när anslutningen är uppe, och notera vilken anslutning som svarade på vart och ett. Där VPN-anslutningen bär en söklista per domän kan ett privat namn slås upp korrekt medan ett offentligt namn fortfarande går till den lokala resolvern, och den delningen är designen som fungerar och inte ett fel. Om den privata frågan misslyckas, undersök rutten till resolvern innan du rör DNS igen; om den lyckas medan ett program fortfarande misslyckas läser programmet kanske sin egen cachade eller separat konfigurerade resolver.

Återanslut och bekräfta det frånkopplade tillståndet

Ta ner anslutningen och upprepa båda frågorna. Det den valda ägaren installerade ska tas bort eller återställas av den ägaren, inte lämnas kvar av klienten du tystade. En inaktuell post per anslutning som överlever tunneln fortsätter skicka privata frågor till en adress som inte längre är nåbar.

Återanslut sedan och läs samma tre värden igen: resolveradress, sökdomäner, gränssnitt.

Om de stämmer med policyn du skrev ned är överlämningen klar och VPN-klienten är inte längre en av skrivarna. Om ett värde driver tillbaka några sekunder efter att anslutningen kom upp tillämpar något annat fortfarande konfiguration, och nästa steg är att identifiera den komponenten i stället för att lägga till ännu en flagga. Det sluttillstånd du vill ha är händelselöst: en ägare, en dokumenterad policy och en frånkopplad värd som slår upp exakt som före tunnelns existens.