Warum ist das Subnetz hinter einem OpenVPN-Client nicht erreichbar?

Pings an die Tunneladresse des Servers gelingen, die eigene Routentabelle des Clients sieht richtig aus, und das LAN hinter diesem Client bleibt unerreichbar. Die Routing-Tabelle des Clients sieht korrekt aus, der Server hat eine Route zum Tunnel, und Pakete verschwinden trotzdem. Das ist das klassische Symptom eines Layer-3-Tunnels, der nicht weiß, dass einer seiner Clients zugleich ein Gateway ist.

Ein tun-Interface hat keinen Next Hop pro Client. Der Kernel sieht eine einzige Schnittstelle mit vielen Peers, daher muss die Entscheidung, welcher Client ein Paket für ein entferntes LAN erhalten soll, innerhalb des OpenVPN-Prozesses fallen. Diese Entscheidung wird mit iroute konfiguriert, und ohne sie hat das Paket keinen Weg.

Der Server routet nach Client, nicht nach Interface

Wenn der Server ein Paket an die Tunneladresse eines Clients senden muss, ist die Antwort eindeutig: Die Adresse gehört zur Sitzung dieses Clients. Ist das Ziel ein ganzes Subnetz hinter diesem Client, gehört die Adresse niemandem, den der Server kennt, und die Kernel-Route zum Tunnel sagt nur "über diese Schnittstelle hinaus", ohne den Peer zu nennen.

OpenVPN löst das mit einer internen Routentabelle, die ein Zielpräfix einem bestimmten Client zuordnet. Diese Tabelle wird aus iroute-Einträgen aufgebaut, deshalb reicht eine gewöhnliche Route auf dem Server-Host nicht aus. Die Kernel-Route bringt das Paket zur Tunnelschnittstelle; die interne Zuordnung entscheidet, welche Sitzung es erhält. Deshalb taucht die Reparatur nie in der Routenausgabe des Kernels auf.

Fehlt die Zuordnung, kommt das Paket am Server an, passt zur Tunnelroute und wird verworfen, weil kein Client das Ziel beansprucht. Nichts protokolliert einen sauberen Fehler, deshalb sieht der Ausfall wie ein stilles schwarzes Loch aus und nicht wie eine Routingschleife.

Den iroute-Eintrag schreiben, der den Client benennt

iroute lebt in einer client-spezifischen Konfigurationsdatei, nicht in der Hauptkonfiguration des Servers. Richte den Server mit der Option client-config-dir auf ein Verzeichnis, erstelle dann eine Datei, deren Name der Common Name des Client-Zertifikats ist, und lege das Präfix hinein.

Für eine Filiale mit LAN 10.20.0.0/24 und dem Zertifikat-Common-Name branch-router enthält die Datei unter diesem Pfad eine Zeile wie iroute 10.20.0.0 255.255.255.0. Die Hauptkonfiguration braucht nur die Verzeichnisoption; das Präfix lebt beim Client.

Der Common Name ist der brüchige Teil. Ein mit anderem Subject ausgestelltes Zertifikat oder eine Bereitstellung, die Benutzer per Benutzername authentifiziert, während die Datei nach dem Zertifikat benannt ist, erzeugt eine Datei, die nie gelesen wird. Prüfe den Namen, den der Server für die Sitzung tatsächlich meldet, und erwäge die Option, die einen nicht passenden Client scheitern lässt, statt ihn stillschweigend ohne seine Routen zu verbinden. Die Datei passend zum Zertifikat umzubenennen ist eine Fünf-Minuten-Korrektur, die einen sehr langen Abend verhindert.

Ein Client kann mehrere Präfixe besitzen. Füge eine iroute-Zeile pro Netz hinzu und halte die Liste neben den übrigen Einstellungen dieses Clients, damit die Zuordnung nachvollziehbar bleibt.

Den Rückweg in beide Richtungen aufbauen

Pakete zum entfernten LAN zu bringen ist die halbe Arbeit. Der Client muss den Verkehr dieses LANs auch in den Tunnel schicken, was normalerweise durch Pushen einer Route an den Client geschieht: Eine Zeile wie push "route 10.8.0.0 255.255.255.0" sagt jedem Client, wie er das Netz auf der Serverseite erreicht. Für die Filiale zeigt die entsprechende Route auf den Tunnel, für alles, was sie auf der Serverseite erreichen soll.

Die Rückrichtung braucht einen Verantwortlichen auf der Gegenseite. Dort muss jemand den Weg zurück kennen: eine statische Route auf dem LAN-Router, die den VPN-Pool auf den Server zeigt, oder Adressübersetzung auf dem Server, bevor Verkehr ins LAN gelangt. Die statische Route hält die Originaladressen in Protokollen und Zugriffsregeln sichtbar, verlangt aber die Mitarbeit des LAN-Betreibers; Übersetzung ist eigenständig, verbirgt aber, wer sich tatsächlich verbunden hat.

Forwarding muss auf dem Server-Host aktiviert sein. Ohne es nimmt der Kernel das Paket vom Tunnel an und weigert sich, es an das LAN-Interface weiterzugeben, was aus Sicht des Clients identisch zu einer fehlenden iroute aussieht.

Erreichbarkeit mit den richtigen Sonden prüfen

Teste schichtweise, statt das andere Ende anzupingen und zu raten. Prüfe vom Server, dass die interne Zuordnung für das Präfix existiert und dass die Kernel-Route zum Tunnel zeigt. Bestätige vom Client, dass die gepushte Route installiert ist und sein Standardweg zur LAN-Adresse der Tunnel ist.

Beobachte dann die Pakete. Eine Aufzeichnung an der Tunnelschnittstelle zeigt, ob der Server zum Client überträgt, und eine Aufzeichnung an der LAN-Schnittstelle zeigt, ob er weiterleitet. Zeigt die erste Pakete und die zweite nichts, sind Weiterleitung oder ein Filter das Problem; zeigen beide nichts, ist die Suche früher gescheitert.

Zwei durch einen Tunnel verbundene Server wiederholen dieselbe Regel auf beiden Seiten: Jeder braucht eine iroute für den Pool des anderen, und jeder braucht die Route und das Forwarding, die den Weg symmetrisch machen. Routing und Policy sind hier getrennte Angelegenheiten. Routing entscheidet, wohin ein Paket kann, während eine FORWARD-Regel entscheidet, ob es darf, also erreicht ein Client mit zwei iroute-Zeilen beide Präfixe, sofern kein Filter etwas anderes sagt.