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

Zwei Profile sind verbunden, und eines davon trägt stillschweigend Datenverkehr, der für das andere bestimmt ist. Ein Linux-Host kann beide OpenVPN-Clients gleichzeitig ohne Schwierigkeiten betreiben. Was er nicht kann, ist für Sie zu entscheiden, welcher Prozess welches Präfix beanspruchen darf. Diese Entscheidung muss fallen, bevor der zweite Tunnel hochkommt, nicht nachdem eine Ressource aufhört zu antworten.

Beginnen Sie bei der Aufgabe, die die zweite Verbindung erfüllen muss

Ein Büro, das über ein Profil erreichbar ist, und ein Labor, das über ein anderes erreichbar ist, brauchen beide Tunnel oben und keinen von beiden, der alles beansprucht. Eine einzelne hartnäckige Anwendung, die über das zweite Profil hinaus muss, braucht eine Regel für die Richtlinie statt einer zweiten Standardroute. Eine Standby-Verbindung braucht nur einen laufenden Tunnel zur Zeit, also sollte die Reserve nicht mit der Maschine starten.

Das sind drei verschiedene Konfigurationen, und sie werden verwechselt, weil alle drei gleich beginnen: ein zweites Profil und eine erfolgreiche Verbindung. Schreiben Sie die beabsichtigte Anordnung zuerst auf und konfigurieren Sie dann darauf hin. Ein Satz über die Absicht spart eine Stunde Paketmitschnitt.

systemctl list-units --type=service 'openvpn-client@*'
ip -4 route show default

Der erste Befehl listet die laufenden Instanzen auf, einschließlich aller von Hand außerhalb des Managers gestarteten. Der zweite gibt den aktuellen Standardanspruch aus, also den Zustand, den Sie später erklären müssen.

Überlappende Pools brechen, bevor das Routing bricht

Zwei Server verteilen fröhlich Adressen aus demselben 10.8.0.0/24. Der Client hält dann zwei Schnittstellen innerhalb eines Präfixes, und nichts sagt, welche Destination zu welcher gehört; das resultierende Verhalten sieht wie ein Routingfehler aus, ist aber ein Nummerierungsfehler. Einen Pool neu zu nummerieren kostet eine Konfigurationsänderung; jeder spätere Routing-Behelf kostet ein Wochenende. Prüfen Sie den Pool, bevor Sie eine Route dafür hinzufügen.

Sehen Sie sich auch das lokale LAN an. Ein Heim-LAN mit der Nummer 192.168.1.0/24, das ein Tunnel ebenfalls offenlegt, erzeugt dieselbe Mehrdeutigkeit, und das Symptom ist ein Hostname, der sich auflöst, während die Verbindung nie zustande kommt. Das sieht wie ein Namensauflösungsfehler aus, bis Sie die Routen ausgeben.

ip -4 addr show
ip route show table all | grep -E '10\.|192\.168\.'

Vergleichen Sie beide Ausgaben mit den beiden Serverkonfigurationen, bevor Sie den Client anfassen. Wenn die Präfixe überlappen, stoppen Sie und nummerieren Sie neu, denn kein Neustart wird sie trennen.

Geben Sie jedem Profil seine eigene Unit und jedem Präfix einen Eigentümer

Jedes Profil bekommt seinen eigenen Instanznamen und seine eigene Konfigurationsdatei, sodass die Instanz office die office.conf lädt, während die Instanz lab die lab.conf lädt. Bestätigen Sie diese Zuordnung über den Dienstmanager, statt einem Verzeichnislisting zu vertrauen, denn ein Drop-in kann ändern, welche Datei geladen wird. Wer die Zuordnung verwechselt, stimmt das Profil ab, das nicht läuft.

Legen Sie dann fest, wer Routen installiert. Wenn die Server inkompatible Sätze pushen, lehnen Sie entweder den Push ab und listen die Präfixe selbst auf, oder lassen Sie ein Profil die Standardroute behalten und lenken das andere mit Richtlinienregeln. Zwei Prozesse, die beide eine Standardroute installieren, enden mit einem stillen Gewinner und ohne schriftlichen Beschluss.

systemctl cat [email protected]
grep -E 'route-nopull|pull-filter|redirect-gateway' /etc/openvpn/client/lab.conf

Der erste zeigt die Unit mit jeder Überschreibung, die ihre Argumente ändert. Der zweite zeigt, ob das Profil gepushte Routen überhaupt akzeptiert, und das ist der Schalter, der alles Weitere bestimmt.

Markierungen halten Antworten auf der Schnittstelle, von der sie kamen

Wenn jeder Tunnel unterschiedliche Quellen bedient, kann eine Antwort über die falsche Verbindung hinausgehen, und die Verbindung stirbt nach dem ersten Paket. Das Muster, das hält, ist: ankommende Pakete nach Eingangsschnittstelle markieren, diese Markierung in der Antwort wiederherstellen und jeder Markierung eine Tabelle mit eigenem Standard-Gateway geben.

Lockere Reverse-Path-Filterung muss für die betroffenen Schnittstellen normalerweise gelockert werden, weil eine Antwort berechtigt über eine Verbindung ankommt, die die Haupttabelle nie wählen würde. Halten Sie die Markierungen eng, damit sie nie den eigenen verschlüsselten Verkehr der Tunnel einfangen, was den Tunnel durch sich selbst schicken würde.

ip rule show
ip route show table 101
sysctl net.ipv4.conf.all.rp_filter

Lesen Sie die bestehenden Regeln, bevor Sie eine weitere hinzufügen. Doppelte Prioritäten und vergessene Tabellen sind der übliche Grund, warum eine Markierungsrichtlinie völlig wirkungslos erscheint.

Beweisen Sie die Isolation, indem Sie eine Verbindung stoppen

Notieren Sie bei beiden laufenden Tunneln jede Schnittstellenadresse, die Route zu einem Host hinter jedem Tunnel und den Weg, den ein unabhängiges Ziel nimmt. Fragen Sie den Kernel nach dem Lookup, statt eine einzelne Tabelle zu lesen, denn eine Tabelle zeigt nie die endgültige Entscheidung.

Stoppen Sie dann eine Instanz und beobachten Sie, wie ihre Schnittstelle und ihre Routen verschwinden, während die andere weiterläuft. Ein Bruch bei der überlebenden bedeutet, dass beide noch einen Gerätenamen, eine Route oder eine Firewallregel teilen, die niemand getrennt hat.

Bringen Sie das gestoppte Profil zurück und wiederholen Sie dieselben Prüfungen. Wenn ein Tunnel nur den ersten Start nach einem Neustart überlebt, sehen Sie einen Lebenszyklusfehler und kein Routing-Design.