Hvad Proxy-feltet i en Apple VPN-profil egentlig gør
At udfylde et proxyfelt gør ikke en VPN til HTTP. Der er to forbindelser, og feltet når kun én af dem.
At udfylde Proxy-feltet i en Apple VPN-konfiguration føles som om det skulle omdirigere tunnelen gennem en webport. Det gør det ikke. Feltet vælger en mellemmand på applikationsniveau for trafik, som en kompatibel app vælger at sende dertil. Selve VPN-klientens forbindelse til sin gateway styres af protokollen, lytteren og transporten, du har konfigureret, og det er separate beslutninger.
To forbindelser, to ejere
Enhver opsætning som denne omfatter en forbindelse fra klient til gateway og en fra applikation til destination. Proxy-afsnittet handler om den anden, selv om det ligger i samme profil som den første.
| 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 reference for proxyindstillinger nævner HTTP, HTTPS, SOCKS og automatisk proxykonfiguration, hvilket beskriver applikationernes proxyvalg. Ingen af disse poster siger noget om, hvordan en IPsec- eller WireGuard-pakke når en gateway.
Her er en hurtig kontrol, der afgør sagen. Nævn den port og protokol, som VPN-klienten rapporterer i sin log. Hvis linjen stadig siger UDP 500 eller UDP 51820, ændrede proxyfeltet intet ved den.
Hvornår feltet er det rigtige værktøj
Der findes et reelt tilfælde, hvor en proxy står foran tunnelen, men det er en klientfunktion og ikke et profilfelt. OpenVPN-manualen dokumenterer --http-proxy til TCP-forbindelser, der føres gennem en HTTP CONNECT-proxy. Brug kræver den matchende klientindstilling, en gateway, der kan nås ad den vej, og en proxy, der tillader CONNECT til den anvendte port.
Hvis din klient udbyder den indstilling, og netværket tillader CONNECT til porten, kan det virke. Hvis klienten ikke udbyder den, har udfyldning af en systemproxy slet ingen effekt på tunnelen.
Hvornår det ikke ændrer noget
En IKEv2- eller IPsec-profil bliver ikke en HTTP-tunnel, fordi proxyfeltet er udfyldt. Det gør WireGuard heller ikke, hvis konfigurationsformat ikke har noget proxybegreb. At ændre gatewayporten ændrer heller ikke dens protokol. Og et endepunkt, der svarer på almindelig HTTPS, er ikke automatisk en VPN-lytter.
Den samme fælde fanger folk, der kopierer PPTP-tidens profiler fra gamle iPad-guides. Valgmulighederne findes stadig i grænsefladen; tjenesten bag dem taler ikke længere den protokol.
Beslut, hvilket lag der skal rettes
Spørg, hvilket lag der fejlede, før du ændrer noget. Hvis klienten ikke kan oprette en session, er transporten problemet, og proxyfeltet er irrelevant. Hvis tunnelen er oppe, men en app ikke kan nå sin server, er det værd at undersøge applikationsproxyen. Hvis tunnelen er oppe, og alle apps fejler, er routing og DNS inde i tunnelen de mistænkte.
Spørg i det første tilfælde operatøren, hvilken godkendt alternativ transport eller netværk vedkommende understøtter. OpenVPN over TCP 443 findes, fordi nogle netværk kun tillader det, og det kræver stadig, at serveren lytter efter det.
Behandl ikke en blokeret UDP-port som tilladelse til at improvisere. Behold gatewayens certifikat- eller identitetskontroller intakte i stedet for at slå dem fra for at få et handshake til at passe.
Bekræft de to lag ét ad gangen
Bekræft først tunnelen: tjek klientens statusside for en etableret session og et bytetal, der ikke er nul. Læs derefter proxyindstillingen direkte, med scutil --proxy for den effektive konfiguration eller networksetup -getwebproxy Wi-Fi for den gemte værdi. Test derefter en app, der respekterer systemproxyen, og en, der ignorerer den, fordi mange native apps ignorerer den.
Tre resultater, tre forskellige rettelser.
Hvis begge lag rapporterer succes, og appen stadig fejler, så se på delt tunellering, DNS og appens egne netværksindstillinger. Det er et tredje lag, og det er heller ikke proxyfeltet.