Netgear OpenVPN: TUN und TAP lauschen auf verschiedenen Ports

Ein Telefon verbindet sich ohne Beanstandung mit dem VPN des Routers, und ein Laptop, der ein Profil von derselben Downloadseite verwendet, läuft in eine Zeitüberschreitung. An den Zertifikaten hat sich zwischen diesen beiden Versuchen nichts geändert, denn der Laptop erreichte nie den Punkt, an dem Zertifikate eine Rolle spielen. Der Router veröffentlicht getrennte Listener für TUN und TAP, und ein funktionierendes Profil muss denjenigen wählen, der zum eigenen Gerätetyp gehört.

Zu entscheiden, welchem von drei möglichen Fehlern nachzugehen ist, ist hier die ganze Aufgabe: der Port, der Gerätetyp oder die Cipher-Aushandlung des Datenkanals.

Drei Dinge, die zusammenpassen müssen

Der Gerätetyp, die Interface-Zeile des Profils und der Listener-Port bilden eine Entscheidung, nicht drei. Ein Profil, das dev tun deklariert und auf den TAP-Listener zielt, kann die Sitzung nicht abschließen, und umgekehrt scheitert es genauso. Lesen Sie den Port für Ihr Modell und Ihre Firmware auf der VPN-Seite des Routers selbst statt in einem Leitfaden, denn die Nummern verschieben sich zwischen Builds. Notieren Sie Modell und Firmware-Version neben dieser Nummer, damit die nächste Person sie überprüfen kann.

Berichte aus der Praxis nennen ein Paar wie 12973 für TUN und 12974 für TAP auf einer Firmware und eine andere Nummer auf einer anderen. Lesen Sie das als Beleg dafür, dass Builds sich unterscheiden, nicht als zu kopierende Konstanten. Das Profil braucht dann den entfernungsgerechten Hostnamen: den dynamischen DNS-Namen des Routers statt einer WAN-Adresse, die sich ändern wird.

Nach der Korrektur von Port und Interface-Zeile sieht das Profil wie eine normale Client-Konfiguration mit einer remote-Zeile und einer dev-Zeile aus. Wenn die beiden nicht übereinstimmen, erzeugt noch so viel Wiederholen keine Sitzung.

Lesen Sie das Log in der Reihenfolge, in der es ausgegeben wird

Ein OpenVPN-Client meldet Ereignisse in der Reihenfolge, in der sie geschehen, sodass die letzte Zeile vor der Stille die zu prüfende Schicht benennt. Wenn der Lauf bei TLS Error: TLS key negotiation failed endet oder einfach auf eine erste Antwort wartet und aufgibt, fand nie ein Zertifikatsvergleich statt. Das deutet auf Erreichbarkeit, auf den Listener oder auf einen Port ohne etwas dahinter hin. Nichts davon wird durch Ersetzen der CA-Datei repariert.

Ein Lauf, der VERIFY OK erreicht und dann scheitert, liegt völlig woanders, mit eigenen Ursachen. Diese beiden Ausgänge zu sortieren, bevor Dateien angefasst werden, verhindert den klassischen Umweg über Zertifikatsbündel, die nie befragt wurden. Wenn der Handshake abgeschlossen ist, der Tunnel aber nicht hochkommt, schauen Sie auf die Cipher-Aushandlung statt auf die Erreichbarkeit.

Fügen Sie die Cipher-Liste hinzu, die ein moderner Client erwartet

Neuere OpenVPN-Clients lehnen ältere Voreinstellungen ab, die Consumer-Firmware noch anbietet, und das Symptom ist ein Aushandlungsfehler unmittelbar nach einem erfolgreichen Handshake. Die Korrektur ist eine Profilzeile, die benennt, was der Client akzeptiert: Setzen Sie data-ciphers in dieser Reihenfolge auf AES-256-GCM, AES-128-GCM, CHACHA20-POLY1305 und AES-128-CBC. Jeder Algorithmus, den der Router nicht implementiert, wird schlicht nie gewählt, eine längere Liste kostet also nichts außer einer etwas längeren Aushandlung.

Cipher aufzulisten lehrt den Router keinen, den er nicht hat. Wenn die Aushandlung weiterhin scheitert, prüfen Sie, ob die Routerseite eine eigene Cipher-Einstellung hat und ob diese Einstellung mindestens einen Eintrag enthält, den der Client akzeptiert. Zwei Listen ohne gemeinsames Element erzeugen genau denselben Fehler wie ein falscher Port, deshalb verdienen beide Enden einen Blick.

Einmal importieren statt Kopien von Hand zu bearbeiten

Der Import der korrigierten Datei in NetworkManager vermeidet einen Ordner voller leicht unterschiedlicher Profile: nmcli connection import type openvpn file client.ovpn, dann per Namen aktivieren. Behalten Sie das importierte Profil als die einzige Kopie, die Sie bearbeiten, und löschen Sie die Duplikate, die sich durch wiederholte Downloads ansammeln.

Testen Sie dann von außerhalb des LAN. Eine Verbindung aus demselben Netz beweist sehr wenig, weil der Verkehr den Tunnel womöglich gar nicht durchquert. Bestätigen Sie, dass eine Anfrage tatsächlich über den Router hinausgeht, nicht nur dass der Client einen verbundenen Zustand anzeigt.

Entscheiden Sie, was Sie bei Warnungen tun

Consumer-Firmware erzeugt üblicherweise ihre eigene Zertifizierungsstelle, und Clients beschweren sich über die Verifikation auf Weisen, die die Firmware nicht unterdrücken kann. Beurteilen Sie, ob diese Beschwerde für das relevant ist, was Sie schützen, statt jede Warnung als tödlich zu behandeln, und schalten Sie die Verifikation nicht global ab, um eine einzige Meldung stumm zu stellen. Eine geprüfte Warnung ist ein dokumentiertes Risiko; eine deaktivierte Verifikationseinstellung ist ein undokumentiertes.

Wenn die Firmware keinen unterstützten Weg bietet, eine Warnung zu korrigieren, die tatsächlich zählt, spricht diese Lücke dafür, das VPN anderswo zu hosten. Die Wahl zwischen Profilreparatur, Akzeptieren der Warnung und Verlegen des Endpunkts ist eine Entscheidung darüber, wie sehr Sie diesem Zertifikat trauen. Treffen Sie sie bewusst und notieren Sie, welche Option Sie gewählt haben, statt sich durch Dialoge zu klicken, bis das Symbol grün wird.