Warum Ihr LAN einen Dienst auf einem VPN-Client nicht erreicht

Ein VPN-Client kann einen Dienst hosten, den das LAN nicht öffnen kann. Was meist fehlt, ist der Rückweg: eine Route, ein DNAT-Paar oder die SNAT-Zeile, die niemand hinzufügt.

Der Tunnel steht, der Dienst lauscht, und das Büro-LAN bekommt trotzdem nichts zurück. Niemand hat das VPN kaputt gemacht. Aus Sicht des LAN existiert die Tunneladresse des Laptops nicht, bis etwas dem LAN sagt, wie es sie erreicht, und die Antwort muss denselben Weg zurückkommen, den die Anfrage genommen hat. Ich habe erlebt, wie Leute einen völlig intakten Tunnel dreimal neu gebaut haben, bevor jemand den Rückweg ansah.

Nicht der Tunnel ist kaputt

Beide Enden liegen in privaten Bereichen, was der Normalfall und keine Fehlkonfiguration ist. Eine Adresse wie 10.8.0.6 ist innerhalb des Tunnels real und sonst nirgends vorhanden, also hat das LAN keinen Grund, dorthin etwas zu senden. Bevor Sie das Routing anfassen, bestätigen Sie, dass der Dienst überhaupt innerhalb des Tunnels erreichbar ist: Auf dem Client zeigt ss -ltn, ob der Listener an 127.0.0.1, an die LAN-Schnittstelle oder an die Tunneladresse bindet. Ein Daemon, der nur an Loopback bindet, antwortet niemandem außer sich selbst, und keine Route, kein DNAT und keine Portweiterleitung ändert das.

Ein Proxy auf Port 80 oder 443 ist ein anderes Werkzeug mit anderer Sichtbarkeit. Er bewegt Anfragen, keine Pakete, ist also die falsche Schicht für eine rohe Datenbankverbindung, und genau der Griff danach führt dazu, dass dieses Problem drei Werkzeuge tief endet, bevor irgendjemand etwas misst.

Routenform: Sagen Sie dem LAN, wo der Pool liegt

Eine statische Route auf dem LAN-Gateway ist die sauberste Antwort, wenn LAN und Tunnel-Pool sich nicht überlappen. Richten Sie den Pool auf die Maschine, die den Tunnel beendet:

ip route add 10.8.0.0/24 via 192.168.1.12
route add -p 10.8.0.0 mask 255.255.255.0 192.168.1.12   # Windows, persistent

Das behebt nur eine Richtung, deshalb sehen halbfertige Versionen dieser Änderung wie Fortschritt aus. Die Tunnelseite braucht die passende Hälfte, sonst verlässt die Antwort den Client über seine eigene Standardroute und stirbt unterwegs:

push "route 192.168.1.0 255.255.255.0"

Für ein Subnetz, das hinter einem Client statt hinter dem Server liegt, braucht der Server sowohl eine Systemroute als auch einen iroute-Eintrag in der Datei dieses Clients unter client-config-dir. Ohne iroute weiß OpenVPN, dass das Präfix existiert, und hat keine Ahnung, welcher Client es besitzt: Pakete kommen an, und der Daemon hat nichts, womit er sie abgleichen könnte.

Hier ist der Mythos, der einen Namen verdient. Eine Route macht eine Adresse erreichbar; sie macht die Gegenseite nicht willens zu antworten. Site-to-Site-Peers legen eine weitere Schicht darüber, denn das entfernte Gateway akzeptiert nur Quellen innerhalb der Präfixe seiner Richtlinie, und ein Laptop, der aus einem Heim-Pool kommt, liegt nicht darin.

NAT-Form: DNAT hinein und die SNAT-Zeile, die alle überspringen

Wenn Sie das LAN-Gateway nicht anfassen können oder genau einen Port veröffentlichen wollen, funktioniert Übersetzung auf dem VPN-Host ohne jede Route im LAN. Veröffentlichen Sie den Port, leiten Sie ihn weiter und übersetzen Sie die Quelle auf dem Weg in den Tunnel:

iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 -j DNAT --to-destination 10.8.0.6:3000
iptables -A FORWARD -i eth0 -o tun0 -p tcp -d 10.8.0.6 --dport 3000 -j ACCEPT
iptables -t nat -A POSTROUTING -o tun0 -d 10.8.0.6 -p tcp --dport 3000 -j SNAT --to-source 10.8.0.1

