OpenVPN schiebt weiter alte Routen? Prüfen Sie, was es geladen hat

Sie fügen eine Route hinzu, starten den Dienst neu, verbinden sich erneut, und die Tabelle des Clients sieht genauso aus wie vorher. Zwei verschiedene Dinge können zutreffen: Der Server hat Ihre Änderung nie geladen, oder der Client hat das Empfangene nie installiert. Gemeinsam ist ihnen nur das Symptom, deshalb besteht der erste Schritt darin, herauszufinden, welchen der beiden Fälle Sie haben.

Der folgende Vergleich geht vom Prozess nach außen, denn der Prozess ist die einzige Instanz, die weiß, welche Datei gilt.

Die Datei, die Sie bearbeitet haben, und die Datei, die der Prozess liest

Beginnen Sie bei der Unit und der Kommandozeile, die sie erzeugt hat. Auf einem systemd-Host gibt systemctl cat openvpn@server die Zeile ExecStart aus, und eine Instanz-Unit leitet ihren Konfigurationspfad meist vom Instanznamen ab, sodass ein als openvpn@office gestarteter Daemon eine andere Datei liest als einer, der als openvpn@server gestartet wurde. Vergleichen Sie das mit der argv des laufenden Prozesses. Ein Konfigurationsmanagement-Werkzeug fügt eine weitere Art hinzu, die Änderung zu verlieren: Es kann eine korrekte Datei an einen Ort schreiben, den die Unit nie nennt, und dann sieht ein grünes Deployment wie ein Nichts aus.

Zeitstempel klären das schnell: Ist die Datei neuer als die Startzeit des Prozesses, kann der Prozess sie nicht gelesen haben. Router-Firmware fügt einen dritten Fall hinzu, denn viele Modelle halten ihre Einstellungen im Flash und bauen die Konfiguration beim Start neu auf, was eine Dateibearbeitung auf der Platte zur völlig falschen Ebene macht.

Was der Server schiebt und was der Client installiert

Eine geschobene Route muss zwei Filter überstehen. Auf dem Server muss sie in der geladenen Konfiguration stehen und nicht in einem auskommentierten Block oder in einer client-spezifischen Datei, deren Name nicht passt. Auf dem Client muss pull aktiviert sein, und kein pull-filter darf die Option verwerfen. Verbinden Sie sich mit verbosity 4 und lesen Sie die geschobenen Optionen, die der Client meldet: Steht die Route in dieser Liste, hat der Server seine Arbeit getan, und der Client entscheidet sich, sie nicht zu installieren.

Client-spezifische Dateien sind eine häufige Verwechslungsquelle. Eine nach dem Common Name des Zertifikats benannte Datei schiebt Optionen nur an diesen einen Client, und eine Abweichung um ein Zeichen beendet das Schieben still, ohne Fehler auf beiden Seiten. Der Server protokolliert den Common Name, den er beim Verbinden sah, vergleichen Sie also diesen Wert mit dem Dateinamen und nicht mit dem, was Sie für den Namen des Clients halten.

Das geschobene Präfix und die Rückroute sind verschiedene Probleme

Ein Client, der redirect-gateway bewusst ignoriert, um seinen lokalen Internetweg zu behalten, erzeugt eine zweite, unabhängige Lücke. Die Sonden des Servers erreichen die Tunneladresse, und die Antworten kommen nie an, weil eine Antwort an die Tunnel-IP des Servers über das gewöhnliche Standardgateway des Clients geroutet wird. Die geschobene Subnetz-Route ist hier nicht schuld; es fehlt eine Route, die Verkehr für das Tunnelnetz des Servers zurück durch das Tunnelgerät schickt.

Diese Route auf dem Client hinzuzufügen behebt Antworten auf Sonden, die der Server auslöst. Sie ersetzt die geschobene Subnetz-Route nicht, und umgekehrt gilt dasselbe, weil die beiden entgegengesetzte Richtungen beschreiben.

Vergleichen Sie die Tabellen an beiden Enden

Verbinden Sie sich nach jeder Änderung erneut und lesen Sie die Tabelle des Clients für das geschobene Präfix und für das Tunnelgerät. Testen Sie dann in beide Richtungen: vom Client zu einem Host im geschobenen Subnetz und von diesem Host zurück zum Client. Eine Route, die existiert, aber keinen Verkehr trägt, bedeutet eines von drei Dingen: Die Gegenseite leitet nicht weiter, eine Firewall verwirft den Fluss, oder die Antwort findet keinen Weg zurück.

Halten Sie drei Kennungen zusammen: den Konfigurationspfad, den Unit- oder Instanznamen und die Client-Identität, mit der Sie getestet haben.

Diese drei machen aus dem nächsten Vorfall eine Fünf-Minuten-Prüfung statt einer erneuten Untersuchung, und sie sind es, was ein Kollege braucht, wenn der Tunnel zu jemandes anderem Problem wird.

Ein Routenproblem, das einen Neustart übersteht, ist oft gar kein Routingproblem; der Fehler sitzt oberhalb der Tabelle, die Sie immer wieder lesen.