Öffentliches Präfix über OpenVPN: den Rückweg reparieren

Man sieht den Tunnel hochkommen und den Client die Gegenseite anpingen, und dann antwortet eine öffentliche Adresse, die hinter dem VPN liegt, von woanders – oder gar nicht. Dieses Symptom hat meist nichts mit der Verschlüsselung oder den Zertifikaten zu tun. Ein vom Anbieter geroutetes Präfix wird als IP-Route geliefert, und es über OpenVPN zu führen bedeutet, diese Route auf zwei Ebenen nachzubilden und die Quelladresse auf dem Rückweg zu erhalten. Das WAN zu bridgen ist nicht erforderlich, und das Hinzufügen der Adresse zu einem Interface erzeugt nicht die Upstream-Route.

Das Präfix muss zuerst zu Ihnen geroutet werden

Fragen Sie den Anbieter, wie der Block bereitgestellt wird. Ein Präfix, das auf die Hauptadresse Ihres Servers geroutet wird, ist etwas anderes als Adressen, die der Anbieter direkt auf einem WAN-Segment erwartet. Nur das erste Modell funktioniert mit dem Design hier.

Wenn der Anbieter 198.51.100.64/28 zu Ihrem Einstiegsserver routet, kommen Pakete für diesen Bereich am Server an und bleiben dort stehen, sofern Sie sie nicht weiterleiten. Wenn der Anbieter den Bereich stattdessen auf Ihren Uplink bridgt, muss der Server ARP dafür beantworten, was ein anderes Problem ist.

Testen Sie das Bereitstellungsmodell, bevor Sie OpenVPN anfassen: Pingen Sie von außen eine Adresse im Block an und beobachten Sie, welches Interface sie empfängt. Wenn nichts ankommt, hilft keine noch so umfangreiche Tunnelkonfiguration. Wenn die Adresse direkt am WAN antwortet, bridgt der Anbieter, statt zu routen, und das folgende Design greift nicht.

Zwei Routing-Ebenen: Kernel-Route und iroute

OpenVPN braucht das Präfix an zwei Stellen. Der Kernel muss wissen, dass das Präfix zum Tunnel-Device gehört, damit weitergeleitete Pakete in OpenVPN landen statt in der Default-Route. OpenVPN muss außerdem wissen, welcher authentifizierte Client das Präfix besitzt, und das ist der iroute-Eintrag im clientspezifischen Verzeichnis.

Die serverseitige Route sieht so aus, wobei Präfix und Maske zur Zuweisung passen müssen:

ip route add 198.51.100.64/28 dev tun0

Die clientspezifische Konfiguration weist den Besitz zu. Legen Sie sie in der CCD-Datei ab, die nach dem Common Name des Client-Zertifikats benannt ist, und prüfen Sie, dass das Verzeichnis dasjenige ist, das der Server tatsächlich liest:

iroute 198.51.100.64 255.255.255.240

Die OpenVPN-Dokumentation zu gerouteten Netzen beschreibt beide Ebenen und warum sie getrennt sind. Eine Kernel-Route ohne iroute schickt Pakete ohne Besitzer in den Tunnel, und OpenVPN verwirft sie. Ein iroute ohne Kernel-Route lässt Pakete auf dem Default-Pfad des Servers. Beide Fehler sehen von der Client-Seite wie ein kaputter Tunnel aus.

Wo die Dienstadresse liegt

Das delegierte Präfix ist nicht dasselbe wie die eigenen Adressen des Tunnels. Nummerieren Sie die Link-Strecke nach Belieben aus dem privaten Raum, und platzieren Sie die öffentliche Dienstadresse dort, wo der Dienst tatsächlich läuft.

Auf einem Linux-Client, der den Dienst lokal terminiert, genügt eine einzelne Host-Adresse:

ip address add 198.51.100.70/32 dev lo

Wenn das Präfix weiter zu einem VM-Host oder einem anderen LAN geroutet wird, konfigurieren Sie stattdessen diesen Downstream-Pfad und seine Rückroute. Jede Adresse im Block dem VPN-Client zuzuweisen ist nicht nötig und schafft später Konflikte.

Die öffentliche Quelle auf dem Rückweg bewahren

Eine Antwort aus dem delegierten Präfix muss durch den Tunnel hinausgehen und die Route des Anbieters erreichen. Wenn der Remote-Host sie über seinen eigenen ISP sendet, wirkt die Quelladresse gefälscht, und der Anbieter oder das Ziel verwirft sie. Die Lösung ist eine quellbasierte Regel oder eine dedizierte Routing-Tabelle, kein breiteres NAT. Ohne sie funktioniert der Dienst vom Tunnel-Peer aus und scheitert von überall sonst.

Am Einstiegsserver ist eine breite Masquerade-Regel der übliche Übeltäter. Sie schreibt die öffentliche Quelle in die Hauptadresse des Servers um, und der Client sieht die echte nie:

iptables -t nat -S POSTROUTING

Beschränken Sie NAT auf die privaten VPN-Clients, die es brauchen, und lassen Sie das delegierte Präfix unübersetzt. Prüfen Sie dann, ob der Server das Präfix überhaupt weiterleitet, denn eine Forward-Kette mit Default-Deny verwirft es stillschweigend.

Prüfen Sie beide Richtungen, bevor Sie sich darauf verlassen

Die Verifikation besteht aus vier Beobachtungen, nicht aus einer. Bestätigen Sie, dass die Route des Anbieters ankommt, der Kernel das Präfix in den Tunnel schickt, OpenVPN es dem richtigen Client zuordnet und die Antwort mit intakter öffentlicher Quelle zurückkommt. Jede Beobachtung hat ihr eigenes Kommando, sodass ein Fehler auf eine Schicht zeigt statt auf das ganze Design. Führen Sie sie nach jeder Konfigurationsänderung in dieser Reihenfolge aus.

Fragen Sie den Kernel, welchen Pfad eine delegierte Adresse nimmt, und beobachten Sie den Tunnel, während eine Anfrage läuft:

ip route get 198.51.100.70
sudo tcpdump -ni tun0 host 198.51.100.70

Reverse-Path-Filtering kann eine korrekte Route zunichtemachen. Prüfen Sie die effektive Einstellung am Tunnel und am Uplink, und bedenken Sie, dass ein strikter Modus Verkehr ablehnt, dessen Quelle nicht zum Interface passt, auf dem er ankam:

sysctl net.ipv4.conf.tun0.rp_filter net.ipv4.conf.eth0.rp_filter

Testen Sie schließlich den Fehlerfall. Stoppen Sie den Tunnel und bestätigen Sie, dass das öffentliche Präfix nicht über den gewöhnlichen Uplink leckt. Das Wiederherstellen des VPN sollte den Dienst zurückbringen, ohne zu erweitern, welche Ports der Host öffnet.