Wo TLS in OpenVPN sitzt und was die Form verändert

OpenVPN verwendet tatsächlich TLS, und Menschen dehnen das routinemäßig zu einer Behauptung aus, die es nicht trägt: dass ein Tunnel deshalb wie ein Browser aussieht, der eine Seite besucht. Der erste Teil stimmt. Der zweite nicht. TLS gehört hier zu einem Steuerkanal, der innerhalb des eigenen Containers von OpenVPN reist, neben einem Nutzlastkanal mit völlig anderer Kryptografie, sodass wer die ersten Bytes untersucht, OpenVPN sieht.

Zwei Gespräche in einem Umschlag

Stellen Sie sich eine Sitzung als zwei Gespräche vor, die einen Umschlag teilen. Das eine validiert Zertifikate und leitet Schlüsselmaterial ab. Das andere verschlüsselt, was Sie tatsächlich senden, mit dem, was das erste erzeugt hat.

Der Umschlag ist das Protokoll. Jedes Paket beginnt mit einem kleinen Header, der seinen Typ benennt, und dieser Header kommt vor allem anderen an.

Was tatsächlich zuerst ankommt

Wegen dieser Reihenfolge ist das erste auf der Leitung kein TLS-Record. Es ist der Header von OpenVPN, gefolgt vom Inhalt desjenigen Kanals, den der Header ankündigt. Ein ClientHello existiert darin, nur nicht am Byte null. Zum Bemerken des Unterschieds ist keine Entschlüsselung nötig, denn die Form allein verrät ihn.

Auch Standardwerte zählen hier. Der Fluss geht per UDP an 1194, sofern das Profil nicht TCP wählt. In beiden Fällen ist das äußere Erscheinungsbild ein Tunnel und keine Webanfrage.

Drei ehrliche Wege, die Form zu ändern

Ein TLS-Terminator wie stunnel nimmt an beiden Enden TLS auf einem Port an und übergibt den entschlüsselten Strom lokal an OpenVPN, sodass das Netzwerk TLS zu diesem Port sieht. Ein Protokoll, das ab dem ersten Byte TLS ist, verhält sich wieder anders: der AnyConnect-kompatible Austausch, den ocserv implementiert, ähnelt dem Unternehmensfernzugriff, den viele Netzwerke bereits erwarten. SSTP, das mit Windows kommt, hat dieselbe Eigenschaft in einem anderen Produkt.

Unter Linux trägt die Option -w von SSH eine Punkt-zu-Punkt-Verbindung innerhalb einer SSH-Sitzung, was nützlich ist, wenn SSH das einzige erlaubte Protokoll ist. Sie ist die billigste der vier, wenn SSH aus diesem Netzwerk bereits funktioniert, und die am wenigsten nützliche, wenn nicht.

Was keines davon ändert

Nichts davon ändert, was der Tunnel erreichen kann. Sie machen eine blockierte Adresse nicht erreichbar, sie authentifizieren niemanden, und sie entscheiden keine Routen.

Ein Wrapper kostet Sie zudem eine Komponente. Zwei Listener und zwei Konfigurationsdateien bedeuten zwei Stellen für einen Fehler, und beide sehen vom Platz des Benutzers identisch aus. Kalkulieren Sie das ein, bevor Sie einen adoptieren. Die Sitzung bleibt ein einziger langlebiger verschlüsselter Fluss zu einem Ziel, und ihr Volumen und Timing bleiben sichtbar.

Erst diagnostizieren, dann wählen

Also erst diagnostizieren. Verworfenes UDP wird durch den TCP-Modus beantwortet, eine erkannte Signatur durch ein anderes Protokoll oder einen Wrapper. Ein Werkzeug zu wählen, bevor man die Blockade kennt, ist der Weg, auf dem Menschen am Ende drei Schichten warten, die alle aus demselben Grund scheitern.

Ein Netzwerk, das nur Web-Ports erlaubt, verengt die Wahl auf ein TLS-basiertes Protokoll auf 443. Alle drei auf einmal anzuwenden ergibt einen Stapel, den niemand debuggen kann, also ändern Sie eine Sache und testen Sie denselben Fluss erneut.

Wenn keines davon zutrifft, ist die zutreffende Antwort, dass dieses Netzwerk keinen Tunnel für Sie tragen wird. Das ist ein Befund und kein Scheitern des Aufwands. Mehr Optionen durchzuprobieren macht eine oben getroffene Richtlinienentscheidung nicht rückgängig.

Eine Grenze steht vor all dem. Die Erlaubnis, einen Tunnel in einem fremden Netzwerk zu betreiben, ist eine Richtlinienfrage, die getrennt davon entschieden wird, ob der Mechanismus funktioniert. Diese Fakten erklären, was ein Beobachter sieht, und sie erteilen keine Erlaubnis.