DD-WRT OpenVPN 2.5-Listener tot? Lesen Sie die erzeugte Konfiguration

Ein toter Listener auf DD-WRT bedeutet meist, dass der Daemon beim Parsen seiner Konfiguration beendet wurde, nicht dass eine Firewall-Regel den Port blockiert hat. OpenVPN 2.5 hat mehrere Standardwerte verschärft, auf die sich ältere Konfigurationen verlassen haben, und eine erzeugte Konfiguration, die auf einem älteren Build funktionierte, kann abgelehnt werden, bevor der Socket überhaupt geöffnet wird. Der Grund steht im Log des Routers selbst, die Eingabe in der erzeugten Datei. Beides in dieser Reihenfolge zu lesen ist schneller als jeder Paketmitschnitt.

Der Daemon ist nicht die Firewall

Der Unterschied zählt, weil beide Fehler von außen gleich aussehen: Ein Client sendet einen Handshake und bekommt nichts zurück. Das eine ist ein Prozess, der nicht läuft, das andere ein Prozess, der läuft und filtert.

Trennen Sie beides mit zwei Prüfungen, bevor Sie etwas ändern, denn eine Firewall-Änderung an einem toten Daemon fügt nur eine zweite Variable hinzu.

Lesen Sie die von DD-WRT erzeugte Konfiguration

DD-WRT gibt OpenVPN nicht den Text, den Sie in die Weboberfläche getippt haben. Es schreibt eine erzeugte Konfiguration nach /tmp/openvpn/openvpn.conf und startet den Daemon mit dieser Datei, sodass die Felder der Oberfläche und jeder Text in Additional Config zusammengeführt werden, bevor OpenVPN sie je sieht. Wenn Sie das Formular statt der erzeugten Datei debuggen, lesen Sie eine Absicht statt der tatsächlichen Eingabe. Kopieren Sie die Datei an einen dauerhaften Ort, bevor ein Neustart /tmp leert.

Vergleichen Sie die erzeugte Datei mit dem, was Sie beabsichtigt haben, besonders dort, wo die Oberfläche eine Direktive schreibt, die Sie nie gewählt haben. Ein Dropdown, das eine veraltete Option ausgibt, ist im Formular unsichtbar und für den Daemon fatal.

Wenn die erzeugte Datei leer ist oder fehlt, hat der Daemon den Start gar nicht erreicht, und das Problem liegt vor OpenVPN.

Was OpenVPN 2.5 nicht mehr akzeptiert

OpenVPN 2.5 hat ncp-ciphers durch data-ciphers ersetzt und die standardmäßige Mindestversion von TLS auf 1.2 angehoben. Es hat auch die Komprimierungsbehandlung geändert, sodass ein Peer, der Komprimierung anbietet, abgelehnt wird, sofern die Konfiguration es nicht ausdrücklich erlaubt, und ältere Optionsnamen wie ns-cert-type zugunsten von remote-cert-tls als veraltet markiert. Jede dieser Änderungen macht aus einer zuvor funktionierenden Konfiguration einen Parse- oder Aushandlungsfehler.

Der Fehlermodus hängt von der Direktive ab. Eine unbekannte oder entfernte Option stoppt den Daemon beim Start, das ist Ihr toter Listener. Eine Aushandlungsabweichung lässt den Daemon laufen und weist Clients ab, was von der Client-Seite wie ein Firewall-Problem aussieht.

Lesen Sie den ersten Fehler im Log, nicht den letzten. Das Parsen stoppt bei der ersten fehlerhaften Direktive, und alles danach ist Rauschen vom Herunterfahren.

Die Broadcom-spezifischen Voraussetzungen

Auf Broadcom-Builds muss das Tunnelgerät existieren, bevor der Daemon es nutzen kann. Prüfen Sie, ob das tun-Modul geladen ist und ob /dev/net/tun vorhanden ist, denn ein fehlendes Gerät erzeugt einen Startfehler, der nichts mit Zertifikaten zu tun hat. Dasselbe gilt für die Hilfsskripte, die DD-WRT für Routen und DNS erzeugt: Fehlen sie oder sind sie nicht ausführbar, kann der Daemon starten und trotzdem seine Einrichtung nicht abschließen.

Starten Sie den Daemon im Vordergrund mit höherer Ausführlichkeit gegen die erzeugte Konfiguration, wenn Sie die echte Meldung brauchen. Ein Vordergrundlauf gibt den Parse-Fehler aus, den das Init-Skript verschluckt hat.

Stellen Sie danach den normalen Dienst wieder her, denn ein Vordergrund-Daemon und das Init-Skript streiten sich um den Port.

Beweisen Sie, dass der Listener existiert, bevor Sie Clients debuggen

Bestätigen Sie Prozess und Socket getrennt: ein Befehl für den laufenden Daemon, ein anderer für einen gebundenen UDP-Port auf der erwarteten Adresse. Ein Prozess ohne Socket bedeutet, dass er noch in der Einrichtung steckt oder an die falsche Schnittstelle gebunden ist. Das Paar ist gerade deshalb ein nützlicher Test, weil die eine Hälfte ohne die andere nicht wahr sein kann.

Clientseitiges Debuggen ergibt erst Sinn, wenn der Listener existiert. Prüfen Sie dann, ob Cipher und TLS-Einstellungen des Clients zu den data-ciphers des Servers und zu dessen Mindestversion passen und ob der Port tatsächlich zum Router weitergeleitet wird.

Bewahren Sie die erzeugte Konfiguration und die Logzeile auf, die die Korrektur bewiesen hat. Das nächste Firmware-Update kann die Standardwerte erneut ändern, und dieser Eintrag macht aus einer Wiederholung eine Fünf-Minuten-Prüfung.