SOCKS5-Proxy für OpenVPN: TCP-Tunnel oder die Apps proxen?

Netzwerke, die nur ausgehenden Verkehr über einen Proxy zulassen, sind der Ort, an dem ein funktionierendes Profil plötzlich stirbt. Die Proxy-Adresse ist die uninteressanteste Variable in diesem Fehler. Alles entscheidet die Form des Verkehrs, den der Proxy weiterleitet, denn diese Proxys übertragen einen Bytestrom, und ein UDP-Tunnel ist keiner. Das lässt zwei Architekturen übrig, und sie brechen an verschiedenen Stellen.

Eine Einschränkung entscheidet das Design

SOCKS5 spezifiziert zwar einen UDP-Assoziationsmodus. Die Proxy-Unterstützung des OpenVPN-Clients ist dennoch um Ströme herum gebaut: socks-proxy ist für TCP-Profile dokumentiert, und ein HTTP-CONNECT-Proxy hat überhaupt keinen Datagramm-Pfad. Eine Zeile Dokumentation entscheidet die Architektur, bevor Sie eine Konfigurationsdatei anfassen.

Die Frage ist also nicht, welchen Proxy Sie wählen. Sie ist, ob der Tunnel ein Strom wird oder ein Datagramm bleibt und etwas anderes das Proxen übernimmt.

Option A: den Tunnel in einen Strom verwandeln

Das braucht einen Server mit TCP-Listener und ein Client-Profil, das den Proxy benennt. Beides ist nötig, und die Serverseite ist die, die man vergisst:

proto tcp-client
remote vpn.example.net 443
socks-proxy 127.0.0.1 1080

Ersetzen Sie die letzte Zeile durch http-proxy proxy.internal 8080, wenn der Proxy HTTP spricht, und fügen Sie eine Anmeldedatei hinzu, wenn er eine verlangt. Der Proxy muss bereit sein, CONNECT an Ihren VPN-Port auszuführen, und der Server muss auf TCP antworten; ein reiner UDP-Listener ignoriert den Versuch. 443 zu wählen ist ein praktischer Schritt, weil viele restriktive Netze ihn und wenig anderes erlauben.

Der Preis ist TCP auf TCP. Ein verlorenes äußeres Segment blockiert jeden inneren Strom, der diese Verbindung teilt, sodass Wiederherstellung, die sonst unabhängig wäre, geteilt wird. Der Aufbau dauert auch länger, und ein instabiler äußerer Pfad wird zu einem instabilen Tunnel statt zu einem langsamen.

Option B: den Tunnel in Ruhe lassen

Wenn der Tunnel auf UDP bleiben muss, ist der Tunnel nicht der Ort, an dem Sie etwas konfigurieren. Stattdessen wird ausgehendes TCP von Anwendungen an einen lokalen SOCKS-Listener umgeleitet, und die Anwendungen erfahren nie, dass ein Proxy existiert. Unter Linux ist das typischerweise redsocks plus eine NAT-REDIRECT-Regel in der nat-Tabelle.

Wieder nur TCP. Ein reiner HTTP-Proxy wie privoxy kann keine beliebigen Protokolle weiterleiten, und dieses Design fügt auch für die Anwendungen keine Datagramm-Unterstützung hinzu.

Jeder Anwendung direkt vom Proxy zu erzählen, ist meist besser, wo die Software es unterstützt. Es ist leichter zu prüfen, und es scheitert an einer Stelle, die Sie tatsächlich sehen.

Wo jede Option scheitert

Option A scheitert, wenn dem Server ein TCP-Listener fehlt, wenn der Proxy das CONNECT-Ziel verweigert oder wenn der äußere Strom unter das gedrosselt wird, was der Tunnel braucht. Die ersten beiden hinterlassen einen Eintrag im Proxy-Log; die dritte hinterlässt eine Verbindung, die aufgebaut wird und sich dann falsch anfühlt. Lesen Sie dieses Log, bevor Sie das Profil bearbeiten, denn es trennt ein Berechtigungsproblem von einem Kapazitätsproblem. Ein abgeschlossenes CONNECT verlagert die Untersuchung in den Tunnel.

Option B scheitert für alles, was Datagramme braucht, für Protokolle, die der Proxy nicht versteht, und still auf Hosts, wo die Umleitungsregel existiert, das Routing den Verkehr aber daran vorbeischickt.

Keine der Optionen ändert die Geräteanforderung. Pakete brauchen weiterhin einen TUN- oder TAP-Knoten, bevor der Kernel sie weiterleitet, also braucht der Prozess weiterhin Berechtigung auf /dev/net/tun. Ein Wrapper ändert, was nach dem Öffnen dieses Knotens passiert, nicht ob Sie einen brauchen.

Beweisen, welchen Pfad Sie gebaut haben

Schauen Sie auf Sockets statt auf das Tray-Symbol. Der VPN-Prozess sollte eine bestehende Verbindung zur Proxy-Adresse halten, und der Proxy sollte das Ziel protokolliert haben, das er erreichen sollte:

ss -tnp | grep openvpn

Greifen Sie dann nach einem Ziel, das nur der Tunnel bedienen kann, und nach einem Namen, den nur der Resolver des Tunnels beantworten kann. Eine abgeschlossene Proxy-Verbindung bei totem Tunnel bedeutet meist, dass die Gegenseite den in Ihrem Profil genannten Transport nie angeboten hat.

Notieren Sie Transport und annehmenden Proxy an einem dauerhaften Ort. Wenn dasselbe Profil in einem anderen Netz scheitert, schließt diese Notiz den Proxy in Sekunden aus oder ein.