OpenVPN iroute gegen Kernelroute: Welche fehlt?

Ein Paket für 10.77.20.0/24 trifft auf einem OpenVPN-Server zwei getrennte Entscheidungen: Das Betriebssystem muss es an die VPN-Schnittstelle übergeben, und OpenVPN muss wissen, welcher verbundene Client dieses Präfix besitzt. Eine fehlende Kernel-Route verwirft es vor dem Tunnel, eine fehlende Peer-Route danach. Die beiden Fehler sehen vom entfernten LAN identisch aus, und die Diagnose, welchen Sie haben, erfordert je einen Befehl auf beiden Seiten.

Im klassischen Userspace-Datenpfad bringt die Kernel-Route das Paket in den Tunnelprozess, und iroute sagt diesem Prozess, welcher Peer es erhalten soll. Keines ersetzt das andere, und eine Konfiguration mit nur einem von beiden wirkt vernünftig bis zum ersten Ping.

Zwei Entscheidungen, nicht eine Route

Stellen Sie sich eine Standort-zu-Standort-Verbindung vor, bei der 10.77.20.0/24 hinter einem einzigen Client liegt. Die Kernel-Route des Servers, zum Beispiel ip route add 10.77.20.0/24 dev tun0, schickt passende Pakete an das Tunnelgerät. Dann zieht OpenVPN seine eigene interne Tabelle heran, die aus iroute-Einträgen im Konfigurationsverzeichnis des Clients aufgebaut ist, um zu entscheiden, welche Peer-Verbindung sie erhält. Ohne die Kernel-Route erreicht das Paket den Prozess nie, und ohne die Peer-Route erreicht es den Prozess und kommt nirgendwo an.

Diese Trennung vergisst man leicht, weil eine einzige Routenzeile in einem Clientprofil so aussehen kann, als erledige sie beide Aufgaben. Das tut sie nicht: Eine Route zu pushen sagt Clients, was sie durch den Tunnel senden sollen, während iroute dem Server sagt, wer einen Adressbereich hinter einem Client besitzt. Sie liegen in verschiedenen Dateien, werden von verschiedenen Seiten gelesen und scheitern in entgegengesetzten Richtungen.

Wohin iroute gehört und was es aussagt

Der Eintrag gehört in eine Datei pro Client, benannt nach dem common_name des Clients, unter client-config-dir, als iroute 10.77.20.0/24. Die Übereinstimmung des Dateinamens ist nicht kosmetisch: OpenVPN schlägt die authentifizierte Identität nach und liest die Datei mit genau diesem Namen, sodass eine Datei namens site-a nur für einen Client wirkt, dessen Common Name site-a ist. Fügen Sie ccd-exclusive hinzu, wenn Clients ohne eine solche Datei rundweg abgelehnt werden sollen, was die richtige Einstellung ist, wenn jeder Client ein Standort-Gateway ist. Halten Sie eine Datei pro Gateway und benennen Sie sie nach dem Zertifikatssubjekt, das Sie tatsächlich ausstellen.

Testen Sie den Eintrag vom Server aus, bevor Sie das entfernte LAN beschuldigen. Die Statusdatei listet verbundene Clients mit ihren Common Names, und ein Server mit --verb 4 protokolliert das Installieren von iroute, sobald der Peer sich verbindet. Erscheint beim Verbinden nichts, liegt die Datei im falschen Verzeichnis oder benennt die falsche Identität.

Die Falle: Datei vorhanden, falsche Identität

Ein korrekt aussehendes iroute, das am falschen Peer hängt, kostet mehr Zeit als eine fehlende Datei, weil auf der Platte alles richtig aussieht. Zertifikatsumbenennungen, doppelte Common Names und username-as-common-name, das die effektive Identität ändert, erzeugen das alles. Prüfen Sie, welche Identität der Server authentifiziert hat, statt welche Sie erwartet haben: Die Statusausgabe ist maßgeblich, der Dateiname nur ein Suchschlüssel.

Eine Route kann ihren Besitzer überleben. Statische Routen und iroute-Einträge beschreiben ein Präfix, keine Verfügbarkeitsgarantie, sodass Verkehr weiter zu einem Peer geleitet werden kann, der gerade getrennt ist.

Vervollständigen Sie den Pfad hinter dem Peer

Die Peer-Zugehörigkeit ist die Mitte des Pfades, nicht das Ende. Der Client muss Pakete aus dem Tunnel in sein LAN weiterleiten, was IP-Weiterleitung auf diesem Host und eine Firewall-Regel erfordert, die den Durchgang erlaubt. Hosts im entfernten LAN brauchen einen Rückweg für die Tunneladresse: entweder eine Route zurück zum Gateway oder ein bewusstes NAT-Design auf Clientseite. Bestätigen Sie die Weiterleitungseinstellung auf dem Client mit sysctl net.ipv4.ip_forward, statt eine Distributionsvorgabe anzunehmen.

Müssen andere VPN-Clients dieses Subnetz erreichen, wächst die Anordnung erneut: Der Server braucht client-to-client, und diese Clients müssen das Präfix durch den Tunnel routen. Nichts davon ergibt sich aus der eigenen Routentabelle des Servers.

Prüfen Sie ein Ziel von einer echten Quelle aus statt vom Server selbst. Ein Ping von einem unbeteiligten LAN-Host zu einem Host hinter dem Client beansprucht den Rückweg, die Weiterleitungsregel und die Peer-Zugehörigkeit in einem Zug, während ein erfolgreicher Handshake nur die Identität belegt. Trennen Sie dann den besitzenden Peer und notieren Sie, was die Route tut, denn diese Antwort ist Ihr Fehlerbild.