Mit OpenVPN verbunden, aber kein Ping und keine SMB-Freigabe? Drei Tore prüfen

Der Tunnel steht, der Client bekommt eine Adresse, und im entfernten LAN antwortet nichts. Ping schlägt fehl, die Freigabe öffnet sich nicht, und das VPN-Protokoll sieht sauber aus, weil die Sitzung aus seiner Sicht gesund ist. Zwischen dieser Sitzung und einer Datei auf einem Server liegen drei unabhängige Tore: die Weiterleitungsrichtlinie, die Ports, die der Dienst braucht, und der Name, den du statt einer Adresse eingetippt hast.

Jedes Tor scheitert mit einem anderen Symptom, und nur das erste liegt auf dem VPN-Server.

Weiterleitung ist eine Richtlinie auf der FORWARD-Kette

Das Annehmen des OpenVPN-Listeners geschieht in INPUT, deshalb kann sich der Tunnel verbinden, während jedes Paket in Richtung LAN verworfen wird. Datenverkehr, der auf tun0 eintrifft und über die LAN-Schnittstelle hinausgeht, durchläuft FORWARD, und ein Host mit Standard-DROP-Richtlinie dort verwirft ihn stillschweigend. Prüfe sowohl das sysctl als auch die Kette, bevor du etwas anderes anfasst: sysctl net.ipv4.ip_forward und iptables -L FORWARD -v -n.

Erlaube die Richtung, die du willst, und die Antworten, die dazugehören, zum Beispiel eine accept-Regel von der Tunnel-Schnittstelle zur LAN-Schnittstelle plus eine stateful-Regel für established- und related-Verkehr. Steht das LAN hinter einem weiteren Router, braucht dieser Router eine Route zurück zum Client-Pool oder ein source NAT auf dem VPN-Server. Bestätige diesen Pfad mit einem einzigen Ping, bevor du weitere Regeln hinzufügst, denn eine Regel, die nicht erreichbar ist, taucht nie in einem Zähler auf.

SMB braucht mehr als einen Port

Dateifreigabe ist kein einzelnes TCP-445-Gespräch. Die Erkennung nutzt UDP 137 und 138, ältere NetBIOS-Sitzungen nutzen TCP 139, und moderne SMB-Sitzungen nutzen TCP 445. Eine Regel, die nur 445 öffnet, erzeugt den verzweifelten Fall, dass ein zugeordnetes Laufwerk funktioniert und das Durchsuchen des Netzwerks nicht, oder umgekehrt.

Große Übertragungen über einen Tunnel treffen auch auf MSS-Probleme, die wie eine kaputte Freigabe aussehen. Ein SYN, das die volle Segmentgröße des LANs ankündigt, wird von der kleineren MTU des Tunnels verworfen, und die Verbindung hängt nach dem Handshake. MSS-Clamping auf dem Weiterleitungspfad, iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu, beseitigt diese Art von Stillstand. Prüfe es mit einer Kopie von ein paar Megabyte statt mit einer Verzeichnisauflistung, denn kleine Antworten kommen durch, auch wenn große Übertragungen es nicht tun.

Der Tunneladapter kommt als neues Netzwerkprofil

Windows ordnet jeden Adapter einem Netzwerkprofil zu, und ein frischer Tunneladapter landet meist in Public, wo die Regeln für Datei- und Druckerfreigabe blockiert sind. Das ist eine Entscheidung der Host-Firewall auf dem Dateiserver, kein Routingproblem auf dem VPN-Server. Ändere die Kategorie bewusst mit Set-NetConnectionProfile -InterfaceAlias "Ethernet 3" -NetworkCategory Private, nachdem du bestätigt hast, dass die Richtlinie es erlaubt, denn die Kategorie ändert auch, welche eingehenden Regeln gelten.

Dasselbe Profil erklärt einen Ping, der scheitert, während TCP 445 gelingt: Echo-Anfragen werden in Public standardmäßig verworfen.

Namen überqueren einen gerouteten Tunnel nicht von selbst

NetBIOS-Namensauflösung und lokale Erkennung beruhen auf Broadcasts, die ein gerouteter Tunnel nicht transportiert. Das Eintippen des Kurznamens des Servers scheitert daher, während seine Adresse funktioniert, und die Freigabe sieht kaputt aus, obwohl nur die Auflösung kaputt ist. Füge einen DNS-Eintrag für den Server beim Resolver hinzu, den der Tunnel ausgibt, oder verwende die Adresse in der Verknüpfung.

Wenn die Bereitstellung noch von WINS abhängt, konfiguriere es auf dem Client, statt auf Broadcast-Verkehr zu hoffen. Teste zuerst über die Adresse, damit ein Namensfehler nicht mit einem Firewallfehler verwechselt wird.

Teste eine Schicht nach der anderen und lies den ersten Fehler

Arbeite dich nach oben: Pinge das Tunnel-Gateway, pinge einen LAN-Host über die Adresse, öffne dann den Dienstport mit Test-NetConnection -ComputerName 10.8.0.5 -Port 445, und erst dann authentifiziere dich an der Freigabe. Der erste Schritt, der scheitert, ist die Schicht, die zu reparieren ist, und jeder spätere Schritt ist Rauschen, bis er durchgeht. Ein Ping, der antwortet, während der Port geschlossen bleibt, deutet auf die eigene Firewall des Dateiservers hin, während ein Port, der sich trotz stummer Pings öffnet, auf ICMP-Filterung hindeutet. Schreibe den ersten fehlschlagenden Schritt auf, bevor du etwas änderst, denn eine zweite Änderung verdeckt das Ergebnis der ersten.

Wenn der VPN-Server nicht der Router des LANs ist, bestätige die Rückroute auf diesem Router bevor du dem Server weitere Regeln hinzufügst. Ohne sie erreichen Anfragen den Host, und Antworten verlassen ihn über die Standardroute Richtung Internet, was von Clientseite genau wie ein Firewall-Drop aussieht.

Halte das Freigabekonto in deinen Notizen getrennt vom VPN-Login, denn ein erfolgreicher Tunnel sagt nichts über Dateiberechtigungen aus. SMB ins Internet zu exponieren, um eine fehlende Regel zu umgehen, ist keine Lösung.