Wie man Split-Tunnel-Routen behebt, die ein Heim-NAS-Subnetz verbergen

Eva Wong ist die Technische Redakteurin und und leidenschaftliche Tüftlerin bei ZimaSpace. Eine lebenslange Geek mit einer Leidenschaft für Homelabs und Open-Source-Software, sie spezialisiert sich darauf, komplexe technische Konzepte in zugängliche, praktische Anleitungenzu übersetzen. Eva ist der Meinung, dass Self-Hosting Spaß machen und nicht einschüchternd sein sollte. Durch ihre Tutorials befähigt sie die Community, Hardware-Setups zu entmystifizieren, vom Bau ihres ersten NAS bis hin zur Beherrschung von Docker-Containern.

Stellen Sie das fehlende NAS-Subnetz wieder her, indem Sie die spezifischste bidirektionale Route hinzufügen und dabei die funktionierenden Split-Tunnel-Pfade unverändert lassen.

In einem Heim-VPN kann ein NAS-Netzwerk verschwinden, obwohl der Tunnel verbunden ist und andere private Subnetze erreichbar bleiben. Die übliche Ursache ist nicht der NAS-Dienst selbst, sondern eine fehlende Route, eine breitere lokale Route, die gewinnt, ein sich überschneidendes Heimnetzwerk-Präfix, ein falsches Tunnel-Gateway oder ein Rückweg, der nicht weiß, wie er den VPN-Client erreichen soll. Die sicherste Lösung besteht darin, ein funktionierendes Subnetz mit dem versteckten Subnetz zu vergleichen, eine Routenentscheidung nach der anderen zu korrigieren und sowohl den Vorwärts- als auch den Rückverkehr zu überprüfen, bevor der Tunnel erweitert wird.

Beweisen Sie, dass nur ein NAS-Subnetz fehlt

Verbinden Sie das VPN und testen Sie drei Ziele separat: das VPN-Gateway, ein bekannt funktionierendes privates Subnetz und das NAS-Subnetz, das nicht funktioniert. Verwenden Sie zuerst direkte IP-Adressen, damit DNS, SMB-Erkennung und Hostnamen das Routing-Ergebnis nicht verfälschen.

Split-Tunneling sendet nur ausgewählte Zielpräfixe durch das VPN, während anderer Verkehr der normalen Standardroute des Clients folgt. Eine praktische Erklärung zu subnetz-spezifischen Split-Routen zeigt, dass ein Client das VPN-Netzwerk selbst als erreichbar behandeln kann, während er ein benachbartes privates Subnetz an das falsche Gateway sendet.

Wenn das VPN-Gateway und ein anderes entferntes Subnetz funktionieren, sind Tunnel und Authentifizierung bereits hergestellt. Konzentrieren Sie die Diagnose auf das fehlende NAS-Präfix, die Routenpräferenz, die Firewall-Richtlinie und den Rückweg, anstatt die gesamte VPN-Konfiguration neu aufzubauen.

Vergleichen Sie die gewählte Route für eine funktionierende und eine fehlerhafte Adresse

Untersuchen Sie die Client-Routing-Tabelle, nachdem der Tunnel verbunden ist, und fragen Sie die ausgewählte Route für eine funktionierende Remote-Adresse und eine NAS-Adresse ab. Notieren Sie das Zielpräfix, die Präfixlänge, die Metrik, die Schnittstelle und den nächsten Hop für jede Route.

Eine vorhandene Route ist nicht automatisch die Route, die gewinnt. Betriebssysteme bevorzugen normalerweise das längste passende Präfix, sodass eine lokale 192.168.1.0/24-Route eine breitere VPN-Route wie 192.168.0.0/16 für genau die überlappenden Adressen überschreiben kann.

Wenn die NAS-Adresse dem lokalen Wi-Fi- oder Ethernet-Gateway folgt, fügen Sie eine spezifischere VPN-Route für das NAS-Subnetz hinzu oder bewerben Sie diese. Wenn sie bereits dem Tunnel folgt, fahren Sie mit VPN-Richtlinie, Remote-Weiterleitung und Rückrouting fort, anstatt doppelte Client-Routen hinzuzufügen.

Entfernen Sie Überschneidungen zwischen dem Client-Netzwerk und dem NAS-Netzwerk

Vergleichen Sie das private Subnetz, das vom aktuellen Standort des entfernten Clients verwendet wird, mit dem privaten Subnetz hinter dem Heim-VPN. Hotels, Büros, mobile Hotspots und andere Haushalte verwenden häufig gängige Bereiche wie 192.168.0.0/24 oder 192.168.1.0/24.

