openfortivpn überschreibt ständig DNS? Finden Sie den wahren Eigentümer

Verfolgen Sie die Verbindung von dem Moment an, in dem sie hochkommt: der Client authentifiziert sich, pppd verhandelt, und dann schreibt etwas DNS-Einstellungen ins Betriebssystem. Wenn Sie nur wissen, dass das VPN Ihren Resolver geändert hat, wissen Sie noch nicht, welche dieser Stufen es getan hat. Zwei davon können es, und auf einem Client mit der dokumentierten pppd-Integration laufen sie nah genug zusammen, um wie ein einziger Akteur auszusehen. Den Schreiber zu benennen ist der erste Schritt; seinen Ersatz zu wählen der zweite, und das ist eine eigene Entscheidung mit eigenen Fehlermodi.

Die folgende Reihenfolge folgt dem Client nach außen: was die Verbindung geändert hat, welcher Schalter welchen Schreiber unterdrückt, wer übernehmen soll und wie Sie bestätigen, dass das Ergebnis eine Wiederverbindung übersteht. Jede Stufe hinterlässt eine andere Spur, und die Spur sagt Ihnen, ob die Übergabe tatsächlich stattgefunden hat.

Beginnen Sie damit, was die Verbindung tatsächlich geändert hat

Verbinden Sie sich einmal mit Ihrem üblichen Aufruf und vergleichen Sie die Auflösung vorher und nachher. Auf einem Linux-Host mit systemd-resolved gibt resolvectl status die DNS-Server und Suchdomänen pro Verbindung aus, und eine neue tun- oder ppp-Verbindung mit eigenen Servern ist der Fingerabdruck einer clientseitigen Aktualisierung. Unter macOS zeigt scutil --dns die Resolver-Konfiguration in der Reihenfolge, in der Anwendungen sie konsultieren.

Vergleichen Sie das mit der Datei, deren Änderung Sie erwartet hatten. Ein verbindungsgebundener Eintrag in der Ansicht pro Verbindung und eine neu geschriebene /etc/resolv.conf sind zwei verschiedene Ergebnisse, und das zweite kann ein symbolischer Link sein, den etwas ganz anderes verwaltet. Notieren Sie Resolver-Adresse, Suchdomänen und Schnittstellennamen im selben Moment; eine Änderung an irgendeinem davon deutet auf einen anderen Schreiber. Ohne diese Grundlinie ist jede spätere Korrektur eine Vermutung darüber, welche von drei Komponenten sich bewegt hat.

Die zwei Schalter und der Schreiber, den jeder zum Schweigen bringt

openfortivpn dokumentiert ein Optionsfragment, das beide Schreiber abschaltet, die es steuern kann, und jeder Schalter hat ein ausgeschriebenes Äquivalent, das das Handbuch als dieselbe Einstellung 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 hindert den Client daran, die vom Gateway gelernten DNS-Server anzuwenden, während --pppd-no-peerdns pppd daran hindert, Peer-DNS ins System zu schieben. Das Handbuch von upstream warnt davor, dass sich DNS-Aktualisierungen über PPP mit den eigenen DNS-Aktualisierungen des Clients überholen können, weshalb beide Schalter in das Fragment gehören, statt einen von beiden als ausreichend zu betrachten.

Keiner der Schalter benennt einen Ersatz-Resolver, und keiner hindert einen Netzwerkmanager, einen DHCP-Client oder eine separate VPN-Integration daran, danach die Auflösung zu schreiben. Zwei Schreiber zum Schweigen zu bringen lässt das Feld offen statt besessen. Wenn eine dritte Komponente DNS bereits verwaltet, ändert das Fragment nichts, was Sie beobachten können; wenn nichts es verwaltet, haben Sie gerade die einzige Quelle privater Namensauflösung entfernt. Das ist nur dann eine gültige Anordnung, wenn der Ersatz-Eigentümer zuerst gewählt und für sich getestet wurde.

Wählen Sie den Eigentümer, bevor Sie etwas abschalten

Entscheiden Sie zuerst, wer Anfragen für Arbeitsnamen beantwortet, denn diese Wahl beschränkt alles danach. Den vorhandenen Resolver zu behalten bedeutet, dass die private Zone bereits von überall erreichbar sein muss, wo der Client sitzt, und ein privater Resolver im Büro braucht eine Route, die das Hochkommen des Tunnels übersteht. Jede Anfrage an einen einzigen internen Dienst zu schicken ist eine dritte Politik mit einem schärferen Fehlermodus: wenn dieser Dienst nicht erreichbar ist, scheitern öffentliche Namen zusammen mit den privaten.

Routen-Eigentum bleibt bewusst getrennt. Die Routenoptionen sind nicht erforderlich, weil Sie DNS geändert haben, und das Abschalten der Routeninstallation ohne Installation eines Ersatzes kann den Resolver, den Sie gerade gewählt haben, unerreichbar machen. Prüfen Sie die Routing-Tabelle gezielt auf die Resolver-Adresse, nicht nur auf das Anwendungssubnetz, das Sie zufällig getestet haben.

Prüfen Sie die Auflösung pro Verbindung, nicht pro Datei

Eine einzelne /etc/resolv.conf ist keine Bestandsaufnahme dessen, was Anwendungen auf einem Host mit bereichsbezogener oder domänenbezogener Auflösung tatsächlich verwenden, lesen Sie den Resolver-Zustand also so, wie die Plattform ihn offenlegt.

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

Fragen Sie einen privaten Namen und einen öffentlichen Namen ab, sobald die Verbindung steht, und notieren Sie, welche Verbindung jeweils geantwortet hat. Wo die VPN-Verbindung eine Suchliste pro Domäne trägt, kann ein privater Name korrekt aufgelöst werden, während ein öffentlicher Name noch zum lokalen Resolver geht, und diese Aufteilung ist funktionierendes Design und kein Fehler. Wenn die private Abfrage fehlschlägt, prüfen Sie die Route zum Resolver, bevor Sie DNS erneut anfassen; wenn sie gelingt, während eine Anwendung weiterhin scheitert, liest die Anwendung möglicherweise einen eigenen zwischengespeicherten oder getrennt konfigurierten Resolver.

Verbinden Sie neu und bestätigen Sie den getrennten Zustand

Bringen Sie die Verbindung herunter und wiederholen Sie beide Abfragen. Was der gewählte Eigentümer installiert hat, sollte von diesem Eigentümer entfernt oder wiederhergestellt werden, nicht von dem Client zurückgelassen, den Sie zum Schweigen gebracht haben. Ein veralteter Eintrag pro Verbindung, der den Tunnel überlebt, schickt weiterhin private Abfragen an eine Adresse, die nicht mehr erreichbar ist.

Verbinden Sie sich dann neu und lesen Sie dieselben drei Werte erneut: Resolver-Adresse, Suchdomänen, Schnittstelle.

Wenn sie zu der von Ihnen notierten Politik passen, ist die Übergabe abgeschlossen und der VPN-Client ist keiner der Schreiber mehr. Wenn ein Wert wenige Sekunden nach dem Link-Up zurückwandert, wendet etwas anderes noch Konfiguration an, und der nächste Schritt ist, diese Komponente zu identifizieren, statt ein weiteres Flag hinzuzufügen. Der gewünschte Endzustand ist ereignislos: ein Eigentümer, eine dokumentierte Politik und ein getrennter Host, der genau so auflöst wie vor dem Bestehen des Tunnels.