OpenVPN-Handshake auf Synology schlägt fehl? Prüfen Sie die LAN-Weiterleitung

Ihr Laptop meldet, dass der TLS-Handshake fehlgeschlagen ist, also lockt der Reiz, die Zertifikate neu zu bauen. Fragen Sie vorher etwas Langweiligeres: An welchem Ethernet-Port lauscht das Synology tatsächlich? Ein NAS mit zwei LAN-Ports hat zwei Adressen, und das VPN-Server-Paket von DSM bindet seinen OpenVPN-Listener an eine davon. Wenn der Router 1194 an die andere Adresse weiterleitet, erreicht kein Paket jemals den Dienst, und der Client hat nichts, worüber er verhandeln könnte.

Der Fehlertext führt in die Irre, weil er das Letzte beschreibt, was der Client versucht hat, nicht das Erste, was schiefging. Zwei Minuten Vergleich der Paketseite mit der Routerregel klären es.

Finden Sie die Adresse, an die der Listener gebunden ist

DSM nennt seine Ports LAN 1 und LAN 2, und jeder trägt eine eigene Adresse und ein eigenes Subnetz. Öffnen Sie VPN Server, lesen Sie die auf dem OpenVPN-Tab genannte Schnittstelle, öffnen Sie dann die Systemsteuerung und notieren Sie die IPv4-Adresse, die DSM an derselben Schnittstelle hat. Diese beiden Werte, nicht der Hostname des NAS, muss die Weiterleitung benennen.

Ein zweites eingestecktes Kabel schafft keinen zweiten Listener. Beide Verbindungen können als verbunden erscheinen, während nur eine Adresse den Verkehr annimmt, und wenn beide Schnittstellen im selben Subnetz liegen, unterscheiden sich die zwei Adressen um eine Ziffer, die niemand erneut liest, bevor eine Regel gespeichert wird.

Sehen Sie sich den Socket selbst über SSH an, denn das ist der einzige Ort, der zeigt, woran der Daemon wirklich gebunden hat, statt was die Einstellungsseite beabsichtigt.

sudo netstat -anp | grep 1194

Bearbeiten Sie die vorhandene Weiterleitung, statt eine weitere hinzuzufügen

Zwei Regeln für einen externen Port lassen dem Router die freie Wahl, und welche er wählt, kann sich nach einem Firmware-Update oder einem Neustart ändern. Öffnen Sie die bereits vorhandene Regel, ändern Sie ihre interne Adresse, speichern Sie, öffnen Sie sie dann erneut und lesen Sie den Wert zurück. Die Regel nach dem Dienst zu benennen hilft, denn eine Liste aus fünf identischen Weiterleitungen ist der Weg, auf dem die falsche überlebt.

external 1194/udp  ->  192.0.2.20:1194/udp

Halten Sie den internen Port gleich dem Lauschport und halten Sie das Protokoll konsistent. UDP 1194 ist der Standard-Listener, während ein TCP-Profil einen eigenen Listener auf der Paketseite und eine passende Weiterleitung am Router braucht. TCP an einen Dienst weiterzuleiten, der nur auf UDP lauscht, erzeugt Stille, keinen Fehler.

Wenn die NAS-Adresse von DHCP kommt, reservieren Sie sie, bevor die Regel gespeichert wird. Der Ablauf der Lease weist die Adresse neu zu, die Weiterleitung zeigt weiter auf den alten Wert, und der Handshake beginnt an einem Tag zu scheitern, an dem niemand das NAS angefasst hat. Eine statische Konfiguration auf der NAS-Seite löst dasselbe Problem, sofern die Adresse außerhalb des DHCP-Bereichs des Routers liegt.

Beweisen Sie, ob Pakete überhaupt ankommen

Starten Sie zuerst eine Aufzeichnung auf dem NAS, verbinden Sie sich dann vom Client, und lesen Sie die Quelladresse in der Ausgabe. Eine nach dem Fehler gestartete Aufzeichnung zeigt nichts und beweist nichts.

sudo tcpdump -i any -n udp port 1194

Stille bedeutet, dass der Verkehr vor dem Dienst gestorben ist: eine falsche interne Adresse, ein geschlossener Port an der DSM-Firewall oder eine Schnittstelle, die administrativ abgeschaltet ist. Pakete in der Ausgabe bedeuten, dass die Weiterleitung funktioniert, und der restliche Fehler liegt über der Netzwerkschicht, was ein viel kleineres Suchgebiet ist.

Die Aufzeichnung nennt auch die Schnittstelle, auf der das Paket ankam, und dieses eine Detail trennt eine auf den falschen Port gerichtete Regel von einer auf einen Port gerichteten Regel, der nicht aktiv ist. Beobachten Sie während desselben Versuchs den eigenen Zähler des Routers, wenn er einen anzeigt. Ein Zähler, der sich nicht bewegt, während die Aufzeichnung leer bleibt, deutet auf den Router, während ein Zähler, der sich bei leerer Aufzeichnung bewegt, auf den Pfad zwischen den beiden Geräten deutet.

Wenn Pakete ankommen, geben Sie der Weiterleitung nicht mehr die Schuld

Das Profil ist der nächste Verdächtige, und der übliche Grund ist das Alter. Eine exportierte .ovpn-Datei enthält die Autorität und das Material aus dem Moment des Exports, sodass ein Paket, dessen Zertifikat später ersetzt wurde, einen Client ablehnt, der noch die alte Kopie trägt.

Der Transport ist die andere Unstimmigkeit, die man ausdrücklich prüfen sollte, weil Profil und Paket an verschiedenen Stellen bearbeitet werden. Ein Profil von UDP auf TCP umzustellen, ohne das Paket umzuschalten, lässt den Client auf einen Listener warten, der nicht existiert, und der Client meldet denselben allgemeinen Handshake-Text, den er für alles andere meldet. Lesen Sie die proto-Zeile in der Datei, sehen Sie sich dann das auf der Serverseite gewählte Protokoll an, und schließen Sie erst dann, dass sie übereinstimmen. Die DSM-Firewallregeln zu lesen ist die dritte Prüfung: eine Regel, die den Port aus dem lokalen Subnetz, aber nicht aus dem Internet erlaubt, bleibt nach dem Testen leicht zurück, und sie erzeugt eine Verbindung, die aus der Küche funktioniert und von überall sonst scheitert.

Testen Sie den Weg, den ein entfernter Nutzer wirklich nimmt

Ein Client im selben LAN erreicht das NAS, ohne die Weiterleitung je zu berühren, beweist also nichts über den Fernzugriff. Nehmen Sie ein Telefon mit ausgeschaltetem Wi-Fi oder fragen Sie jemanden außerhalb des Netzwerks, und beobachten Sie während dieses Versuchs den Routerzähler. Wenn der entfernte Versuch scheitert, während der lokale gelingt, sind Weiterleitung oder Firewall noch im Spiel.

Notieren Sie den funktionierenden Zustand, solange er funktioniert: externer Port, interne Adresse, Protokoll, Paket-Schnittstelle sowie Profilname und Exportdatum. Wenn der Handshake wieder scheitert, ist die Differenz zwischen dieser Notiz und der aktuellen Konfiguration der Fehler, und niemand muss neu entdecken, welchen der beiden Ports der Dienst verwendet.