Wat het Proxy-veld in een Apple VPN-profiel werkelijk doet
Een proxyveld invullen maakt van een VPN geen HTTP. Er zijn twee verbindingen in het spel, en het veld bereikt er maar één van.
Het Proxy-veld in een Apple VPN-configuratie invullen voelt alsof het de tunnel via een webpoort moet omleiden. Dat doet het niet. Het veld kiest een tussenpersoon op applicatieniveau voor verkeer dat een compatibele app daarheen besluit te sturen. De verbinding van de VPN-client zelf met zijn gateway wordt daarentegen bepaald door het protocol, de listener en het transport dat je hebt geconfigureerd, en dat zijn afzonderlijke beslissingen.
Twee verbindingen, twee eigenaren
Elke dergelijke opzet omvat een verbinding van client naar gateway en een van applicatie naar bestemming. Het gedeelte Proxy gaat over de tweede, ook al staat het in hetzelfde profiel als de eerste.
| 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 naslagwerk voor proxyinstellingen noemt HTTP, HTTPS, SOCKS en automatische proxyconfiguratie, wat de proxykeuzes van applicaties beschrijft. Geen van die vermeldingen zegt iets over hoe een IPsec- of WireGuard-pakket een gateway bereikt.
Hier is een snelle controle die de kwestie beslecht. Noem de poort en het protocol die de VPN-client in zijn log meldt. Als die regel nog steeds UDP 500 of UDP 51820 zegt, heeft het proxyveld daar niets aan veranderd.
Wanneer het veld het juiste hulpmiddel is
Er is een echt geval waarin een proxy vóór de tunnel staat, maar dat is een clientfunctie en geen profielveld. De handleiding van OpenVPN documenteert --http-proxy voor TCP-verbindingen die via een HTTP CONNECT-proxy lopen. Gebruik ervan vereist de bijbehorende clientoptie, een gateway die zo bereikbaar is, en een proxy die CONNECT naar de gebruikte poort toestaat.
Als je client die optie biedt en het netwerk CONNECT naar de poort toestaat, kan het werken. Als de client die optie niet biedt, heeft het invullen van een systeemproxy helemaal geen effect op de tunnel.
Wanneer het niets verandert
Een IKEv2- of IPsec-profiel wordt geen HTTP-tunnel omdat het proxyveld is ingevuld. WireGuard ook niet, waarvan het configuratieformaat geen proxyconcept kent. Ook een andere gatewaypoort verandert het protocol niet. En een eindpunt dat gewoon HTTPS beantwoordt, is niet automatisch een VPN-listener.
Dezelfde valstrik vangt mensen die profielen uit het PPTP-tijdperk uit oude iPad-gidsen kopiëren. De opties bestaan nog in de interface; de dienst erachter spreekt dat protocol niet meer.
Bepalen welke laag je moet repareren
Vraag welke laag heeft gefaald voordat je iets verandert. Als de client geen sessie kan opzetten, is het transport het probleem en doet het proxyveld er niet toe. Als de tunnel actief is maar één app zijn server niet bereikt, is het de moeite waard de applicatieproxy te bekijken. Als de tunnel actief is en alle apps falen, zijn routing en DNS binnen de tunnel de verdachten.
Vraag in het eerste geval de operator welk goedgekeurd alternatief transport of netwerk hij ondersteunt. OpenVPN over TCP 443 bestaat omdat sommige netwerken alleen dat toestaan, en het vereist nog steeds dat de server erop luistert.
Beschouw een geblokkeerde UDP-poort niet als toestemming om te improviseren. Houd de certificaat- of identiteitscontroles van de gateway intact in plaats van ze uit te schakelen om een handshake te laten passen.
Bevestig de twee lagen één voor één
Bevestig eerst de tunnel: controleer op de statuspagina van de client een opgezette sessie en een byteaantal dat niet nul is. Lees daarna de proxyinstelling rechtstreeks, met scutil --proxy voor de effectieve configuratie of networksetup -getwebproxy Wi-Fi voor de opgeslagen waarde. Test vervolgens één app die de systeemproxy respecteert en één die die negeert, want veel native apps negeren hem.
Drie resultaten, drie verschillende correcties.
Als beide lagen succes melden en de app faalt nog steeds, kijk dan naar split tunneling, DNS en de eigen netwerkinstellingen van de app. Dat is een derde laag, en ook die is niet het proxyveld.