OpenVPN-Client erreicht den Server, aber nicht die LAN-Hosts: Checkliste

Der Client meldet verbunden, die Tunneladresse antwortet auf einen Ping, und nichts im Büro-LAN reagiert. Ich sehe das nach fast jedem Client-Upgrade, und der erste Instinkt ist, die Firewall zu öffnen, was meist der falsche Schritt ist: Der Tunnel ist in Ordnung, und der Bruch liegt auf einem von drei Hops, die das Paket passieren muss. Gehen Sie den Weg in der Reihenfolge, in der das Paket ihn nimmt, zuerst die Client-Route, dann das Weiterleiten auf dem Server, dann die Rückreise, und Sie finden den Verursacher in ein paar Minuten.

Schritt eins: die Routing-Entscheidung des Clients beobachten

Bevor Sie den Server anfassen, beweisen Sie, dass der Client das Paket in den Tunnel schickt. Fragen Sie den Kernel, welche Schnittstelle er für einen bestimmten LAN-Host verwenden würde, statt die ganze Tabelle zu lesen:

ip route get 192.168.50.10

Wenn die Antwort Ihren physischen Adapter und das Büro-Gateway nennt, kann keine Änderung auf der Serverseite helfen. OpenVPN verteilt Routen nur, wenn der Server sie schiebt, also suchen Sie push "route 192.168.50.0 255.255.255.0" in der Serverkonfiguration und verbinden Sie den Client danach neu. Die meisten Clients übernehmen geschobene Routen beim Verbinden, nicht beim Neuladen des Profils.

Unter Windows hat dieselbe Frage einen anderen Befehl. Find-NetRoute -RemoteIPAddress 192.168.50.10 gibt die Schnittstelle und den nächsten Hop aus, den der Stack wählen würde, und route print -4 zeigt, ob das geschobene Präfix überhaupt existiert.

Schritt zwei: bestätigen, dass der Server das Paket weiterleitet

Wenn die Client-Route stimmt, erreicht das Paket den Server, und der Server muss zustimmen, es weiterzuleiten. Der Kernel-Schalter ist die erste Hürde, und sysctl net.ipv4.ip_forward muss 1 zurückgeben. Das Setzen mit echo 1 > /proc/sys/net/ipv4/ip_forward hält bis zum nächsten Neustart, und genau deshalb kommt dieselbe Beschwerde Wochen später zurück.

Schreiben Sie es an einen Ort, der einen Neustart überlebt:

echo 'net.ipv4.ip_forward = 1' > /etc/sysctl.d/99-openvpn-forward.conf
sysctl --system

Die zweite Hürde ist die Filtertabelle. Ein Host mit installiertem Docker trägt oft eine FORWARD-Richtlinie von DROP, und der Tunnel erbt diese Entscheidung. iptables -L FORWARD -v -n zeigt sowohl die Richtlinie als auch die Paketzähler; ist die Richtlinie DROP, braucht das Weiterleiten eine ausdrückliche Freigabe für die Richtung Tunnel zu LAN und eine für die Antwort.

Schritt drei: das Paket ins LAN verfolgen und die Antwort suchen

Beobachten Sie beide Seiten des Servers gleichzeitig. Zeichnen Sie am Tunnel und an der LAN-Schnittstelle auf, gefiltert auf einen Client und einen Host, damit die Ausgabe lesbar bleibt:

tcpdump -ni tun0 host 192.168.50.10
tcpdump -ni eth0 host 192.168.50.10

Anfragen, die auf tun0 und erneut auf eth0 mit einer Quelle 10.8.0.x auftauchen, gefolgt von Stille, bedeuten: Das Paket kam an, und die Antwort ging woanders hin. Der LAN-Host antwortet seinem Standardgateway, dieses Gateway hat keine Route für den VPN-Pool, und die Antwort stirbt am LAN-Router. Den LAN-Host vom Server aus anzupingen beweist nichts über diesen Weg, weil dieser Verkehr den Tunnel nie überquert.

Schritt vier: zwischen Übersetzung und Rückroute wählen

Zwei Reparaturen schließen die Lücke, und die Wahl hat Folgen über die Frage hinaus, ob Ping funktioniert. Quellübersetzung macht den Server zum scheinbaren Absender:

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

Beschränken Sie die Regel auf den Pool und die LAN-Schnittstelle, dann machen Sie sie dauerhaft, sonst entfernt das nächste Neuladen der Firewall Ihren Fix still. Der Preis ist Identität: Jeder Client erscheint in LAN-Logs und Zugriffsregeln wie der VPN-Server, und per-client policy becomes guesswork.

Eine statische Route für 10.8.0.0/24 auf dem LAN-Router, die auf den VPN-Server zeigt, hält Client-Adressen sichtbar und ist die bessere langfristige Antwort, wenn dieser Router Ihrer ist. Viele Standorte fahren eine Weile beides, NAT für die sofortige Reparatur und die Route, sobald die Firewall-Richtlinie geschrieben ist. Ist der Server ein Site-to-Site-Peer statt eines Pools, braucht die Serverseite zusätzlich ein iroute für das entfernte Subnetz, sonst existiert die Peer-Route, aber Client-Verkehr wird nie damit verknüpft.

Schritt fünf: vom Client prüfen und festhalten, was sich geändert hat

Schließen Sie die Schleife vom Client aus, nicht vom Server. Verbinden Sie sich mit einem echten Dienst auf dem LAN-Host und bestätigen Sie dann, dass sich die Übersetzungszähler mit iptables -t nat -L POSTROUTING -v -n bewegt haben, denn eine Regel ohne Pakete ist eine Regel, die nie gepasst hat. conntrack -L -s 10.8.0.5 zeigt den Fluss und seinen Zustand, wenn Sie einen Beweis brauchen, dass die Rückrichtung verfolgt wird.

Hinterlassen Sie eine Notiz in der Serverkonfiguration: welches Subnetz, welche Schnittstelle, welche Regel und ob der LAN-Router eine Route zurück trägt. Wenn ein Client-Upgrade das nächste Mal eine geschobene Route löscht, verwandelt diese Notiz eine Feuerwehr-Sitzung in einen Einzeiler.