Was das Proxy-Feld in einem Apple-VPN-Profil tatsächlich bewirkt

Das Proxy-Feld in einer Apple-VPN-Konfiguration auszufüllen fühlt sich an, als müsse es den Tunnel über einen Web-Port umleiten. Das tut es nicht. Das Feld wählt einen Vermittler auf Anwendungsebene für Datenverkehr, den eine kompatible App dorthin senden möchte. Die eigene Verbindung des VPN-Clients zu seinem Gateway bestimmen dagegen das Protokoll, der Listener und der Transport, die Sie konfiguriert haben, und das sind getrennte Entscheidungen.

Zwei Verbindungen, zwei Zuständigkeiten

Jede solche Einrichtung umfasst eine Verbindung vom Client zum Gateway und eine von der Anwendung zum Ziel. Der Abschnitt Proxy betrifft die zweite, obwohl er im selben Profil wie die erste liegt.

Apples Referenz zu Proxy-Einstellungen listet HTTP, HTTPS, SOCKS und automatische Proxy-Konfiguration auf, was die Proxy-Optionen von Anwendungen beschreibt. Keiner dieser Einträge sagt etwas darüber, wie ein IPsec- oder WireGuard-Paket ein Gateway erreicht.

Hier ist eine schnelle Prüfung, die die Frage klärt. Nennen Sie den Port und das Protokoll, die der VPN-Client in seinem Protokoll meldet. Steht dort weiterhin UDP 500 oder UDP 51820, hat das Proxy-Feld daran nichts geändert.

Wann das Feld das richtige Werkzeug ist

Es gibt einen echten Fall, in dem ein Proxy vor dem Tunnel sitzt, aber das ist eine Client-Funktion und kein Profilfeld. Das OpenVPN-Handbuch dokumentiert --http-proxy für TCP-Verbindungen, die über einen HTTP-CONNECT-Proxy laufen. Die Nutzung erfordert die passende Client-Option, ein so erreichbares Gateway und einen Proxy, der CONNECT zum verwendeten Port erlaubt.

Bietet Ihr Client diese Option und erlaubt das Netzwerk CONNECT zum Port, kann es funktionieren. Bietet der Client sie nicht, hat das Ausfüllen eines System-Proxys keinerlei Auswirkung auf den Tunnel.

Wann es nichts ändert

Ein IKEv2- oder IPsec-Profil wird nicht dadurch zu einem HTTP-Tunnel, dass das Proxy-Feld ausgefüllt ist. WireGuard ebenso wenig, dessen Konfigurationsformat kein Proxy-Konzept kennt. Auch ein anderer Gateway-Port ändert sein Protokoll nicht. Und ein Endpunkt, der gewöhnliches HTTPS beantwortet, ist nicht automatisch ein VPN-Listener.

Dieselbe Falle erwischt Leute, die Profile aus der PPTP-Zeit aus alten iPad-Anleitungen kopieren. Die Optionen gibt es in der Oberfläche noch; der Dienst dahinter spricht dieses Protokoll nicht mehr.

Entscheiden, welche Ebene zu reparieren ist

Fragen Sie, welche Ebene versagt hat, bevor Sie etwas ändern. Kann der Client keine Sitzung aufbauen, liegt das Problem beim Transport, und das Proxy-Feld ist unerheblich. Steht der Tunnel, aber eine App erreicht ihren Server nicht, lohnt ein Blick auf den Anwendungs-Proxy. Steht der Tunnel und alle Apps scheitern, sind Routing und DNS im Tunnel die Verdächtigen.

Fragen Sie im ersten Fall den Betreiber, welchen genehmigten alternativen Transport oder welches Netz er unterstützt. OpenVPN über TCP 443 existiert, weil manche Netze nur das zulassen, und es verlangt weiterhin, dass der Server darauf lauscht.

Betrachten Sie einen blockierten UDP-Port nicht als Erlaubnis zum Improvisieren. Lassen Sie Zertifikats- oder Identitätsprüfungen des Gateways intakt, statt sie abzuschalten, damit ein Handshake passt.

Prüfen Sie beide Ebenen nacheinander

Bestätigen Sie zuerst den Tunnel: Prüfen Sie auf der Statusseite des Clients eine aufgebaute Sitzung und einen Byte-Zähler ungleich null. Lesen Sie dann die Proxy-Einstellung direkt, mit scutil --proxy für die wirksame Konfiguration oder networksetup -getwebproxy Wi-Fi für den gespeicherten Wert. Testen Sie danach eine App, die den System-Proxy beachtet, und eine, die ihn ignoriert, denn viele native Apps ignorieren ihn.

Drei Ergebnisse, drei verschiedene Korrekturen.

Melden beide Ebenen Erfolg und die App scheitert weiterhin, prüfen Sie Split-Tunneling, DNS und die eigenen Netzwerkeinstellungen der App. Das ist eine dritte Ebene, und auch sie ist nicht das Proxy-Feld.