OpenVPNs „File exists“ auf einer Route ist kein Dateiproblem

Beginnen Sie dort, wo die Meldung erscheint. Ein Client verbindet sich, der Tunnel kommt hoch, und dann meldet das Protokoll, dass der Linux-Befehl zum Hinzufügen der Route mit File exists fehlgeschlagen ist. Nichts in diesem Satz bezieht sich auf ein Zertifikat, einen Schlüssel oder eine Konfigurationsdatei, auch wenn die Worte das nahelegen. Der Kernel beschreibt seine Routentabelle, und das Präfix, das Sie installieren ließen, hat bereits einen Eintrag.

Folgen Sie der eigenen Reihenfolge des Clients: was er angefordert hat, was die Tabelle bereits enthielt, wer diesen Eintrag dort platziert hat und erst dann, was zu ändern ist. Jeder Schritt entfernt einen möglichen Eigentümer.

Wonach der Client tatsächlich gefragt hat

Vor dem Fehler protokolliert der Client die Route, die er hinzufügen will, meist als Ziel, Netzmaske, Gateway und manchmal als Metrik oder Tabelle. Diese Zeile ist die Anfrage. Der folgende Fehler ist die Antwort des Kernels darauf, und beide gehören beim Lesen des Protokolls nebeneinander.

journalctl -u openvpn-client@office -b --no-pager | grep -nE 'route|File exists'
openvpn --config /etc/openvpn/client/office.ovpn --verb 4 --log /tmp/ovpn.log

Ein Exit-Status ungleich null des Routen-Helfers ist weniger aussagekräftig als der Text darunter, weil verschiedene Kernel-Antworten einen Status ungleich null erzeugen. Behalten Sie die genaue Meldung; die Unterscheidung zwischen einem vorhandenen Eintrag und einem nicht erreichbaren Gateway entscheidet, welcher der nächsten Abschnitte gilt.

Lesen Sie die vorhandene Route, nicht nur die Adresse

Die Tabelle nach demselben punktierten Quadrupel zu durchsuchen, reicht nicht. Ein Routenobjekt wird durch Adressfamilie, Tabelle, Zielpräfix, Metrik, Protokoll und Ausgabegerät bestimmt, und Einträge, die ein Präfix teilen, können legitim nebeneinander bestehen, wenn sich diese Attribute unterscheiden. Es kollidiert das ganze Objekt, nicht der Text.

ip -4 route show table all | grep -F '10.40.'
ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5

Der letzte Befehl beantwortet eine andere Frage als die ersten beiden: nicht, was existiert, sondern welchen Eintrag der Kernel für dieses Ziel gerade jetzt auswählen würde. Beide Ansichten sind nützlich, und sie weichen oft genug voneinander ab, dass ein Vergleich lohnt, bevor Sie etwas schließen. Die Abweichung zwischen ihnen ist der interessante Fall, kein Rundungsfehler.

Notieren Sie Präfix, Tabelle, Metrik und Gerät neben der fehlgeschlagenen Anfrage. Hat der vorhandene Eintrag dieselben Attribute und denselben nächsten Hop, liegt eine doppelte Anweisung vor, kein Routingproblem.

Vier Eigentümer, die ein Präfix haben kann

Verbundene Routen stammen aus einer zugewiesenen Adresse und werden vom System neu erzeugt, sobald diese Adresse existiert. Ein DHCP-Client oder ein Verbindungsmanager installiert Routen als Teil seines eigenen Lebenszyklus. Ein anderer VPN-Client trägt das gleiche Präfix möglicherweise bereits. Und ein lokaler Hook oder ein Skript kann eine hinzufügen, von der sonst nichts weiß.

Jeder Eigentümer braucht eine andere Korrektur. Eine verbundene Route ist nicht Ihre zum Löschen; ihr Entfernen kann den lokalen Zugriff brechen, bevor der Tunnel nutzbar ist, und der Kernel legt sie wieder an. Eine manager-eigene Route sollte über diesen Manager geändert werden, nicht mit einem manuellen ip route del, das die nächste Wiederverbindung rückgängig macht.

Eine beibehaltene Schnittstelle macht dieselbe Verwirrung leichter. Wenn das Tunnelgerät eine Wiederverbindung überlebt, können vom eigenen Setup-Code installierte Routen beim zweiten Lauf noch vorhanden sein, sodass ein Skript, das einen sauberen Zustand annimmt, beim zweiten Mal scheitert und beim ersten funktioniert. Räumen Sie den veralteten Eintrag bewusst auf oder machen Sie den Setup-Code idempotent.

block-local beantwortet eine andere Frage

Wenn ein Profil den gesamten Verkehr durch den Tunnel schickt, muss der Client entscheiden, was mit dem lokalen Netzwerk geschieht. Das Flag block-local ändert diese Entscheidung, indem es das lokale LAN durch den Tunnel leitet und die dokumentierte Ausnahme für das LAN-Gateway beibehält; das ist eine verkehrspolitische Wahl mit sichtbaren Folgen für die Erreichbarkeit.

Es erklärt nicht, warum ein Routen-Hinzufügen einen Fehler über einen bestehenden Eintrag zurückgab, und es als universelle Reparatur zu übernehmen, versteckt den eigentlichen Konflikt hinter einer Richtlinienänderung. Wenn Ihre lokalen Ressourcen nach einer Profilbearbeitung nicht mehr erreichbar sind, ist dieses Flag eines der ersten Dinge, die zu prüfen sind; wenn ein Routen-Hinzufügen scheitert, ist es nicht die Antwort.

Behandeln Sie es als eine Entscheidung darüber, welche Ziele lokal bleiben, bewusst getroffen und aufgeschrieben. Es ist kein Schalter zum Ausprobieren, wenn das Protokoll alarmierend aussieht.

Schließen Sie den Kreis: Entfernen Sie das Duplikat an seiner Quelle

Sobald Sie wissen, welcher Eigentümer den Eintrag hält, entfernen Sie die doppelte Anweisung dort, wo sie definiert ist. Das kann eine route-Zeile im Profil sein, ein Push vom Server oder ein Hook, der nicht mehr laufen muss.

ip -4 route show match 10.40.0.0/16
ip -4 route get 10.40.0.5
journalctl -u openvpn-client@office -b --no-pager | tail -n 15

Verbinden Sie sich dann erneut und bestätigen Sie drei Dinge: Der Tunnel kommt hoch, das beabsichtigte Ziel löst sich in den gewünschten Pfad auf, und der Fehler ist verschwunden, ohne dass an seiner Stelle ein neuer auftaucht. Ein sauberes Protokoll mit falsch gewähltem Pfad ist keine Reparatur.

Wenn das Präfix auf der einen Seite das lokale LAN und auf der anderen ein entferntes Netz bedeutet, ist das Problem eine Adressüberlappung und kein Duplikat, und keine noch so große Löschaktion macht beide Bedeutungen gleichzeitig wahr. Dieser Fall braucht einen anderen Plan für eines der beiden Netze. Entscheiden Sie, welche Seite umnummeriert wird, bevor Sie eine von beiden anfassen.