Ce face de fapt câmpul Proxy dintr-un profil VPN Apple
Completarea unui câmp proxy nu transformă un VPN în HTTP. Sunt implicate două conexiuni, iar câmpul ajunge doar la una dintre ele.
Completarea câmpului Proxy dintr-o configurație VPN Apple pare că ar trebui să redirecționeze tunelul printr-un port web. Nu face asta. Câmpul alege un intermediar la nivel de aplicație pentru traficul pe care o aplicație compatibilă decide să îl trimită acolo. În schimb, conexiunea clientului VPN însuși cu gateway-ul său este guvernată de protocolul, de listenerul și de transportul pe care le-ați configurat, iar acestea sunt decizii separate.
Două conexiuni, doi proprietari
Orice astfel de configurare implică o conexiune de la client la gateway și una de la aplicație la destinație. Secțiunea Proxy vorbește despre a doua, deși se află în același profil ca prima.
| 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 |
Referința Apple pentru setările de proxy listează HTTP, HTTPS, SOCKS și configurarea automată a proxy-ului, ceea ce descrie opțiunile de proxy ale aplicațiilor. Niciuna dintre aceste intrări nu spune cum ajunge un pachet IPsec sau WireGuard la un gateway.
Iată o verificare rapidă care lămurește problema. Spuneți portul și protocolul pe care clientul VPN le raportează în jurnal. Dacă acea linie încă spune UDP 500 sau UDP 51820, câmpul proxy nu a schimbat nimic acolo.
Când câmpul este instrumentul potrivit
Există un caz real în care un proxy stă în fața tunelului, dar este o funcție a clientului, nu un câmp de profil. Manualul OpenVPN documentează --http-proxy pentru conexiunile TCP transportate printr-un proxy HTTP CONNECT. Folosirea lui necesită opțiunea corespunzătoare din client, un gateway accesibil pe acea cale și un proxy care permite CONNECT către portul folosit.
Dacă clientul dumneavoastră expune această opțiune și rețeaua permite CONNECT către port, poate funcționa. Dacă clientul nu o expune, completarea unui proxy de sistem nu are niciun efect asupra tunelului.
Când nu schimbă nimic
Un profil IKEv2 sau IPsec nu devine tunel HTTP pentru că câmpul proxy este completat. Nici WireGuard, al cărui format de configurare nu are noțiunea de proxy. Schimbarea portului gateway-ului nu îi schimbă nici protocolul. Iar un punct final care răspunde la HTTPS obișnuit nu este automat un listener VPN.
Aceeași capcană îi prinde pe cei care copiază profiluri din epoca PPTP din ghiduri vechi pentru iPad. Opțiunile încă există în interfață; serviciul din spate nu mai vorbește acel protocol.
A decide ce strat trebuie reparat
Întrebați ce strat a eșuat înainte de a schimba ceva. Dacă clientul nu poate stabili o sesiune, problema este transportul, iar câmpul proxy este irelevant. Dacă tunelul este activ, dar o aplicație nu își atinge serverul, merită inspectat proxy-ul aplicației. Dacă tunelul este activ și toate aplicațiile eșuează, suspecții sunt rutarea și DNS-ul din interiorul tunelului.
Pentru primul caz, întrebați operatorul ce transport sau rețea alternativă aprobată acceptă. OpenVPN peste TCP 443 există pentru că unele rețele permit doar asta, și tot cere ca serverul să asculte pe acel port.
Nu tratați un port UDP blocat ca pe o permisiune de a improviza. Păstrați intakte verificările de certificat sau de identitate ale gateway-ului, în loc să le dezactivați ca să se potrivească schimbul de chei.
Confirmați ambele straturi pe rând
Confirmați mai întâi tunelul: verificați în pagina de stare a clientului o sesiune stabilită și un număr de octeți diferit de zero. Apoi citiți setarea de proxy direct, cu scutil --proxy pentru configurația efectivă sau networksetup -getwebproxy Wi-Fi pentru valoarea stocată. Apoi testați o aplicație care respectă proxy-ul de sistem și una care îl ignoră, fiindcă multe aplicații native îl ignoră.
Trei rezultate, trei corecturi diferite.
Dacă ambele straturi raportează succes iar aplicația tot eșuează, uitați-vă la split tunneling, la DNS și la setările de rețea ale aplicației. Acesta este un al treilea strat, și nici el nu este câmpul proxy.