Die dritte Zeile ist die, die fehlt. Lassen Sie sie weg, sieht der Client die ursprüngliche LAN-Adresse als Quelle, antwortet über seine eigene Standardroute, und diese Antwort geht in den Tunnel statt zurück zum LAN. Ob die Verbindung überlebt, hängt dann von Routing ab, das Sie nie geplant haben. Mit SNAT sieht der Client die Tunneladresse des Servers, sodass die Antwort dem Tunnel zurück zu dem einzigen Host folgt, der die Übersetzung rückgängig machen kann.

Consumer-Firmware verwendet eigene Kettennamen und erzeugt diese Übersetzung nicht für Sie. Bei Tomato landet eine Inbound-Regel in WANPREROUTING und dann in einer Filterkette wie wanin, und ein Regelsatz, der vollständig aussieht, braucht trotzdem eine manuelle POSTROUTING-Zeile. Das ist kein Firmware-Fehler; es ist ein Regelsatz, der nur für eingehenden Verkehr geschrieben wurde.

Warum eine korrekt aussehende Regel das Paket trotzdem verwirft

Die meisten dieser Fehler stecken nicht in der Regel, die Sie anstarren. Prüfen Sie vier Dinge in dieser Reihenfolge und stoppen Sie beim ersten, das nicht gilt:

  • Kettenreihenfolge. iptables -I fügt oben ein und -A hängt unten an, also entscheidet eine frühere erlaubende oder blockierende Regel zuerst.
  • Falsche Kette. Verkehr an den Router selbst durchläuft INPUT, weitergeleiteter Verkehr berührt sie nie. Das Veröffentlichen eines Dienstes kann Regeln in beiden erfordern.
  • Richtungsflags. -i tun0 trifft Verkehr, der von Clients ankommt, und -o tun0 Verkehr, der zu ihnen hinausgeht. Ein REJECT mit dem falschen Flag blockiert etwas, das Sie nicht beabsichtigt haben.
  • Quellenbeschränkung. Eine Weiterleitung, die eine Client-Adresse akzeptiert, wirkt von diesem Client und verwirft jede andere Quelle ohne ein Wort.

Eine Regel mit einem Paketzähler von null ist überhaupt nicht im Pfad, und die Zähler zu lesen ist der schnellste Weg, ein Falsche-Kette-Problem von einem Falsche-Regel-Problem zu trennen.

Die lokale Weiterleitung, wenn sich im LAN nichts ändern lässt

Eine lokale SSH-Weiterleitung umgeht die ganze Frage. Sie braucht keine Route im LAN, keine Mithilfe der Client-Firewall und keinen irgendwo veröffentlichten Port:

ssh -N -f -L 3000:10.8.0.6:3000 user@vpn-host

Der Dienst erscheint dann auf localhost:3000 der Maschine, die den Tunnel betreibt, und nirgends sonst. Das ist die Grenze: eine Workstation, ein Port, und die Weiterleitung stirbt mit der Sitzung, falls nichts sie neu startet. Für einen Administrator, der eine Staging-Datenbank prüft, ist es das richtige Werkzeug. Für eine Kamera oder einen Scanner, die andere Leute erreichen müssen, nicht, weil jeder Nutzer seine eigene Weiterleitung bräuchte.

Prüfen Sie beide Richtungen, bevor Sie eine weitere Regel hinzufügen

Übersetzung hinterlässt Spuren, und sie zu lesen schlägt Raten. Auf dem VPN-Host zeigt conntrack -L, ob die Übersetzung überhaupt stattfand, iptables -t nat -L -n -v zeigt, ob sich die Zähler bewegten, und tcpdump -ni any port 3000 zeigt, welche Quelladresse tatsächlich ankam. Auf dem Client bestätigt ss -ltn, dass der Listener auf einer Adresse ist, die der Tunnel erreicht.

Wählen Sie dann die Form, die Sie behalten. Ein veröffentlichter Port, eine Route für den ganzen Pool und eine Weiterleitung für einen einzigen Administrator sind drei verschiedene Festlegungen, und sie zu mischen ist der Weg, wie aus einem funktionierenden Aufbau einer wird, den sechs Monate später niemand erklären kann. Schreiben Sie auf, welche Adresse von wo erreichbar ist, und die nächste Person, die das debuggt, beginnt bei der Antwort statt beim Tunnel.

Ähnliche Artikel