Vad Proxy-fältet i en Apple VPN-profil faktiskt gör
Att fylla i ett proxyfält gör inte en VPN till HTTP. Det finns två anslutningar inblandade, och fältet når bara en av dem.
Att fylla i Proxy-fältet i en Apple VPN-konfiguration känns som om det ska leda om tunneln via en webbport. Det gör det inte. Fältet väljer en mellanhand på applikationsnivå för trafik som en kompatibel app väljer att skicka dit. Själva VPN-klientens anslutning till sin gateway styrs däremot av protokollet, lyssnaren och transporten som du konfigurerade, och det är separata beslut.
Två anslutningar, två ägare
Varje sådan uppsättning omfattar en anslutning från klient till gateway och en från applikation till destination. Proxy-avsnittet handlar om den andra, även om den ligger i samma profil som den första.
| Connection | What decides its behaviour |
|---|---|
| VPN client to VPN gateway | The supported protocol, the listening port, the transport and the network policy in between |
| Application to a selected proxy | The application's own proxy support, the configured proxy policy, and the route to that next hop |
Apples referens för proxyinställningar listar HTTP, HTTPS, SOCKS och automatisk proxykonfiguration, vilket beskriver applikationernas proxyval. Ingen av dessa poster säger något om hur ett IPsec- eller WireGuard-paket når en gateway.
Här är en snabb kontroll som avgör saken. Ange porten och protokollet som VPN-klienten rapporterar i sin logg. Om raden fortfarande säger UDP 500 eller UDP 51820 ändrade proxyfältet ingenting där.
När fältet är rätt verktyg
Det finns ett verkligt fall där en proxy står framför tunneln, men det är en klientfunktion och inte ett profilfält. OpenVPN-handboken dokumenterar --http-proxy för TCP-anslutningar som förs genom en HTTP CONNECT-proxy. Att använda det kräver motsvarande klientalternativ, en gateway som går att nå den vägen och en proxy som tillåter CONNECT till porten som används.
Om din klient erbjuder det alternativet och nätverket tillåter CONNECT till porten kan det fungera. Om klienten inte erbjuder det har ifyllandet av en systemproxy ingen effekt alls på tunneln.
När det inte ändrar något
En IKEv2- eller IPsec-profil blir inte en HTTP-tunnel för att proxyfältet är ifyllt. Inte heller WireGuard, vars konfigurationsformat inte har något proxybegrepp. Att byta gatewayport ändrar inte heller dess protokoll. Och en ändpunkt som svarar på vanlig HTTPS är inte automatiskt en VPN-lyssnare.
Samma fälla fångar dem som kopierar profiler från PPTP-eran ur gamla iPad-guider. Alternativen finns fortfarande i gränssnittet; tjänsten bakom dem talar inte längre det protokollet.
Bestämma vilket lager som ska åtgärdas
Fråga vilket lager som misslyckades innan du ändrar något. Om klienten inte kan upprätta en session är transporten problemet och proxyfältet irrelevant. Om tunneln är uppe men en app inte når sin server är det värt att granska applikationsproxyn. Om tunneln är uppe och alla appar misslyckas är routning och DNS inne i tunneln de misstänkta.
För det första fallet, fråga operatören vilken godkänd alternativ transport eller vilket nätverk som stöds. OpenVPN över TCP 443 finns eftersom vissa nätverk bara tillåter det, och det kräver fortfarande att servern lyssnar på det.
Behandla inte en blockerad UDP-port som tillstånd att improvisera. Behåll gatewayens certifikat- eller identitetskontroller intakta i stället för att stänga av dem för att få en handskakning att passa.
Bekräfta de två lagren ett i taget
Bekräfta först tunneln: kontrollera klientens statussida för en upprättad session och ett bytant som inte är noll. Läs sedan proxyinställningen direkt, med scutil --proxy för den effektiva konfigurationen eller networksetup -getwebproxy Wi-Fi för det sparade värdet. Testa därefter en app som respekterar systemproxyn och en som ignorerar den, eftersom många inbyggda appar ignorerar den.
Tre resultat, tre olika åtgärder.
Om båda lagren rapporterar framgång och appen fortfarande misslyckas, titta på delad tunnling, DNS och appens egna nätverksinställningar. Det är ett tredje lager, och det är inte heller proxyfältet.