Kva Proxy-feltet i ein Apple VPN-profil faktisk gjer
Å fylle ut eit proxyfelt gjer ikkje ein VPN om til HTTP. Det er to tilkoplingar involvert, og feltet når berre éi av dei.
Å fylle ut Proxy-feltet i ein Apple VPN-konfigurasjon kjennest som om det skal rute tunnelen gjennom ein webport. Det gjer det ikkje. Feltet vel ein mellommann på applikasjonsnivå for trafikk som ein kompatibel app vel å sende dit. Sjølve VPN-klienten sin tilkopling til gatewayen sin vert derimot styrt av protokollen, lyttaren og transporten du konfigurerte, og det er separate avgjerder.
To tilkoplingar, to eigarar
Kvart slikt oppsett inneber ei tilkopling frå klient til gateway og éi frå applikasjon til destinasjon. Proxy-delen handlar om den andre, sjølv om han ligg i same 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 |
Apple sin referanse for proxyinnstillingar listar opp HTTP, HTTPS, SOCKS og automatisk proxykonfigurasjon, som skildrar applikasjonane sine proxyval. Ingen av desse oppføringane seier noko om korleis ein IPsec- eller WireGuard-pakke når ein gateway.
Her er ein rask sjekk som avgjer saka. Nemn porten og protokollen VPN-klienten rapporterer i loggen sin. Viss linja framleis seier UDP 500 eller UDP 51820, endra proxyfeltet ingenting ved henne.
Når feltet er det rette verktøyet
Det finst eit reelt tilfelle der ein proxy står framfor tunnelen, men det er ein klientfunksjon og ikkje eit profilfelt. OpenVPN-handboka dokumenterer --http-proxy for TCP-tilkoplingar som vert førte gjennom ein HTTP CONNECT-proxy. Bruk krev det samsvarande klientvalet, ein gateway som kan nåast den vegen, og ein proxy som tillèt CONNECT til porten som vert brukt.
Viss klienten din tilbyr det valet og nettverket tillèt CONNECT til porten, kan det fungere. Viss klienten ikkje tilbyr det, har utfylling av ein systemproxy ingen effekt på tunnelen i det heile.
Når det ikkje endrar noko
Ein IKEv2- eller IPsec-profil vert ikkje ein HTTP-tunnel fordi proxyfeltet er fylt ut. Det gjer WireGuard heller ikkje, der konfigurasjonsformatet ikkje har noko proxyomgrep. Å endre gatewayporten endrar heller ikkje protokollen. Og eit endepunkt som svarar på vanleg HTTPS er ikkje automatisk ein VPN-lyttar.
Den same fella fangar dei som kopierer profilar frå PPTP-tida frå gamle iPad-rettleiarar. Vala finst framleis i grensesnittet; tenesta bak dei snakkar ikkje lenger den protokollen.
Avgjere kva lag som skal rettast
Spør kva lag som feila før du endrar noko. Viss klienten ikkje kan opprette ein sesjon, er transporten problemet, og proxyfeltet er irrelevant. Viss tunnelen er oppe, men ein app når ikkje serveren sin, er det verdt å undersøkje applikasjonsproxien. Viss tunnelen er oppe og alle appane feilar, er ruting og DNS inne i tunnelen dei mistenkte.
For det første tilfellet, spør operatøren kva godkjend alternativ transport eller nettverk dei støttar. OpenVPN over TCP 443 finst fordi nokre nettverk berre tillèt det, og det krev framleis at serveren lyttar på det.
Ikkje handsam ein blokkert UDP-port som løyve til å improvisere. Hald gatewayen sine sertifikat- eller identitetskontrollar intakte i staden for å slå dei av for å få eit handtrykk til å passe.
Stadfest dei to laga eitt om gongen
Stadfest først tunnelen: sjekk statussida til klienten for ein etablert sesjon og eit bytetal som ikkje er null. Les deretter proxyinnstillinga direkte, med scutil --proxy for den effektive konfigurasjonen eller networksetup -getwebproxy Wi-Fi for den lagra verdien. Test så éin app som respekterer systemproxien og éin som ignorerer han, fordi mange innebygde appar ignorerer han.
Tre resultat, tre ulike rettingar.
Viss båe laga rapporterer suksess og appen framleis feilar, sjå på delt tunnelering, DNS og appen sine eigne nettverksinnstillingar. Det er eit tredje lag, og det er heller ikkje proxyfeltet.