OpenVPN über einen HTTP-Proxy: zuerst die CONNECT-Antwort lesen

Richten Sie einen VPN-Client auf einen Firmen-HTTP-Proxy, und die erste nützliche Tatsache ist, dass der Proxy nicht das Protokoll des VPN spricht. Er öffnet eine gewöhnliche TCP-Verbindung zu der Adresse, die Sie genannt haben, und tritt dann beiseite, sodass Ihr Client und der Server ihren eigenen Austausch über diesen Strom führen. Alles, was der Client braucht, vom Transporttyp bis zum Listener des Servers, muss zu dieser Anordnung passen. Zwei Nichtübereinstimmungen erklären die meisten Fehlschläge: ein UDP-Profil, das auf einen CONNECT-Proxy zielt, und eine Proxy-Antwort, die für einen VPN-Fehler gehalten wird.

Was der Proxy trägt und was nicht

Der Proxy ist nur eine Transportstufe. Er wird nicht Ihr Browser-Proxy, er speichert die Seiten, die Sie durch den Tunnel besuchen, nicht zwischen, und er sieht den inneren Verkehr nicht, sofern niemand absichtlich eine Inspektion eingerichtet hat. Der Tunnel, den er öffnet, ist für ihn konstruktionsbedingt undurchsichtig.

Das bedeutet auch, dass der Proxy einen Server ohne passenden Listener nicht reparieren kann. Die Erlaubnis, ein Ziel zu erreichen, und ein Dienst, der an diesem Ziel lauscht, sind zwei getrennte Tatsachen, und nur die erste gehört dem Proxy-Administrator.

Der Träger muss an beiden Enden TCP sein

Ein herkömmlicher CONNECT-Proxy reicht nur einen Bytestrom weiter , also muss der Client einen Stromtransport verwenden. Ein Client-Fragment für diesen Fall sieht so aus:

proto tcp-client
remote vpn.example.net 1194
http-proxy proxy.corp.example 3128

Die Serverseite braucht einen echten TCP-Listener auf dem Port, der in der remote-Zeile genannt wird. Ändert man proto udp in einem Profil zu proto tcp-client, entsteht ein Client, der einen Strom erwartet; der Strom auf der Gegenseite entsteht dadurch nicht. Antwortet derselbe Server an diesem Port auch über UDP, ist das ein anderer Listener, kein zweiter Modus desselben.

Wo eine eigene TCP-Instanz existiert, sind ihr Tunnelgerät, ihr Adresspool und ihr Routing eigene Ressourcen. Eine funktionierende Konfiguration zu kopieren und das Transportwort zu ändern lässt diese Ressourcen auf die ursprüngliche Instanz zeigen, was eine Verbindung ergibt, die sich authentifiziert und dann nichts routet.

Lesen Sie die Proxy-Antwort vor dem VPN-Ergebnis

Der erste Austausch des Clients ist eine Anforderungszeile, die Zielhost und Port nennt. Die Antwort auf diese Zeile sagt Ihnen, ob überhaupt ein Bytestrom existiert, und sie kommt, bevor irgendein Zertifikat oder eine Anmeldeinformation geprüft wird:

CONNECT vpn.example.net:1194 HTTP/1.1
Host: vpn.example.net:1194

Eine Antwort der 200-Klasse auf CONNECT bedeutet, dass der Strom existiert. Sie sagt nichts darüber, ob das Gateway-Zertifikat vertrauenswürdig ist, ob der gemeinsame Schlüssel passt oder ob das Benutzerkonto gültig ist. Diese Prüfungen erfolgen danach, innerhalb des Stroms, und sie scheitern mit den eigenen Meldungen des Clients statt mit einer HTTP-Statuszeile. Suchen Sie im Client-Protokoll nach dem ersten OpenVPN Ereignis nach dem Proxy-Handshake, nicht nach der letzten Zeile vor dem Schließen des Fensters.

Proxy-Anmeldeinformationen und VPN-Anmeldeinformationen sind häufig verschiedene Identitäten bei verschiedenen Teams. Ein 407 ist kein schlechtes Passwort des VPN-Kontos, und ein abgelehntes Zertifikat ist kein Berechtigungsproblem des Proxys.

Was CONNECT nicht offenlegt

Ein ausdrücklicher CONNECT-Tunnel ist keine Abhörmaßnahme. Der Proxy leitet Bytes weiter und beendet die TLS-Sitzung des VPN nicht, daher bleibt die Prüfung des Serverzertifikats durch den Client aussagekräftig und sollte eingeschaltet bleiben. Die Prüfung abzuschalten, um an einem Proxy vorbeizukommen, löst ein anderes Problem als Ihr eigenes.

Es gibt separate Vereinbarungen, bei denen eine Organisation TLS bewusst beendet und inspiziert. Diese erfordern ihre eigene Vertrauenskonfiguration und ihre eigene politische Entscheidung, und sie sind nicht das, was eine gewöhnliche http-proxy-Zeile verlangt.

Die Kosten von TCP in TCP

Der Tunnel über TCP hält den äußeren Strom geordnet und mit Wiederholung, und der innere Verkehr ist meist ebenfalls TCP. Die beiden Wiederherstellungsmechanismen koordinieren sich nicht, daher kann ein einzelnes verlorenes Segment alles blockieren, was diesen äußeren Strom teilt, bis es erneut übertragen wird. Das ist ein echter Kompromiss für Kompatibilität, kein kostenloses Upgrade.

Nutzen Sie den Proxy-Pfad, wenn das Netz Ihnen keine Alternative lässt, und bevorzugen Sie einen direkten UDP-Pfad, wo die Richtlinie es erlaubt. Prüfen Sie in jedem Fall nach einer Änderung, dass derselbe Proxy, dasselbe Ziel und dasselbe Profil die nächste Stufe erreichen; ein Browser, der an dieser Adresse eine Seite lädt, verwendet ein anderes Protokoll und beweist nichts über den Tunnel.