Synology NAS mit zwei LAN-Anschlüssen: Warum der VPN-Handshake scheitert

Der Laptop meldet einen TLS-Handshake-Fehler, was nach einem Zertifikatsproblem klingt und meist keines ist. Auf einem NAS mit zwei Ethernet-Anschlüssen ist die häufigste Ursache eine Router-Weiterleitung, die auf die Adresse zeigt, auf der das Paket nicht lauscht, und die Meldung des Clients ist in beiden Fällen identisch. Das Paket antwortet nicht auf dem zweiten Anschluss, nur weil beide Kabel eingesteckt sind. Bevor jemand ein Zertifikat neu ausstellt, sollten Sie belegen, dass überhaupt ein Paket das NAS erreicht.

Was der Client meldet und was tatsächlich geschah

Ein Handshake-Fehler eines OpenVPN-Clients ist ein Sammelbegriff. Er deckt eine Zertifikatsabweichung, eine Transportabweichung, einen Lauscher auf einem anderen Anschluss und eine Weiterleitung ab, die nichts zugestellt hat. Deshalb ist die Meldung als Ausgangspunkt nutzlos und nur als Bestätigung nützlich. Behandeln Sie sie als Aussage, dass die Sitzung nicht zustande kam, und als nichts Genaueres.

Der Anschluss und die gebundene Adresse sind die beiden Fakten, die entscheiden, ob ein Paket jemals ankommt.

Notieren Sie beides, bevor Sie etwas ändern, denn eine plausible Korrektur auf der falschen Ebene ist der Weg, auf dem aus einem Fünfzehn-Minuten-Problem ein ganzer Nachmittag wird. Halten Sie Schnittstelle, Adresse darauf, Anschluss und Transport fest. Diese vier Werte bilden den gesamten eingehenden Pfad, und der nächste Abschnitt erklärt, wo jeder davon lebt.

Finden Sie die Adresse, auf der das Paket lauscht

DSM nummeriert die Ethernet-Anschlüsse, und jeder trägt seine eigene Adresse. Die Seite VPN Server nennt die Schnittstelle, die der OpenVPN-Dienst verwendet, und das Netzwerkfenster zeigt die auf dieser Schnittstelle konfigurierte Adresse. Lesen Sie sie in dieser Reihenfolge, vom Dienst nach außen, damit Sie beschreiben, was lauscht, statt was Sie annehmen, dass es verwendet werden sollte.

Der Dienst bindet eine Adresse. Dass beide Anschlüsse verbunden und aktiv sind, bringt den Dienst nicht dazu, auf dem zweiten zu antworten. Eine statische Adresse auf der einen Schnittstelle neben einer DHCP-Adresse auf der anderen ergibt zwei ähnliche Werte, die sich auf einen Blick leicht verwechseln lassen, besonders wenn sie sich nur im letzten Oktett unterscheiden. Kopieren Sie die Adresse aus dem Fenster, statt sie aus dem Gedächtnis zu tippen. Bestätigen Sie dann auf dem NAS, was tatsächlich an den Anschluss gebunden ist.

sudo ss -lunp | grep 1194

Wenn diese Ausgabe eine Adresse nennt, die Sie nicht erwartet haben, zielt die Weiterleitung auf die falsche Schnittstelle, und alles Weitere hier ist Buchhaltung. Korrigieren Sie die Regel, bevor Sie weiterlesen, sonst debuggen Sie am Ende ein Zertifikat wegen eines Pakets, das den Router nie verlassen hat.

Reparieren Sie die Weiterleitung, dann beobachten Sie den Zähler

Bearbeiten Sie die bestehende Weiterleitungsregel, statt eine zweite für denselben externen Anschluss hinzuzufügen. Zwei Regeln können in der Tabelle eines Routers nebeneinander bestehen, und nur eine gewinnt jemals, was eine Fehlersuche in eine Debatte darüber verwandelt, welche die echte ist. Richten Sie die interne Adresse auf den Wert, den Sie vom NAS gelesen haben, und lassen Sie den internen Anschluss zu dem passen, auf dem der Dienst lauscht.

Bezieht DSM diese Adresse per DHCP, legen Sie zuerst eine Reservierung an. Eine Änderung der Lease bricht stillschweigend eine Weiterleitung, die gestern noch funktionierte.

sudo tcpdump -i any -n udp port 1194

Beginnen Sie den Mitschnitt, bevor der Client eine Verbindung versucht, und lesen Sie die Quelladresse in allem, was erscheint. Gar nichts bedeutet, dass etwas unterwegs es verworfen hat: die Weiterleitung, die DSM-Firewall oder die Schnittstelle, auf die sie zielte, und Zertifikate können nicht die Ursache sein, solange das gilt. Etwas, das von der öffentlichen Adresse des Clients ohne Antwort eintrifft, bedeutet, dass das NAS die Anfrage erhielt und sich entschied, nicht zu antworten. Das sind verschiedene Befunde, und nur der zweite schickt Sie zurück in die Einstellungen des Pakets selbst.

Erst dann prüfen Sie Zertifikate und Transport

Sobald Pakete ankommen, exportieren Sie das Profil nach jeder Zertifikatsänderung neu, denn die alte Datei trägt noch die Autorität, mit der sie erstellt wurde. Ein von Hand bearbeitetes Profil für einen anderen Transport lässt den Client auf einen Lauscher warten, den es nicht gibt, und es meldet denselben allgemeinen Fehler wie alles andere. Vergleichen Sie den Transport im Profil mit dem Transport, den zu bedienen das Paket eingestellt ist. Zwei Profile für zwei Transporte sind ein legitimes Design, ein für beide bearbeitetes Profil nicht.

Testen Sie als letzten Schritt von außerhalb Ihres eigenen Netzwerks, denn eine Verbindung aus dem LAN kann über einen Pfad gelingen, der die Weiterleitung nie berührt.

Halten Sie das exportierte Profil, die Schnittstellenadresse und die Weiterleitungsregel zusammen in einer Notiz fest. Wenn sich eine Adresse ändert, ist diese Notiz der Unterschied zwischen einer Reparatur und einer Wiederholung. Nichts auf diesem Pfad erforderte eine Neuinstallation eines Pakets, was man sich merken sollte, bevor der nächste Neustart beschuldigt wird.