VPN-Clients erreichen den Server, aber nicht das LAN: Welche Lösung?

Der Client pingt die Tunneladresse des OpenVPN-Servers an und bekommt eine Antwort, dann probiert er einen Host im LAN des Servers aus und bekommt nichts. Diese Trennung engt den Fehler erheblich ein: Der Tunnel steht, die Weiterleitung funktioniert wahrscheinlich, und die Antwort verlässt das Netz durch eine Tür, die nicht zurückführt. Es gibt drei Lösungen, und die richtige hängt davon ab, was Sie kontrollieren und worauf Sie verzichten wollen. Beantworten Sie die drei Fragen unten der Reihe nach, und die Wahl ist keine Geschmacksfrage mehr.

Zuerst prüfen, in welche Richtung der Fehler liegt

Die Anfrage kommt auf dem Tunnelinterface mit einer Quelladresse aus dem VPN-Pool an. Der Server leitet sie an den LAN-Host weiter, und dieser Host antwortet dem Gateway, das seine eigene Tabelle nennt, normalerweise dem LAN-Router. Hat der Router keine Route für den Pool, stirbt die Antwort dort oder wandert in Richtung Internet.

Testen Sie beide Maschinen, bevor Sie eine davon ändern. Fragen Sie auf dem Server die Routing-Tabelle, wie sie einen Client erreichen würde; fragen Sie auf dem LAN-Host, wie er dieselbe Adresse erreichen würde. Der erste Lookup zeigt meist auf den Tunnel, der zweite auf den LAN-Router, und dieser Unterschied ist der Fehler in einer Zeile. Zwei Lookups sind billiger als ein Firewall-Audit und sie klären die Richtung des Problems.

ip route get 10.8.0.37
sysctl -n net.ipv4.ip_forward

Wenn der LAN-Host bereits auf den VPN-Server zeigt, ist Ihr Problem eine Firewall-Regel oder eine MTU-Grenze und kein fehlender Rückweg. Fügen Sie keine Route hinzu, um einen Filter zu beheben.

Frage eins: Können Sie den Router des fernen LAN bearbeiten?

Wenn der LAN-Router Ihnen gehört, ist eine statische Route für den VPN-Pool mit der LAN-Adresse des VPN-Servers als Next Hop die saubere Antwort. Sie lässt die Quelladressen der Clients intakt, was zählt, wenn LAN-Hosts nach Adresse protokollieren, filtern oder drosseln. Sie braucht auch keine Übersetzung auf dem Server, sodass der Tunnel ein reiner Routing-Pfad bleibt. Die Pflicht, die sie erzeugt, ist Dokumentation, denn Pool, Route und Serverkonfiguration müssen übereinstimmen.

Sie versagt still an dem Tag, an dem jemand den Pool ändert. Schreiben Sie den Wert einmal auf und behandeln Sie eine Änderung an einer der drei Stellen als Änderung an allen.

Ein NAS oder ein Layer-3-Switch, der den Dienst hostet, braucht dieselbe Route, es sei denn, er schickt alles über einen Router, der sie hat. Prüfen Sie das Gerät, das das Subnetz terminiert, nicht nur das zur Internetseite. Kleine Netze haben oft drei Geräte mit einer Meinung zum Routing.

Frage zwei: Darf das LAN die Client-Adressen nicht mehr sehen?

Wenn der Router jemand anderem gehört, braucht die Übersetzung auf dem VPN-Server keine Zusammenarbeit. Der LAN-Host sieht die LAN-Adresse des Servers, antwortet ihr, und der Server übersetzt zurück. Deshalb verhalten sich Appliances und NAT-basierte Remote-Access-Rollen so.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE

Der Preis ist die Zuordnung: Adressen pro Client verschwinden aus den LAN-Logs. Jede Allowlist auf dem LAN-Host muss dann den Server nennen statt den Pool.

Wählen Sie die Übersetzung, wenn Zusammenarbeit nicht verfügbar ist, nicht wenn sie bloß unbequem ist. Sie versteckt den Client vor jeder künftigen Untersuchung, auch vor denen, in denen Sie wissen müssen, welcher Laptop eine Verbindung geöffnet hat. Sie kann auch Protokolle brechen, die Adressen in Nutzlasten einbetten, weil die Übersetzung im Header lebt. Keine der beiden Optionen ist fortschrittlicher; sie beantworten verschiedene Fragen zum Eigentum.

Frage drei: Ist der Server selbst Client eines anderen Tunnels?

Stellen Sie sich die andere Topologie vor: Der VPN-Server wählt sich zusätzlich bei einem kommerziellen Anbieter ein, hat also zwei Tunnel und zwei Adresssätze. Verkehr, den er für seine eigenen Clients weiterleitet, verlässt das Netz über den Anbieter, und der routet Antworten nicht zurück an Pool-Adressen. Deshalb verschwinden Antworten, obwohl beide Tunnel gesund sind.

Die Lösung ist, auch den ausgehenden Tunnel zu maskieren, damit der Anbieter nur die Tunneladresse des Servers sieht. Die Gegenrichtung braucht ihre eigene Regel, denn ein Server, der eine Verbindung zu einem seiner eigenen Clients aufbaut, ist ein anderer Fluss. Ohne diese Regel antwortet der Client einer Adresse, die er nicht routen kann. Setzen Sie die enge Regel vor jede breite Maskerade, damit die spezifische Übersetzung gewinnt.

iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o tun1 -j MASQUERADE
iptables -t nat -A POSTROUTING -d 10.8.0.0/24 -o tun0 -j SNAT --to-source 10.8.0.1

Multihomed-Hosts fügen einen verwandten Fehler hinzu, der aus Sicht des Clients identisch aussieht. Die Antwort verlässt das System über das Interface mit der niedrigeren Metrik, weil die Quelladresse aus einer anderen Tabelle gewählt wurde. Prüfen Sie den Rückweg mit einem Lookup, statt anzunehmen, der Hinweg impliziere ihn.

Dann beide Richtungen und beide Größen prüfen

Pingen Sie nach der Änderung vom Client zu einem LAN-Host und dann vom LAN-Host zum Client. Die zweite Richtung ist die, die man überspringt, und sie ist die, die eine unvollständige Übersetzungsregel aufdeckt. Halten Sie beide Ergebnisse mit Zeitstempel fest, damit eine spätere Regression vergleichbar ist.

Bewegen Sie dann echte Daten, denn ein kleiner Ping, der gelingt, während eine große Übertragung stockt, ist ein MTU-Symptom. Dieser Fehler erscheint direkt, nachdem Sie sich zum gelösten Routing beglückwünscht haben.

Testen Sie schließlich nach einem Neustart erneut. Laufzeitbefehle für Routen und Firewall überleben keinen, und eine Lösung, die beim nächsten Start verschwindet, wird von jemandem mit weniger Kontext erneut diagnostiziert. Machen Sie die Änderung dauerhaft, so wie Ihr System es ohnehin tut, und starten Sie dann einmal absichtlich neu.