Hva Proxy-feltet i en Apple VPN-profil faktisk gjør
Å fylle ut et proxyfelt gjør ikke en VPN om til HTTP. Det er to forbindelser involvert, og feltet når bare én av dem.
Å fylle ut Proxy-feltet i en Apple VPN-konfigurasjon føles som om det skal rute tunnelen gjennom en webport. Det gjør det ikke. Feltet velger en mellommann på applikasjonsnivå for trafikk som en kompatibel app velger å sende dit. Selve VPN-klientens forbindelse til gatewayen styres derimot av protokollen, lytteren og transporten du konfigurerte, og det er separate beslutninger.
To forbindelser, to eiere
Ethvert slikt oppsett innebærer en forbindelse fra klient til gateway og en fra applikasjon til destinasjon. Proxy-delen handler om den andre, selv om den 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 referanse for proxyinnstillinger lister opp HTTP, HTTPS, SOCKS og automatisk proxykonfigurasjon, som beskriver applikasjonenes proxyvalg. Ingen av disse oppføringene sier noe om hvordan en IPsec- eller WireGuard-pakke når en gateway.
Her er en rask sjekk som avgjør saken. Nevn porten og protokollen VPN-klienten rapporterer i loggen sin. Hvis linjen fortsatt sier UDP 500 eller UDP 51820, endret proxyfeltet ingenting ved den.
Når feltet er det riktige verktøyet
Det finnes et reelt tilfelle der en proxy står foran tunnelen, men det er en klientfunksjon og ikke et profilfelt. OpenVPN-håndboken dokumenterer --http-proxy for TCP-forbindelser som føres gjennom en HTTP CONNECT-proxy. Bruk krever det samsvarende klientvalget, en gateway som kan nås den veien, og en proxy som tillater CONNECT til porten som brukes.
Hvis klienten din tilbyr det valget og nettverket tillater CONNECT til porten, kan det fungere. Hvis klienten ikke tilbyr det, har utfylling av en systemproxy ingen effekt på tunnelen i det hele tatt.
Når det ikke endrer noe
En IKEv2- eller IPsec-profil blir ikke en HTTP-tunnel fordi proxyfeltet er fylt ut. Det gjør WireGuard heller ikke, hvis konfigurasjonsformat ikke har noe proxybegrep. Å endre gatewayporten endrer heller ikke protokollen. Og et endepunkt som svarer på vanlig HTTPS er ikke automatisk en VPN-lytter.
Den samme fellen fanger dem som kopierer PPTP-tidens profiler fra gamle iPad-veiledninger. Valgene finnes fortsatt i grensesnittet; tjenesten bak dem snakker ikke lenger den protokollen.
Bestemme hvilket lag som skal rettes
Spør hvilket lag som feilet før du endrer noe. Hvis klienten ikke kan opprette en sesjon, er transporten problemet, og proxyfeltet er irrelevant. Hvis tunnelen er oppe, men én app ikke når serveren sin, er det verdt å undersøke applikasjonsproxyen. Hvis tunnelen er oppe og alle apper feiler, er ruting og DNS inne i tunnelen de mistenkte.
For det første tilfellet, spør operatøren hvilken godkjent alternativ transport eller nettverk de støtter. OpenVPN over TCP 443 finnes fordi noen nettverk bare tillater det, og det krever fortsatt at serveren lytter på det.
Ikke behandle en blokkert UDP-port som tillatelse til å improvisere. Hold gatewayens sertifikat- eller identitetskontroller intakte i stedet for å slå dem av for å få et håndtrykk til å passe.
Bekreft de to lagene ett om gangen
Bekreft først tunnelen: sjekk klientens statusside for en etablert sesjon og et bytetall som ikke er null. Les deretter proxyinnstillingen direkte, med scutil --proxy for den effektive konfigurasjonen eller networksetup -getwebproxy Wi-Fi for den lagrede verdien. Test så én app som respekterer systemproxyen og én som ignorerer den, fordi mange innebygde apper ignorerer den.
Tre resultater, tre forskjellige rettelser.
Hvis begge lagene rapporterer suksess og appen fortsatt feiler, se på delt tunellering, DNS og appens egne nettverksinnstillinger. Det er et tredje lag, og det er heller ikke proxyfeltet.