OpenVPN auf 443 weiter blockiert? Prüfen Sie, was das Netz inspiziert

Port 443 ändert die Nummer, nicht die Form des Protokolls. Wenn der Pfad TLS inspiziert oder beendet, sind ein Wrapper und eine korrekte Host-Route die nächsten Tests.

Der Tunnel verbindet sich aus einer Heimleitung und bleibt in einem Hotel- oder Firmennetz hängen, und der Umzug des Servers auf Port 443 änderte nichts. Dieses Ergebnis ist häufig genug, um eine Form zu haben: Der Port war der leichte Teil, und der Rest der Entscheidung gehört allem, was zwischen Client und Server sitzt. Zwei Fragen klären die meisten Fälle, und keine von ihnen dreht sich um Verschlüsselungsverfahren. Akzeptiert das Netz einen TLS-Handshake an diese Adresse, und behält der Client eine Route zu seinem eigenen Wrapper, solange der Tunnel steht?

Der Handshake verrät mehr als die Nummer

Ein nativer VPN-Listener auf TCP 443 spricht ab dem ersten Paket sein eigenes Protokoll. Ein ClientHello hat ein Versionsfeld, einen Zufallswert und eine Erweiterungsliste, und ein Gerät, das ein paar hundert Byte liest, erkennt den Unterschied, ohne etwas zu entschlüsseln. Portnummern sind billig zu erfüllen, und die Protokollform ist das, was der Filter tatsächlich prüft. Regeln werden meist auch pro Protokoll geschrieben, eine Richtlinie, die TLS inspiziert, sagt also nichts über UDP.

Ein transparenter Proxy, der auf einer gültigen TLS-Sitzung besteht, verwirft die Verbindung während des Aufbaus, oft nachdem der TCP-Handshake abgeschlossen ist. Dieses Detail zählt später, denn es bedeutet, dass das Client-Log endet, nachdem der Socket aufgebaut ist.

Das Umhüllen des Stroms schafft zwei Fehlerpunkte

Ein TLS-Wrapper wie stunnel stellt die erwartete Form wieder her: Der Client verbindet sich mit einem lokalen Listener, der Wrapper öffnet eine echte TLS-Sitzung zum Server auf 443, und ein zweiter Wrapper auf dem Server reicht die entschlüsselten Bytes an den VPN-Daemon weiter. Die äußere Sitzung sieht nun aus wie jede andere HTTPS-Verbindung. Der VPN-Daemon auf dem Server sollte nur auf Loopback lauschen, denn nichts außerhalb des Wrappers muss ihn erreichen.

Drei getrennte Dinge müssen für dieses Design zusammenpassen. Das Client-Profil zeigt auf den lokalen Listener, das Serverzertifikat passt zu dem Namen, den der Client prüft, und die Weiterleitung auf der Serverseite zielt auf den Port, den der Daemon wirklich nutzt. Stimmt eines davon nicht, stirbt die Verbindung, bevor die VPN-Schicht erreicht wird. Eine Zertifikatsabweichung erscheint dann als Wrapper-Fehler statt als VPN-Fehler, und deshalb lohnt es sich, beide Logs nebeneinander zu lesen.

Die Route zum Wrapper ist die Falle

Sobald der Tunnel steht, zeigt die Standardroute hinein, und die äußere TLS-Sitzung braucht einen Weg, der nicht in den Tunnel führt, den sie trägt. Ein gewöhnlicher VPN-Client schützt die Adresse, die er anwählt; ein umhüllter Client wählt sein eigenes Loopback an, die Zieladresse des Wrappers ist für diesen Schutz also unsichtbar.

sudo ip route add 198.51.100.20 via 192.168.0.1
sudo openvpn --config client.ovpn
sudo ip route del 198.51.100.20

Die genauen Adressen füllen Sie selbst aus, und die Route muss während der gesamten Lebensdauer der Verbindung bestehen, nicht nur beim Start. Ein kleines Wrapper-Skript, das die Route vor dem Client hinzufügt und danach entfernt, ist verlässlicher als ein gemerkter Befehl.

Auf Android ist das Gegenstück zu dieser Ausnahme eine Einstellung pro App: Schließen Sie die Wrapper-Anwendung vom Tunnel aus, damit ihr eigener Datenverkehr über die Mobilverbindung geht. Ohne die Ausnahme wird der Wrapper in den Tunnel geleitet, den er aufzubauen versucht, und die Wiederverbindungsschleife sieht wie ein Serverproblem aus.

Lesen Sie das Timing, bevor Sie etwas ändern

Eine Sitzung, die jedes Mal nach demselben Intervall stirbt, ist eine Richtliniensignatur und kein kryptografischer Fehler, und langfristige Flusslimits erzeugen genau dieses Muster. Eine Verbindung, die direkt nach dem Handshake zurückgesetzt wird, deutet auf einen Proxy hin, dem die Zertifikatskette nicht gefiel.

Vergleichen Sie den Zertifikatsaussteller einer gewöhnlichen HTTPS-Seite aus beiden Netzen. Unterscheidet sich der Aussteller im eingeschränkten Netz, beendet etwas TLS in der Mitte, und kein Wrapper übersteht diese Abfangung unverändert. Derselbe Vergleich sagt Ihnen, ob die Sperre auf Ihren Servernamen oder auf jede TLS-Sitzung an dieser Adresse zielt.

Schreiben Sie das beobachtete Verhalten auf: wie lange die Sitzung hielt, ob der Socket geöffnet wurde, ob der Wrapper einen Handshake protokollierte. Jedes davon engt den nächsten Test ein.

Testen Sie jeweils eine Variable

Prüfen Sie zuerst UDP, weil manche Netze es ganz verwerfen und ein UDP-Fehler nichts über 443 sagt. Probieren Sie dann TCP 443 ohne den Wrapper, danach den Wrapper auf 443. Lesen Sie das Client-Log bei jedem Schritt und hören Sie auf, sobald sich das Verhalten ändert.

Ändern Sie pro Versuch ein Element. Ein neuer Port, ein neuer Wrapper und ein neues Verschlüsselungsverfahren im selben Lauf lassen Sie nicht sagen, welche der drei zählte.

Ähnliche Artikel