Zwei OpenVPN-Clients auf einem Linux-Host: Wem gehört die Route?

Beide Profile melden eine Verbindung, und eines davon trägt stillschweigend Verkehr, der für das andere bestimmt ist. Zwei Clients auf einem Host sind eine unterstützte Anordnung; zwei Clients ohne Eigentümer für jedes Präfix sind es nicht. Die Arbeit besteht weniger darin, den zweiten Tunnel hochzubringen, als darin zu entscheiden, welcher Prozess welche Route beanspruchen darf. Gehen Sie in der Reihenfolge unten vor, und die Konfiguration folgt aus den Antworten.

Fragen Sie zuerst, wofür der zweite Tunnel gedacht ist

Drei Situationen sehen auf der Statuszeile gleich aus und verlangen unterschiedliche Entwürfe. Eine Aufteilung nach Zielen schickt ein Präfix über das Büroprofil und ein anderes über das Laborprofil, wobei keines eine Standardroute beansprucht. Eine Aufteilung pro Anwendung behält meist einen vollen Tunnel und lenkt bestimmten Verkehr mit Policy-Regeln. Failover hält jeweils genau einen Tunnel aktiv, was bedeutet, dass der zweite nicht automatisch starten darf.

Schreiben Sie den Fall auf, bevor Sie irgendeine Konfigurationsdatei öffnen, denn diese Antwort entscheidet alles Weitere.

Die häufigste kaputte Anordnung sind zwei volle Tunnel, die beide eine Standardroute geschoben haben, wobei der zuletzt verbundene gewinnt und der erste weiter so tut als ob. Dieser Zustand wirkt auf der Statuszeile absichtlich und kostet einen Tag in der Routing-Tabelle. Wenn Sie den Fall zuerst benennen, wird er unmöglich statt nur unwahrscheinlich.

Sehen Sie sich die Pools vor den Routen an

Zwei Server geben leicht Adressen aus einem privaten Bereich aus, und dann landet der Client mit zwei Schnittstellen innerhalb eines einzigen Präfixes. Kein Ziel lässt sich dann per Adresse einer Schnittstelle zuordnen, weil beide gleich richtig aussehen. Nummerieren Sie einen Pool neu, statt eine Regel zu erfinden, die das Patt bricht.

Prüfen Sie auch das lokale Netz, denn ein Heim- oder Büro-LAN, das einen Tunnelbereich überlappt, erzeugt dieselbe Mehrdeutigkeit von der anderen Seite. Vergleichen Sie die Adressen auf dem Host mit beiden Serverkonfigurationen, bevor Sie den Client beschuldigen. Eine Pool-Änderung auf einem Laborserver ist eine Fünf-Minuten-Korrektur, während ein Policy-Routing-Umweg für ein überlappendes Präfix eine dauerhafte Steuer für alle ist, die die Konfiguration später lesen. Entscheiden Sie, was davon Sie wollen, bevor Sie wählen, wo Sie eingreifen.

Zwei Adressfamilien bedeuten zwei Runden dieser Prüfung. IPv6-Pools kollidieren genauso still wie IPv4.

Geben Sie jedem Profil einen Eigentümer

Eine Instanz pro Profil, eine Konfigurationsdatei pro Instanz und ein Name, der das Paar identifiziert. Bei Debian-artiger Paketierung wählt der Name nach dem At-Zeichen die Datei, weshalb zwei Profile mit demselben Instanznamen nie beide funktionieren können. Bestätigen Sie die Zuordnung an der installierten Unit und nicht an einem Tutorial.

systemctl cat [email protected]
ip -4 addr show

Dann entscheiden Sie, wer Routen installiert – das ist eine Frage der Politik und nicht der Syntax.

Wenn die beiden Server inkompatible Sätze schieben, fügen Sie entweder route-nopull hinzu und listen nur die Präfixe auf, die jedes Profil braucht, oder lassen Sie eines seine Standardroute behalten und lenken den Rest per Policy-Regel. Zwei Prozesse, die beide eine Standardroute installieren, enden mit einem einzigen Gewinner, und niemand kann sagen warum. Sobald die beiden Tunnel Verkehr für verschiedene Quellen tragen, kann eine Antwort über den falschen hinausgehen, und das Muster, das hält, ist eine Verbindungsmarke, die auf Antworten wiederhergestellt und in ihre eigene Tabelle gelenkt wird. Begrenzen Sie die Marken so, dass die eigenen verschlüsselten Pakete der Tunnel nie darauf passen.

Prüfen Sie pro Tunnel und stoppen Sie dann einen

Wenn beide oben sind, nehmen Sie drei Messungen: die Adresse auf jedem Tunnelgerät, die Route zu einem Host, der hinter jedem von beiden lebt, und den Weg, den ein Ziel außerhalb beider nehmen würde. Eine einfache Routenliste beschreibt die endgültige Suche nicht mehr, sobald Regeln im Spiel sind, also fragen Sie den Kernel, was er tatsächlich wählen würde. Stoppen Sie dann eine Instanz und beobachten Sie, was verschwindet. Wenn das Stoppen der ersten die zweite stört, ist noch etwas zwischen ihnen geteilt: eine Route, ein Gerätename oder eine Firewall-Regel, die niemand getrennt hat.

ip rule show
ip route get 203.0.113.9

Bringen Sie das gestoppte Profil zurück und wiederholen Sie dieselben Prüfungen, denn ein Tunnel, der nach einem Neustart einmal funktioniert und nie wieder, ist ein Lebenszyklusfehler im Routing-Kostüm.

Notieren Sie in den Deployment-Notizen, welches Profil welches Präfix besitzt, neben den Pool-Bereichen. Zwei Tunnel sind eine bewusste Anordnung, und der nächste Leser muss die Grenze sehen, bevor er eines der Profile anfasst. Ohne diese Notiz wird die Grenze von demjenigen neu entdeckt, der Bereitschaft hat, wenn das geteilte Präfix endlich bricht.