Was OpenVPN route-nopull den Server tatsächlich nicht mehr pushen lässt

Sie haben route-nopull in ein Client-Profil gesetzt, damit der Tunnel Ihre Standardroute nicht schluckt, und jetzt ist das Office-Subnetz nicht erreichbar, während der Client weiterhin Verbunden meldet. Beide Beobachtungen stimmen, und nichts ist fehlgeschlagen. Das Flag weist den Client an, die vom Server gepushten Routen und DHCP-Einträge zu überspringen, was eine engere Anweisung ist, als die meisten erwarten, wenn sie es hinzufügen. Was übrig bleibt, ist ein funktionierender Tunnel ohne Meinung dazu, welche Ziele ihn nutzen sollen.

Diese Lücke ist die ganze Entscheidung, um die es in diesem Artikel geht. Entweder beschreibt der Server das Netz, oder der Client tut es, und das Flag gibt diese Aufgabe an den Client weiter, ohne sie Ihnen abzunehmen.

Was das Flag beim Verbindungsaufbau abschaltet

Ein ziehender OpenVPN-Client nimmt nach der Authentifizierung normalerweise ein Paket vom Server entgegen: Routen, eine Umleitung des Standard-Gateways, DNS-Server und ein paar Tuning-Direktiven. Mit route-nopull in Kraft akzeptiert der Client weiterhin die Sitzung, prüft weiterhin Zertifikate, handelt weiterhin Cipher und Keepalives aus und bringt weiterhin die Schnittstelle hoch. Was er verwirft, ist die Anwendung der gepushten route-Zeilen und der gepushten dhcp-option-Zeilen, DNS eingeschlossen.

Die Verwirrung entsteht durch eine grüne Anzeige neben einer toten Anwendung. Der Tunnel existiert; die Zuordnung von Zielen zu diesem Tunnel nicht. Nichts im Statusfenster des Clients unterscheidet „verbunden und routend“ von „verbunden und untätig“, denn aus Sicht des Tunnels sind beide derselbe Zustand.

Warum ein lebender Tunnel trotzdem nichts routen kann

Die Schnittstelle erscheint mit eigener Adresse und hat bei einer Punkt-zu-Punkt-Verbindung oft nichts Spezifischeres als eine Host-Route zum Gegenüber. Ein privates Subnetz wird erst erreichbar, wenn irgendeine Route mit dem richtigen Präfix auf diese Schnittstelle zeigt, und bei abgeschaltetem Push kommt diese Route nie an. Das heruntergeladene Profil kann meist auch nicht helfen, weil es unter der Annahme geschrieben wurde, der Server werde genau diese Information liefern. Deshalb kann die Schnittstelle gesund aussehen, während das Subnetz dunkel bleibt.

Das Profil zu lesen beweist also sehr wenig. Lesen Sie stattdessen den laufenden Zustand auf dem verbundenen Rechner:

ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10

Eine Adresse ohne Subnetzroute im zweiten Befehl ist die Signatur dieses Problems. Der dritte Befehl beantwortet dann die Frage, die Nutzer wirklich interessiert, denn er meldet die Schnittstelle, die der Kernel für ein bestimmtes Ziel wählen würde, statt die Liste, von der Sie hofften, dass sie benutzt wird. Antwortet er über Ihre physische Verbindung, ist der Tunnel überhaupt nicht im Pfad.

Die Namensauflösung scheitert aus einem verwandten Grund, nicht aus einem getrennten. Gepushte dhcp-option DNS-Einträge werden vom selben Flag übersprungen, also gehen Anfragen für interne Hosts an welchen Resolver auch immer das lokale Netz gestellt hat. Dieser Resolver hat keine Zone für das Büro, also scheitert die Anfrage oder liefert eine öffentliche Antwort, und der Fehler sieht wie ein Serverproblem aus, während er ein Client-Konfigurationsproblem ist. Eine Adresse vor einem Namen zu testen, ist das, was beides trennt.

Die Wahl zwischen Flag und Präfixfilter

