NAS über das VPN nicht erreichbar: Adresse, Rückweg oder Dienst?

Tunnel kommen hoch, Clients erhalten eine Adresse, und das NAS antwortet überhaupt nicht. Dieses eine Symptom deckt drei unabhängige Fehler ab, und die Reihenfolge, in der Sie sie prüfen, entscheidet darüber, wie lange die Reparatur dauert. Die Adressierung kommt zuerst, weil ein überlappendes Subnetz Ihre Anfrage an ein fremdes Gerät schicken kann. Der Rückweg kommt an zweiter Stelle, weil eine Anfrage, die ohne Antwort ankommt, genauso aussieht wie ein geschlossener Dienst. Dienst und Berechtigung kommen zuletzt, und erst nachdem die ersten beiden Punkte bewiesen sind.

Drei Fehler, die alle als nicht erreichbar gelesen werden

Adressauswahl, Rückweiterleitung und Dienstautorisierung erzeugen dieselbe sichtbare Meldung: Es passiert nichts. Sie haben unterschiedliche Beweise, unterschiedliche Zuständige und unterschiedliche Korrekturen, deshalb ist ihre Trennung die eigentliche Aufgabe. Ein fehlschlagender Ping beweist für sich genommen wenig, und eine erfolgreiche TCP-Ablehnung ist tatsächlich eine gute Nachricht.

Lesen Sie die Tabelle als Reihenfolge der Tests und nicht als Liste der Ursachen. Jede Zeile schränkt die nächste ein, denn eine Ablehnung beweist bereits, dass Adressierung und Rückweg funktionieren. Zwanzig Minuten in Firewall-Regeln zu verbringen, bevor man prüft, welche Schnittstelle die Route gewählt hat, ist der häufigste Weg, einen Nachmittag zu verlieren. Arbeiten Sie von oben nach unten und halten Sie bei der ersten passenden Zeile an.

Bedingung eins: Ist diese Adresse das richtige Gerät?

Schreiben Sie das NAS-Subnetz und den Bereich auf, den das VPN an Clients vergibt, und vergleichen Sie beides mit dem Netzwerk, in dem Ihr Laptop gerade ist. In diesem Durchlauf steht das NAS auf 10.40.7.25 und der VPN-Pool ist 10.40.9.0/24, zwei getrennte private Bereiche innerhalb eines Standortplans; ein Haushalt, der 192.168.0.0/24 oder 10.0.0.0/24 verwendet, hat eine viel höhere Chance, mit einem davon zu kollidieren.

Wenn das lokale Netzwerk und das NAS-Netzwerk überlappen, schickt der Client diesen Datenverkehr an sein eigenes Gateway und kann ein fremdes Gerät erreichen, das zufällig dieselbe Adresse hat. Prüfen Sie den Pfad, bevor Sie Zugangsdaten in irgendetwas eingeben, das antwortet.

ip -4 route get 10.40.7.25
traceroute -n -m 5 10.40.7.25

Der erste Befehl nennt die Schnittstelle und das Gateway, die der Kernel verwenden würde, und der zweite zeigt die ersten Hops, die tatsächlich antworten. Wenn die beiden nicht übereinstimmen, glauben Sie der Abfrage, denn das ist der Pfad, den das Paket nehmen wird. Eine Hop-Liste, die einen Hop vor dem NAS endet, ist ebenfalls ein Befund und kein Fehlschlag. Eine Abfrage, die auf den physischen Adapter statt auf den Tunnel auflöst, beendet die Untersuchung an dieser Stelle.

Bedingung zwei: Kommt die Antwort zurück?

Der Client braucht eine Route zum NAS, und das NAS-Netzwerk braucht einen Rückweg zum VPN-Pool. Gateway-Weiterleitung, Firewall-Regeln und bewusste Übersetzung wirken jeweils auf dieses Paar. strongSwans Hinweise zur Weiterleitung beschreiben die Wahlmöglichkeiten für Rückroute und Übersetzung für ein privates Subnetz hinter einem Gateway.

Wenn die Anfrage ankommt und die Antwort über ein anderes Gateway hinausgeht, repariert keine DNS-Änderung die Asymmetrie. Eine Aufzeichnung auf beiden Seiten klärt das in einem Versuch, und sie zeigt auch, ob die Übersetzung die Quelle umgeschrieben hat, auf die das NAS geantwortet hat. Der Administrator verantwortet diese Grenze: Erlauben Sie nur die benötigten Dienste und den VPN-Client-Bereich, und notieren Sie, ob Routing oder Übersetzung gewählt wurde.

Bedingung drei: Ist der Dienst vorhanden und erlaubt?

Eine Verwaltungsseite und ein Dateifreigabedienst sind verschiedene Endpunkte auf derselben Kiste, und einer kann Verbindungen annehmen, während der andere durch die Host-Firewall, die Dienstkonfiguration oder eine Freigabeberechtigung blockiert wird. Ein Gerät, das mit einer Ablehnung antwortet, hat die ersten beiden Bedingungen bereits bewiesen, was die dritte erheblich einengt.

Testen Sie mit dem Konto, das die Dateien tatsächlich braucht, statt mit dem Administratorkonto aus der Einrichtung, denn Administratorrechte können eine fehlende Route nicht reparieren, und eine Route kann keine Freigabeberechtigung erteilen. Auch Namen gehören hierher: Ein zu Hause entdeckter NAS-Name hängt oft von lokalem Multicast ab, das ein gerouteter Tunnel nicht überträgt, deshalb probieren Sie daher den dokumentierten privaten Hostnamen des Herstellers oder die Adresse selbst, um Namensauflösung von Zugriff zu trennen.

Testen Sie von außerhalb des NAS-Netzwerks und erweitern Sie dann langsam

Ein Test im selben LAN verbirgt jeden unvollständigen Teil des entfernten Pfads, weshalb der erste erfolgreiche entfernte Versuch einen Eintrag im Änderungsprotokoll verdient. Führen Sie die Prüfungen von einem Client aus, der das NAS nur über den Tunnel erreicht, und bewahren Sie den ursprünglichen Fehlertext jedes Versuchs auf.

nc -vz 10.40.7.25 445
smbclient -L 10.40.7.25 -U guest

Sobald der Pfad funktioniert, übertragen Sie eine harmlose Datei und bestätigen Sie das Lese- oder Schreibverhalten, das Sie tatsächlich brauchen. Wenn große Übertragungen stocken, während kleine gelingen, ist das verbleibende Problem die Paketgrößenbehandlung oder die Verbindungsstabilität und nicht die Adressierung.

Veröffentlichen Sie keine Dateifreigabe- oder Verwaltungsports im Internet, um einen unerklärten Fehler zu umgehen. Reparieren Sie den privaten Pfad, halten Sie die NAS-Software unterstützt, und testen Sie die Wiederherstellung alles dessen, was Sie darüber sichern, bevor Sie sich auf diese Sicherung verlassen.