Què fa realment el camp Proxy d’un perfil VPN d’Apple

Omplir el camp Proxy d’una configuració VPN d’Apple sembla que hagi de redirigir el túnel per un port web. No ho fa. El camp tria un intermediari a nivell d’aplicació per al trànsit que una aplicació compatible decideix enviar-hi. En canvi, la connexió del client VPN amb la seva passarel·la la determinen el protocol, l’oient i el transport que hàgiu configurat, i són decisions separades.

Dues connexions, dos propietaris

Qualsevol configuració així implica una connexió del client a la passarel·la i una connexió de l’aplicació a la destinació. La secció Proxy parla de la segona, tot i que és al mateix perfil que la primera.

La referència de paràmetres de proxy d’Apple llista HTTP, HTTPS, SOCKS i la configuració automàtica de proxy, que és una descripció de les opcions de proxy de les aplicacions. Cap d’aquestes entrades diu res sobre com un paquet d’IPsec o WireGuard arriba a una passarel·la.

Aquí teniu una comprovació ràpida que ho resol. Digueu el port i el protocol que el client VPN indica al seu registre. Si aquesta línia encara diu UDP 500 o UDP 51820, el camp de proxy no hi ha canviat res.

Quan el camp és l’eina correcta

Hi ha un cas real en què un proxy se situa davant del túnel, però és una funció del client i no un camp del perfil. El manual d’OpenVPN documenta --http-proxy per a connexions TCP transportades per un proxy HTTP CONNECT. Fer-lo servir requereix l’opció corresponent del client, una passarel·la abastable per aquesta via i un proxy que permeti CONNECT al port utilitzat.

Si el vostre client exposa aquesta opció i la xarxa permet CONNECT al port, pot funcionar. Si el client no l’exposa, omplir un proxy del sistema no té cap efecte sobre el túnel.

Quan no canvia res

Un perfil IKEv2 o IPsec no es converteix en un túnel HTTP pel fet que el camp de proxy estigui emplenat. WireGuard tampoc, perquè el seu format de configuració no té el concepte de proxy. Canviar el port de la passarel·la tampoc no en canvia el protocol. I un extrem que respon a HTTPS ordinari no és automàticament un oient de VPN.

La mateixa trampa atrapa qui copia perfils de l’època PPTP de guies antigues d’iPad. Les opcions encara existeixen a la interfície; el servei que hi ha darrere ja no parla aquest protocol.

Decidir quina capa cal arreglar

Pregunteu quina capa ha fallat abans de canviar res. Si el client no pot establir una sessió, el problema és el transport i el camp de proxy no hi té res a veure. Si el túnel està actiu però una aplicació no arriba al seu servidor, val la pena inspeccionar el proxy de l’aplicació. Si el túnel està actiu i totes les aplicacions fallen, els sospitosos són l’encaminament i el DNS dins del túnel.

Per al primer cas, pregunteu a l’operador quin transport o xarxa alternativa aprovada admet. OpenVPN sobre TCP 443 existeix perquè algunes xarxes només ho permeten, i encara requereix que el servidor l’escolti.

No tracteu un port UDP bloquejat com un permís per improvisar. Manteniu intactes les comprovacions de certificat o d’identitat de la passarel·la en lloc de desactivar-les per fer encaixar l’handshake.

Confirmeu les dues capes una a la vegada

Confirmeu primer el túnel: mireu la pàgina d’estat del client per veure si hi ha una sessió establerta i un recompte de bytes diferent de zero. Després llegiu la configuració de proxy directament, amb scutil --proxy per a la configuració efectiva o networksetup -getwebproxy Wi-Fi per al valor desat. Després proveu una aplicació que respecti el proxy del sistema i una que l’ignori, perquè moltes aplicacions natives l’ignoren.

Tres resultats, tres correccions diferents.

Si totes dues capes informen d’èxit i l’aplicació encara falla, mireu l’encaminament dividit, el DNS i la configuració de xarxa pròpia de l’aplicació. Aquesta és una tercera capa, i tampoc no és el camp de proxy.