Kein LAN-Zugriff über OpenVPN? Zonen, Routen und Rückweg prüfen

Der Tunnel meldet eine erfolgreiche Verbindung, die eigene Seite des Routers lädt, und die Netzlaufwerkzuordnung zu einem Rechner dahinter läuft trotzdem in eine Zeitüberschreitung. Nichts an dieser Kombination ist widersprüchlich: Der Router antwortet als er selbst, und alles dahinter zu erreichen ist eine andere Entscheidung an einer anderen Stelle. Arbeiten Sie die Prüfungen unten der Reihe nach ab und halten Sie beim ersten Fehlschlag an, denn jede stützt sich auf die vorige. Wenn alle vier bestehen, sitzt der Fehler über dem Tunnel und nicht in ihm.

Welcher Filter sieht ein Paket zum LAN

Ein an den Router adressiertes Paket wird lokal verbraucht; ein an einen Host dahinter adressiertes Paket muss weitergeleitet werden, und Firewalls beurteilen diese beiden Fälle getrennt. Die Erlaubnis, den Router zu erreichen, sagt also nichts über die Erlaubnis, ihn zu durchqueren. Firmware, die ihre Regelsätze verbirgt, setzt trotzdem beides um, meist als Auswahl, die LAN, Internet oder beides anbietet. Fehlt das LAN in der Auswahl, hilft keine spätere Prüfung.

OpenWrt macht die Trennung prüfbar, und der Unterschied lohnt eine Lektüre. Die Zone, die den Tunnel beendet, braucht eine Weiterleitungsregel auf die LAN-Zone, während eine Eingangsregel nur Dienste auf dem Router selbst regelt. Eine funktionierende Verwaltungsseite neben einem toten LAN ist das übliche Ergebnis dieser fehlenden Weiterleitungsregel.

uci show firewall | grep -E "zone\[[0-9]+\]\.(name|input|forward|output)"

Sehen Sie sich das Weiterleitungsziel der Zone an, die den Tunnel trägt: accept ist das, was die Leiter braucht, und reject erklärt jede Zeitüberschreitung darunter. Zwei benachbarte Einstellungen erzeugen dasselbe Symptom, schließen Sie sie also aus, solange Sie hier sind. Drahtlosisolierung verbirgt kabelgebundene Hosts vor drahtlosen Clients, und ein Router, der inaktive LAN-Hosts als offline behandelt, kann die Antworten verwerfen, selbst wenn die Weiterleitung funktioniert.

Warum ein gespaltener Tunnel das gepushte Präfix braucht

Ein Client, der allen Verkehr durch den Tunnel schickt, hält das LAN-Präfix bereits über seine Standardroute, es ist also nichts hinzuzufügen. Der gespaltene Tunnel ist der Fall, der das Präfix ausdrücklich verlangt, weil sonst nichts in der Konfiguration es erwähnt. Fügen Sie die Anweisung der Serverkonfiguration hinzu und laden Sie den Dienst neu.

push "route 192.168.50.0 255.255.255.0"

Profile mit route-nopull ignorieren gepushte Routen, also gehört dasselbe Präfix stattdessen in die Clientdatei. Bestätigen Sie in jedem Fall, dass der Eintrag angekommen ist, statt es anzunehmen, denn eine stille Überschreibung sieht genauso aus wie ein Firewallproblem.

ip route show | grep 192.168.50

Ein Standort-zu-Standort-Partner verlangt mehr als einen Push. Der Server muss lernen, welche Präfixe hinter diesem Partner liegen, was eine iroute-Zeile in seiner client-config-dir-Datei erledigt, und seine eigene Tabelle braucht eine passende Route in den Tunnel.

Die Antwort braucht eine Adresse, die sie erreichen kann

Die Anforderung weiterzuleiten ist nur die Hälfte eines Austauschs, denn der LAN-Host muss auf eine Adresse aus dem Tunnelpool antworten. Kleine Router regeln das meist durch Übersetzung der Quelle auf der Tunnelzone, sodass die Antwort an den Router adressiert ist und anderswo keine Konfiguration braucht. Entfernen Sie diese Übersetzung, und der Host braucht seine eigene Route in den Pool, die er kostenlos bekommt, wenn der Router sein Standardgateway ist. Ein Host mit fest gesetzter Adresse und einem anderen Gateway antwortet stattdessen über dieses Gateway, und der Client sieht eine Sitzung aufgehen und dann stocken.

tcpdump -ni tun0 host 192.168.50.20

Führen Sie das auf dem Router aus, während der Client seine Anforderung wiederholt, und lesen Sie das Ziel der Antwort statt die Anforderung selbst. Eine Antwort an den Pool bedeutet, dass der Rückweg funktioniert und der Fehler weiter innen liegt. Gar keine Antwort bedeutet, dass der Host das Paket nie angenommen hat, was Sie zurück zum Regelsatz schickt.

Eine Leiter, die an der richtigen Stelle endet

Vier Prüfungen lokalisieren die Ebene, und jede ist ein einzelner Befehl statt einer Einschätzung. Führen Sie sie der Reihe nach aus und halten Sie beim ersten Fehlschlag an. Die Reihenfolge ist wichtiger als die Befehle, denn ein bestandener späterer Schritt verbirgt den Grund, warum ein früherer scheiterte.

ping -c1 10.8.0.1
ping -c1 192.168.50.20
nc -vz 192.168.50.20 445
getent hosts nas.local

Namen gehören ans Ende der Leiter, nie an den Anfang. Eine Freigabe, die als 192.168.50.20 aber nicht als nas.local antwortet, deutet auf Namensauflösung oder ein Suchsuffix hin, und Firewall-Änderungen können keines von beiden beheben.

Notieren Sie den ersten fehlgeschlagenen Schritt und geben Sie den Dienstports dann einen eigenen Durchgang, denn ein Listener und eine Host-Erlaubnis sind getrennte Voraussetzungen. Dateifreigabe, Remotedesktop und Kamerastreams brauchen beides, und eine Host-Firewall, die dem LAN-Subnetz aber nicht dem Tunnelpool vertraut, verwirft den Client, während ping noch gelingt. Wenn alle Prüfungen bestehen und die Anwendung trotzdem scheitert, sitzt der Fehler über dem Tunnel: ein Dienst, der an eine Schnittstelle gebunden ist, oder ein Proxy, der auf dem Client konfiguriert ist.