Eine aktuelle GlobalProtect-Diskussion beschreibt, wie eine breite Split-Route mit dem lokalen privaten Netzwerk des Clients in Konflikt geraten kann. Der Client könnte glauben, die NAS-Adresse befinde sich in seinem nahegelegenen Wi-Fi und würde das Paket nie ins VPN senden.

Die sauberste langfristige Lösung ist, das Heim-NAS-VLAN oder das entfernte LAN auf ein weniger gebräuchliches Präfix umzubenennen. Wenn eine Umbenennung nicht möglich ist, verwenden Sie ein übersetztes VPN-Subnetz, host-spezifische Routen, einen Anwendungsproxy oder ein VPN-Design, das die Überschneidung bewusst auflöst, anstatt sich auf mehrdeutige private Adressen zu verlassen.

Korrigieren Sie das Split-Tunnel-Präfix und das Gateway

Überprüfen Sie die serverseitige Liste der eingeschlossenen Routen oder erlaubten Subnetze und bestätigen Sie, dass sie das genaue NAS-Netzwerk mit der korrekten Maske enthält. Ein Tippfehler wie /25 statt /24 kann dazu führen, dass nur die Hälfte der vorgesehenen Adressen sichtbar ist.

Ein Cisco-VPN-Fall fand Split-Routen, die mit dem falschen Routengateway installiert wurden, obwohl der VPN-Adresspool selbst korrekt aussah. Deshalb ist die tatsächlich vom Client verwendete Route wichtiger als die konfigurierte Routenbezeichnung.

Entfernen Sie veraltete oder doppelte Routen, verbinden Sie das VPN neu und vergewissern Sie sich, dass eine autoritative Route für das NAS-Präfix erscheint. Fügen Sie keine Standardroute durch den Tunnel hinzu, es sei denn, Full-Tunneling ist das beabsichtigte Design; die Behebung eines Subnetzes sollte nicht stillschweigend den gesamten Internetverkehr umleiten.

Überprüfen Sie Weiterleitung, Firewall und den Rückweg

Erfassen oder protokollieren Sie den Verkehr am VPN-Gateway, während der Client die NAS-Adresse anpingt. Wenn das Paket in den Tunnel eintritt, aber nie zum NAS-VLAN weitergeleitet wird, prüfen Sie die IP-Weiterleitung, Firewall-Regeln zwischen den Schnittstellen und die Route vom VPN-Gateway zu diesem Subnetz.

Ein Leitfaden zur Split-Tunnel-Implementierung betont, dass die Routeninstallation mit passender Weiterleitungs- und Firewall-Richtlinie einhergehen muss. Eine Client-seitige Route allein kann das VPN-Gateway nicht dazu bringen, Verkehr in ein anderes VLAN weiterzuleiten.

Bestätigen Sie anschließend, dass der Router des NAS-Subnetzes eine Route zurück zum VPN-Client-Pool hat. Wenn Antworten stattdessen das normale Internet-Gateway verwenden, fügen Sie die Rückroute hinzu oder wenden Sie sorgfältig begrenztes Source NAT am VPN-Gateway an. Eine erfolgreiche einseitige Erfassung ohne Antworten ist ein Rückwegfehler und kein Grund, die Client-Route weiter zu ändern.

Testen Sie den NAS-Dienst erneut, ohne andere Pfade zu unterbrechen

Nachdem die IP-Erreichbarkeit funktioniert, testen Sie den tatsächlichen NAS-Dienst zuerst per IP und dann per Hostname. Bestätigen Sie SMB, das Web-Dashboard oder den erforderlichen App-Port, ohne davon auszugehen, dass ein erfolgreicher Ping den Anwendungsweg beweist.

Der ZimaSpace-Leitfaden zu einem fehlenden VPN-zu-LAN-Pfad vermittelt die angrenzende Lektion, dass Tunnelverbindung nicht garantiert, dass jeder LAN-Verkehrstyp denselben Pfad folgt.

Beenden Sie, indem Sie das reparierte NAS-Subnetz, ein zuvor funktionierendes entferntes Subnetz und den normalen Internetzugang testen. Behalten Sie die Änderung nur bei, wenn alle drei wie vorgesehen funktionieren, die Route eine erneute Verbindung übersteht und der Client nach jeder Netzwerkänderung keinen manuellen Befehl benötigt.

Support & Tipps

Mehr zum Lesen

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.