openfortivpn overschrijft steeds DNS? Vind de echte eigenaar

Volg de verbinding vanaf het moment dat hij omhoogkomt: de client authenticeert, pppd onderhandelt, en dan schrijft iets DNS-instellingen in het besturingssysteem. Als je alleen weet dat de VPN je resolver heeft veranderd, weet je nog niet welke van die fasen het heeft gedaan. Twee ervan kunnen het, en op een client met de gedocumenteerde pppd-integratie lopen ze dicht genoeg bij elkaar om als één actor te lijken. De schrijver benoemen is de eerste stap; zijn vervanger kiezen is de tweede, en dat is een aparte beslissing met eigen faalwijzen.

De volgorde hieronder volgt de client naar buiten: wat de verbinding veranderde, welke schakelaar welke schrijver onderdrukt, wie het zou moeten overnemen, en hoe je bevestigt dat het resultaat een herverbinding overleeft. Elke fase laat een ander spoor achter, en het spoor is wat je vertelt of de overdracht echt heeft plaatsgevonden.

Begin met wat de verbinding werkelijk veranderde

Verbind één keer met je gebruikelijke opdracht en vergelijk de resolutie voor en na. Op een Linux-host met systemd-resolved drukt resolvectl status de DNS-servers en zoekdomeinen per verbinding af, en een nieuwe tun- of ppp-verbinding met eigen servers is de vingerafdruk van een update aan de clientkant. Op macOS toont scutil --dns de resolverconfiguratie in de volgorde waarin toepassingen die raadplegen.

Vergelijk dat met het bestand waarvan je verwachtte dat het zou veranderen. Een verbindingsgebonden vermelding in de weergave per verbinding en een herschreven /etc/resolv.conf zijn twee verschillende uitkomsten, en de tweede kan een symbolische koppeling zijn die iets heel anders beheert. Noteer het resolveradres, de zoekdomeinen en de interfacenaam op hetzelfde moment; een wijziging in een van hen wijst op een andere schrijver. Zonder die basislijn is elke latere correctie een gok over welke van drie componenten is verschoven.

De twee schakelaars en de schrijver die elk tot zwijgen brengt

openfortivpn documenteert een optiefragment dat beide schrijvers uitschakelt die het kan beheren, en elke schakelaar heeft een volledig uitgeschreven equivalent dat de handleiding als dezelfde instelling behandelt.

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 verhindert dat de client de DNS-servers toepast die hij van de gateway heeft geleerd, terwijl --pppd-no-peerdns verhindert dat pppd peer-DNS in het systeem duwt. De handleiding van upstream waarschuwt dat DNS-updates via PPP kunnen wedijveren met de eigen DNS-updates van de client, en daarom horen beide schakelaars in het fragment in plaats van een van beide als voldoende te beschouwen.

Geen van de schakelaars noemt een vervangende resolver, en geen van beide verhindert dat een netwerkbeheerder, een DHCP-client of een aparte VPN-integratie daarna resolutie schrijft. Twee schrijvers tot zwijgen brengen laat het veld open in plaats van in bezit. Als een derde component DNS al beheert, verandert het fragment niets dat je kunt waarnemen; als niets het beheert, heb je net de enige bron van private naamresolutie verwijderd. Dat is alleen een geldige regeling wanneer de vervangende eigenaar eerst is gekozen en afzonderlijk getest.

Kies de eigenaar voordat je iets uitschakelt

Bepaal eerst wie vragen voor werknammen beantwoordt, want die keuze beperkt alles daarna. De bestaande resolver behouden betekent dat de private zone al bereikbaar moet zijn vanaf waar de client ook zit, en een private resolver in het kantoor heeft een route nodig die het omhoogkomen van de tunnel overleeft. Elke vraag naar één interne dienst sturen is een derde beleid met een scherpere faalwijze: als die dienst onbereikbaar is, falen openbare namen samen met de private.

Route-eigendom blijft met opzet gescheiden. De routeopties zijn niet vereist omdat je DNS hebt gewijzigd, en het uitschakelen van route-installatie zonder een vervanger te installeren kan de resolver die je net hebt gekozen onbereikbaar maken. Controleer de routingtabel specifiek op het resolveradres, niet alleen op het toepassingssubnet dat je toevallig hebt getest.

Controleer de resolutie per verbinding, niet per bestand

Een enkele /etc/resolv.conf is geen inventaris van wat toepassingen echt gebruiken op een host met beperkte of per-domein-resolutie, dus lees de resolutiestatus zoals het platform die blootlegt.

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

Vraag één private naam en één openbare naam op zodra de verbinding omhoog is, en noteer welke verbinding op elk antwoordde. Waar de VPN-verbinding een zoeklijst per domein draagt, kan een private naam correct worden opgelost terwijl een openbare naam nog naar de lokale resolver gaat, en die splitsing is het ontwerp dat werkt en geen storing. Als de private vraag mislukt, onderzoek dan de route naar de resolver voordat je DNS opnieuw aanraakt; als hij slaagt terwijl een toepassing nog steeds mislukt, leest de toepassing misschien een eigen gecachte of apart geconfigureerde resolver.

Herverbind en bevestig de losgekoppelde toestand

Haal de verbinding naar beneden en herhaal beide vragen. Wat de gekozen eigenaar heeft geïnstalleerd, moet door die eigenaar worden verwijderd of hersteld, niet worden achtergelaten door de client die je tot zwijgen bracht. Een verouderde vermelding per verbinding die de tunnel overleeft, blijft private vragen sturen naar een adres dat niet langer bereikbaar is.

Herverbind daarna en lees dezelfde drie waarden opnieuw: resolveradres, zoekdomeinen, interface.

Als ze overeenkomen met het beleid dat je hebt opgeschreven, is de overdracht compleet en is de VPN-client niet langer een van de schrijvers. Als een waarde enkele seconden na het omhoogkomen van de verbinding terugloopt, past iets anders nog configuratie toe, en de volgende stap is dat component identificeren in plaats van nog een vlag toe te voegen. De eindtoestand die je wilt is zonder incidenten: één eigenaar, één gedocumenteerd beleid en een losgekoppelde host die precies zo resolvet als voordat de tunnel bestond.