OpenVPN bricht nach einer DHCP-Erneuerung ab: die Endpunkt-Route bleibt

Der Tunnel verbindet sich, dann beendet ihn eine Lease-Erneuerung auf der Zugangsstrecke, und das Protokoll gibt einem Timeout die Schuld statt einer Route. In der VPN-Konfiguration hat sich nichts geändert, und genau das ist der Hinweis: etwas außerhalb hat sich geändert. Ein DHCP-Ereignis hat die Adresse oder das Gateway neu geschrieben, und die Host-Route, die den Tunnel-Endpunkt erreichbar hielt, zeigt jetzt auf einen nächsten Hop, den es nicht mehr gibt. Das ist ein Eigentumsproblem, bevor es ein Routingproblem ist.

Prüfe das Symptom gegen die Halb-Default-Routen

Mit redirect-gateway def1 installiert OpenVPN 0.0.0.0/1 und 128.0.0.0/1, statt die Default-Route zu ersetzen. Zusammen decken die beiden den gesamten Adressraum ab, und sie schlagen 0.0.0.0/0 allein durch die Präfixlänge. Jedes Ziel ohne einen spezifischeren Treffer landet daher im Tunnel.

Der Endpunkt braucht eine Ausnahme. OpenVPN fügt eine Host-Route zur Serveradresse über das ursprüngliche Zugangs-Gateway hinzu, bevor die Halb-Defaults gesetzt werden, damit gekapselte Pakete hinauskönnen. Wenn diese Ausnahme verschwindet oder einen nächsten Hop behält, den es nicht mehr gibt, treffen die eigenen äußeren Pakete des Tunnels auf ein Halb-Default und werden zurück in den Tunnel geschickt. Das Ergebnis ist eine Verbindung, die beim nächsten Keepalive oder Handshake stirbt, ohne dass im Protokoll irgendetwas nach einem Routingfehler aussieht.

Bestätige die Form der Tabelle, bevor du irgendetwas anderes anfasst. ip route show sollte beide Hälften plus eine Host-Route für die Serveradresse auflisten; fehlt die Host-Route, hat der Rest der Untersuchung einen offensichtlichen Ausgangspunkt.

Warum die Halb-Defaults ohne Metrikänderung gewinnen

Eine niedrigere Metrik schlägt kein längeres Präfix. Die /1-Routen gewinnen, weil der Kernel zuerst die spezifischste Route abgleicht, sodass eine höhere Metrik auf der Default-Route nichts daran ändert, wohin tunnelgebundener Verkehr geht. Metriken zu jagen ist die häufigste falsche Abzweigung in dieser Diagnose.

Prüfe die Auswahl mit ip route get 203.0.113.10 und setze die echte Serveradresse ein. Die Antwort nennt die Schnittstelle und den nächsten Hop, die der Kernel tatsächlich verwenden würde, was aussagekräftiger ist, als eine Tabelle zu lesen und darüber nachzudenken.

Führe diesen Befehl aus, bevor der Tunnel startet, während er läuft und nach dem Lease-Ereignis. Drei Antworten aus einem Befehl, und der Punkt der Abweichung wird sichtbar.

Nimm drei Momentaufnahmen, nicht eine

Sammle die Zugangsadresse, das Zugangs-Gateway, das Ziel des Endpunkts, die ausgewählte Route und alle Policy-Regeln zu drei Zeitpunkten: nachdem die Zugangsstrecke konfiguriert ist, nachdem sich das VPN verbunden hat und nach dem Lease- oder Trägerereignis. Jede Momentaufnahme ist eine Handvoll Befehle, und sie bedeuten nur zusammen etwas. Eine einzelne Momentaufnahme nach dem Fehler hält den Zustand fest, nicht den Übergang. Schreibe die Befehle in ein kleines Skript, damit jede Momentaufnahme auf dieselbe Weise entsteht.

Halte die Momentaufnahmen in einer Datei mit Zeitstempeln, denn die interessante Frage ist später die Reihenfolge. Kam das DHCP-Ereignis, bevor oder nachdem OpenVPN seine Route erneuert hat? Die Antwort entscheidet, wer es reparieren muss. Ein Zeitstempel von der falschen Uhr ist schlimmer als keiner, also nimm ihn von dem Host, dem die Routingtabelle gehört.

Wenn der Endpunkt als Name statt als Adresse konfiguriert ist, löse ihn in jeder Momentaufnahme ebenfalls auf. Eine DNS-Änderung auf der Zugangsstrecke kann den Endpunkt verschieben, ohne dass irgendeine Route berührt wird.

Entscheide, welche Komponente die Ausnahme erneuert

Auf einem dhcpcd-System laufen Hooks aus dem Hook-Verzeichnis und aus dem Exit-Hook, und der Managermodus unterscheidet sich im Umfang vom Modus pro Schnittstelle. Was der Hook auch tut, es muss idempotent sein, denn Erneuerungen können in Schüben eintreffen.

Der zuverlässige Besitzer ist die Integration, die beide Seiten bereits kennt: ein Netzwerkmanager, der die VPN-Verbindung verwaltet, oder eine Unit, die nach dem Hochkommen der Zugangsstrecke geordnet ist. Eine von einem Hook hinzugefügte statische Route funktioniert bis zur nächsten Gateway-Änderung und scheitert dann auf genau dieselbe Weise. Wenn du doch einen Hook verwendest, lass ihn das aktuelle Gateway zur Laufzeit lesen, statt das fest zu verdrahten, das du heute gesehen hast.

Halte den Besitzer in der Konfiguration fest. Die nächste Person, die eine Wiederverbindung debuggt, muss wissen, dass ein Hook und nicht das VPN für die Ausnahme-Route zuständig ist.

Teste den Lebenszyklus, nicht nur die Wiederverbindung

Erzwinge eine Erneuerung mit dhcpcd -n eth0 oder indem du das Lease freigibst und neu beziehst, und prüfe dann ip route get erneut für den Endpunkt. Mach es zweimal, denn der zweite Lauf fängt Hooks ab, die doppelte Routen anhängen. Starte dann neu, denn Persistenz ist eine andere Eigenschaft als Korrektheit.

Ein Tunnel, der eine Erneuerung und einen Neustart übersteht, hat einen Besitzer und eine funktionierende Ausnahme. Einer, der nur einen manuellen Neustart übersteht, hat beides nicht und wird beim nächsten Ereignis scheitern, das du nicht planen kannst.