OpenVPN funktioniert zu Hause, aber in einem Netz nicht: UDP oder TCP?

Dasselbe Profil verbindet sich zu Hause und bleibt in einem Hotel-, Campus- oder Filialnetz hängen. Die Zugangsdaten haben sich nicht geändert, also ist die interessante Variable der Pfad: was mit den Paketen passiert, bevor OpenVPN sie liest. Vier mögliche Ursachen in der Reihenfolge zu vergleichen, in der man sie testen kann, ist besser als bei Zertifikaten zu raten. Jede hinterlässt eine andere Spur, und die Spur ist es, was sie trennt.

Welche Stufe gescheitert ist, sagt, welcher Vergleich zählt

Das Client-Log hält bereits fest, wie weit Sie gekommen sind. Eine Zeile, die besagt, dass die TLS-Schlüsselaushandlung nicht innerhalb der Zeitgrenze stattfand, bedeutet: ein erstes Paket ging hinaus, und nichts Brauchbares kam zurück, was auf den Pfad deutet. Eine Zertifikatsablehnung sieht völlig anders aus: eine Antwort kommt an, dann benennt ein konkreter Verifikationsfehler den Grund. Merken Sie sich die letzte Zeile vor der Wiederholungsschleife, denn das ist der Wert, den Sie zwischen Netzen vergleichen.

Zeichnen Sie während des Wiederholens auf, nicht danach. Auf dem Client zeigt tcpdump -ni any udp port 1194, ob überhaupt eine Antwort zurückkommt. Wiederholen Sie das auf dem WAN-Interface eines Servers, den Sie kontrollieren; das zeigt, ob diese Pakete überhaupt am fernen Ende ankommen.

Einseitiger Verkehr ist das nützlichste Ergebnis, das hier verfügbar ist, weil es eine sporadische Beschwerde in eine Untersuchungsrichtung verwandelt. Behalten Sie die Mitschnittdateien, denn der nächste Bericht über dasselbe Problem lässt sich mit Beweisen leichter schließen als mit einer Beschreibung.

UDP-Filterung gegenüber einem geschlossenen Port

Viele Zugangsnetze halten anhaltendes UDP für verdächtig, und manche ISPs stimmen zu. Ein geschlossener Port erzeugt dieselbe Stille aus Sicht des Clients. Der Unterschied ist die Selektivität: ein Filter ist wählerisch, welche Ziele oder Ports er verwirft, während ein geschlossener Port alles abweist, was auf diesen einen Port zielt.

Ein TCP-Profil auf Port 443 ist der übliche Ausweg, weil es wie ein gewöhnlicher HTTPS-Fluss aussieht und die meisten Captive Portals und Ausgangsfilter passiert. Zwei Bedingungen müssen gelten. Der Server muss mit proto tcp-server lauschen und der Client muss mit proto tcp-client übereinstimmen, und der Betreiber muss diesen alternativen Endpunkt veröffentlichen. Ein funktionierendes UDP-Profil umzuschreiben, um TCP 443 zu behaupten, führt nirgendwohin, wenn am anderen Ende niemand lauscht.

Ein geschlossener Port ist ein Konfigurationsproblem und kein Zensurproblem. Ein Server hinter einem Heimrouter braucht eine Portweiterleitung für UDP, und die Router-Firewall muss sie erlauben. Wurde der Port nie zugelassen, scheitert jeder Client an der Aushandlung unabhängig von den Zugangsdaten, und der Fehler folgt dem Server statt dem Netz.

Ältere Protokolle schneiden auf dieser Achse schlecht ab. PPTP braucht TCP 1723 plus GRE, und GRE ist IP-Protokoll 47 und kein Port, also drückt das keine gewöhnliche Portweiterleitung aus.

Wenn der Switch derjenige ist, der Pakete fallen lässt

Ein verwalteter Switch kann den Tunnel absichtlich verwerfen. Manche HPE- und Aruba-Modelle bieten im Bereich erweiterte Sicherheit eine UDP-Flut-Schutzsteuerung, gelegentlich als Prevent UDP Blat Attack bezeichnet. Ist diese Steuerung aktiv, antwortet ein Server hinter dem Switch gar nicht, und jeder Client läuft auf dieselbe Weise in eine Zeitüberschreitung. Sie abzuschalten und die laufende Konfiguration zu speichern ist die ganze Reparatur, aber erst nachdem Sie festgestellt haben, dass der Switch tatsächlich im Pfad liegt.

Gegenbelege sind es, was einen Switch-Verwurf von einer Provider-Blockade trennt. Lesen Sie die Interface-Zähler und das Flut-Schutz-Log, bevor Sie ein Ticket beim ISP öffnen. Consumer-Router mit DoS- oder Flut-Schutz scheitern auf dieselbe Weise, und jede Middlebox mit kurzer UDP-Inaktivitätszeit ebenfalls. Ein Handshake, der nie zustande kommt, deutet auf einen Verwurf, während ein Tunnel, der nach Minuten der Stille stirbt, auf die Zeitgrenze deutet.

Notieren Sie jedes Gerät zwischen Client und Server, bevor Sie ein Profil ändern. Eine auf der falschen Schicht angewandte Korrektur sieht richtig aus bis zum nächsten Netz. Diese Liste sagt auch dem nächsten Ingenieur, wo er schauen muss, ohne die ganze Untersuchung zu wiederholen.

Eine Adressüberschneidung, die wie ein DNS-Fehler aussieht

Ein Zugangsnetz, das innerhalb von 10.0.0.0/8 nummeriert ist, kann den Tunnel-Pool überschneiden, und der Resolver lebt meist in diesem Pool. Wenn ein Laptop eine Adresse wie 10.184.178.50 mit /8-Maske im WLAN erhält, ist jedes 10.x-Ziel per Definition lokal. Pakete für 10.4.0.1 gehen dann ins LAN, der Tunnel bleibt oben, und die Namensauflösung scheitert.

ip addr zeigt die Überschneidung auf einen Blick, und ip route get 10.4.0.1 zeigt, wohin das Paket wirklich geliefert würde. Weil das sichtbare Symptom ein Resolver-Fehler ist, überlebt dieser Fall oft mehrere Runden von DNS-Änderungen.

Nummerieren Sie den Pool neu, oder halten Sie dieses Zugangsnetz außerhalb des Bereichs. Keine clientseitige Einstellung rettet aus einer Überschneidung.

Die Entscheidung zwischen TCP-Fallback und Pfadkorrektur

Wählen Sie den TCP-Fallback, wenn Sie den Pfad nicht kontrollieren und Benutzer heute arbeiten müssen, und akzeptieren Sie die Kosten: TCP in TCP verhält sich auf verlustbehafteten Strecken schlecht, und der Fallback braucht einen Listener, den Sie betreiben. Wählen Sie die Pfadkorrektur, wenn die Blockade auf Ihrer eigenen Infrastruktur sitzt, weil eine Firewall-Regel billiger ist als ein zweiter Listener. So oder so, gehen Sie die Schichten der Reihe nach durch: Link, äußerer Transport, Aushandlung, inneres Routing. Die Stufe, die in diesem Netz gescheitert ist, ist die einzige Tatsache, die zählt.

Halten Sie das Ergebnis pro Netz fest statt pro Benutzer. Der nächste Bericht desselben Fehlers beginnt dann bei einer bekannten Stufe statt bei einer Zertifikatstheorie. Dieser Eintrag ist auch das, was einen dauerhaften zweiten Listener rechtfertigt, falls je einer nötig wird.