Wer sollte Routen und DNS besitzen, wenn openfortivpn eine Verbindung aufbaut?

Vier Stufen bauen in einer funktionierenden openfortivpn-Sitzung aufeinander auf. Der Client authentifiziert sich am Gateway und startet eine TLS-Verbindung, führt dann PPP innerhalb dieser Verbindung aus, empfängt dann eine Adresse und DNS-Informationen und wendet schließlich Host-Routen und Resolver-Einstellungen an. Jede Stufe kann leben, während die nächste es nicht tut, und deshalb ist „verbunden“ in Support-Threads ein so schlüpfriges Wort.

Die Entscheidung, die den meisten Verwirrung beseitigt, ist, wer die letzte Stufe besitzt. Entweder wendet der VPN-Client die Änderungen am Host selbst an, oder eine andere Komponente tut es, und beides auf halbem Weg zu mischen, führt dazu, dass Routen und Resolver-Dateien unterschiedliche Sitzungen beschreiben.

Vier Stufen, die wie eine Verbindung aussehen

Die erste Stufe ist die Zulassung. eine benannte Authentifizierungsdomäne oder einen Einmalcode und erhält die Parameter, die er zum Fortfahren braucht. Wenn der Client ausgibt, dass er mit dem Gateway verbunden ist, heißt das, dass der TLS-Transport steht. Es heißt nicht, dass PPP verhandelt hat, und es heißt gewiss nicht, dass eine interne Anwendung erreichbar ist.

Die zweite Stufe ist die PPP-Verbindung. Der Client startet einen PPP-Prozess gegen das Tunnelgerät, und die beiden Seiten verhandeln Linkoptionen und Adressen. Erst danach weiß der Host, welche lokalen und entfernten Adressen die Sitzung verwendet, und erst dann ergibt eine Route in den Tunnel Sinn.

Die dritte Stufe ist die Anwendung dieser Informationen auf den Host, und hier zählt Eigentum. Der Client kann die Routen hinzufügen und die Resolver-Konfiguration neu schreiben, oder man kann ihm sagen, er solle zurücktreten und beides dem überlassen, was sonst das Netzwerk auf dieser Maschine verwaltet. Die README des Projekts beschreibt dies als getrennte Zuständigkeiten statt als ein automatisches Verhalten.

Wer die Routing-Tabelle bearbeitet

Standardmäßig ist der Client der Eigentümer. Er fügt eine Route zum Gateway über die physische Schnittstelle hinzu, eine Route für den Peer des Tunnels und Routen für die Netzwerke, die die Sitzung nutzen darf, und entfernt sie dann beim Beenden des Prozesses. Dieser Standard ist auf einem Laptop mit einem einzigen Netzwerkmanager und ohne andere VPN-Software bequem.

Wählen Sie die Übergabe nur, wenn etwas anderes wirklich das Routing besitzt. Eine Netzwerkmanager-Integration, ein Container-Netzwerk-Namespace oder ein standortweiter Routing-Agent weiß möglicherweise bereits, wie dieselben Präfixe installiert und bereinigt werden. Die no-routes-Option zu übergeben verhindert dann, dass zwei Schreiber um dieselbe Tabelle kämpfen, ein Wettlauf, der sich als zeitweiliger Verlust eines Subnetzes statt als sauberer Fehler zeigt.

Überlappung ist der zweite Grund zur Übergabe. Wenn die gepushten Routen ein Präfix enthalten, das das lokale Netzwerk bereits nutzt, kann der Client den Konflikt nicht für Sie lösen. Jemand muss entscheiden, ob dieses Präfix über den Tunnel, über die physische Verbindung oder über eine spezifischere Route erreichbar ist, und diese Entscheidung gehört dem, der die Topologie besitzt.

Bereinigung ist der dritte. Ein Client, der abstürzt, bevor er seine Routen entfernt, hinterlässt ein schwarzes Loch, das die Sitzung überlebt, und die nächste Verbindung kann ein Duplikat darauf legen. Wer das Routing besitzt, besitzt auch die Prüfung, dass die alten Einträge verschwunden sind. Machen Sie diese Prüfung zum Teil des Startpfads, nicht zu einem optionalen Bereinigungsschritt.

Wer DNS und die Resolver-Datei besitzt

DNS ist dieselbe Entscheidung mit schärferen Kanten. Der Client kann die DNS-Server akzeptieren, die das Gateway oder der PPP-Peer meldet, und sie in die Resolver-Konfiguration des Hosts schreiben. Auf einer einfachen Maschine ist das genau, was Sie wollen, weil interne Namen dann nur auflösen, solange der Tunnel steht.

Auf einem modernen Linux-Host kann der Resolver von einem lokalen Stub verwaltet werden, und die Resolver-Datei hinter dem Rücken dieses Stubs neu zu schreiben, erzeugt eine Konfiguration, die korrekt aussieht und sich inkonsistent verhält. Wenn der Host bereits einen Resolver-Manager betreibt, lassen Sie ihn DNS besitzen und füttern Sie ihn über seine unterstützte Schnittstelle mit den Servern des Tunnels. Die no-dns-Option des Clients ist dort die richtige Wahl, keine Notlösung.

Split-DNS ist eine separate Frage davon, wer die Datei schreibt. Jede Abfrage durch den Tunnel zu schicken ist einfach und langsam; nur interne Zonen durch ihn zu schicken, erfordert pro Domäne eine Konfiguration, die die meisten einfachen Clients nicht bieten. Entscheiden Sie, welches Verhalten der Host braucht, bevor Sie die Resolver-Änderungen des Clients aktivieren. Eine falsche Wahl hier sieht wie ein Namensauflösungsausfall aus, selbst wenn der Tunnel selbst in Ordnung ist.

Berechtigung, Bereitschaft und die Übergabe

Das Tunnelgerät zu erstellen und Host-Routen oder den Resolver-Zustand zu bearbeiten, erfordert erhöhte Netzwerkautorität. Der übliche Fehler ist zu schließen, dass deshalb alles als root laufen müsse, einschließlich des Browsers oder der Anwendung, die den Tunnel nutzt. Halten Sie den privilegierten Teil klein: der Client und seine Konfigurationsdatei, im Besitz eines Administrators, während Benutzeranwendungen ihr normales Konto behalten.

Bereitschaft sollte pro Verbraucher definiert werden. Ein Supervisor kann den Dienst als gestartet betrachten, wenn der Client-Prozess läuft und das Tunnelgerät existiert. Ein Backup-Job sollte die VPN erst als nutzbar betrachten, wenn sein Speicherendpunkt durch den Tunnel antwortet. Das sind unterschiedliche Prüfungen, und die schwächere für den stärkeren Zweck zu verwenden, erzeugt Jobs, die zu früh starten und zeitweilig scheitern. Schreiben Sie die gewählte Definition auf, denn ein Supervisor und ein Job, die sich über die Bereitschaft uneinig sind, sind ein Support-Ticket, das darauf wartet zu passieren.

Testen Sie den Vertrag mit vier Beobachtungen: Die Gateway-Phase schließt ab, PPP weist Adressen zu, die beabsichtigte Route ist vorhanden und eine Anfrage an einen internen Host gelingt. Stoppen Sie dann den Client und bestätigen Sie, dass jedes davon entfernt oder wiederhergestellt ist. Wenn der Host nach dem Schließen des Tunnels noch interne Namen auflöst oder noch eine Route hält, ist die Eigentumsübergabe unvollständig.