Die beiden Optionen lösen unterschiedliche Formen derselben Beschwerde, und eine schlechte Wahl erzeugt den Zustand verbunden-aber-nutzlos. Die eine ersetzt die gepushte Richtlinie vollständig, die andere bearbeitet sie nach Präfix. Die Tabelle gibt die Kurzfassung, und der Absatz danach deckt den Teil ab, der Leute erwischt.

pull-filter ist ein Präfixabgleich mit drei Verben, kann also eine Familie von Zeilen akzeptieren, sie still ignorieren oder die Verbindung rundheraus ablehnen, wenn ein Präfix auftaucht. Das letzte Verhalten ist das wissenswerte: Eine Ablehnungsregel macht aus einem Richtlinienstreit einen fehlgeschlagenen Handshake statt einer stillen Auslassung. Das OpenVPN-2.6-Handbuch listet die akzeptierten Präfixe und die genaue Semantik jedes Verbs.

Ein häufiger Mittelweg ist, nur redirect-gateway abzulehnen und die Büro-Routen und DNS wie beabsichtigt ankommen zu lassen. Das hält den Push für die Teile am Laufen, die der Server besser versteht als Sie, und verhindert zugleich die eine Zeile, die Ihre Standardroute übernehmen würde.

Routen und einen Resolver von Hand eintragen

Wenn Sie das Flag behalten, muss das Profil sagen, was der Server gesagt hätte. Clientseitige route-Direktiven werden nach dem Verbindungsaufbau angewendet, wirken also neben dem Flag, statt von ihm blockiert zu werden. Setzen Sie sie ins Profil, nicht in eine interaktive Kommandozeile, sonst stellt die nächste Wiederverbindung den funktionierenden Zustand nicht wieder her.

route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53

Die DNS-Zeile sitzt in einer unangenehmen Lage: Sie ist eine clientseitige Direktive, aber manche Clients wenden sie nur über die DNS-Integration der Plattform an, die sie überschreiben kann, wenn sich die Verbindung ändert. Auf einem systemd-Host ist es vorhersehbarer, den Resolver direkt auf der Tunnelschnittstelle zu setzen, als zu hoffen, dass der Client den Prioritätswettstreit gewinnt:

resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.com

Die Routing-Domäne ist genauso wichtig wie die Adresse. Ohne sie können Anfragen für öffentliche Namen auch an den internen Resolver gehen, und jeder interne Resolver, der Rekursion verweigert, bricht das Surfen, während die private Zone weiter funktioniert. Mit ihr werden nur Namen unter diesem Suffix an den Tunnel-Resolver geleitet, und alles andere folgt der physischen Verbindung.

Das Ergebnis prüfen: Adresse, Name und der äußere Pfad

Drei Tests trennen die möglichen Fehler. Holen Sie die private Adresse per IP, dann denselben Host per Namen, dann eine gewöhnliche öffentliche Seite. Eine funktionierende IP mit fehlschlagendem Namen deutet auf den Resolver; eine fehlschlagende IP mit funktionierendem Namen auf das Routing; schlägt beides fehl, ist der Tunnel meist nicht im Pfad.

Schauen Sie dann nach außen statt nach innen. Die eigene Route des Tunnel-Endpunkts muss die Änderung überleben, und jede Blockade muss auf den Tunnel begrenzt sein, ohne den Endpunkt zu fangen. Ein Client, der nach dem Ausfall des Tunnels weiter surft, ist ein Richtlinienproblem, kein Routingproblem, und es wird in keinem der drei Tests oben auftauchen.

Schreiben Sie die endgültige Liste in die Dokumentation des Profils: die Routen, den Resolver, die Domänen und den Grund, warum jeder existiert. Eine Wiederverbindung, die dieselbe Tabelle reproduziert, ist der einzige Beweis, dass die lokale Richtlinie vollständig ist. Wenn Anwendungen bei stehendem Tunnel und bestandenen drei Tests weiterhin scheitern, ist die nächste Stelle die Klasse der verbunden-aber-offline-Probleme statt Zertifikaten, die bereits verifiziert wurden.