Que fai realmente o campo Proxy dun perfil VPN de Apple
Encher un campo de proxy non converte unha VPN en HTTP. Hai dúas conexións implicadas e o campo só chega a unha delas.
Encher o campo Proxy dunha configuración VPN de Apple parece que debería redirixir o túnel por un porto web. Non o fai. O campo escolle un intermediario a nivel de aplicación para o tráfico que unha aplicación compatible decide enviar alí. Pola contra, a conexión do propio cliente VPN coa súa pasarela gobérnana o protocolo, o oínte e o transporte que configurases, e esas son decisións distintas.
Dúas conexións, dous propietarios
Calquera configuración así implica unha conexión do cliente á pasarela e outra da aplicación ao destino. A sección Proxy fala da segunda, aínda que estea no mesmo perfil que a primeira.
| 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 |
A referencia de axustes de proxy de Apple enumera HTTP, HTTPS, SOCKS e a configuración automática de proxy, que describe as opcións de proxy das aplicacións. Ningunha desas entradas di nada sobre como chega un paquete IPsec ou WireGuard a unha pasarela.
Aquí tes unha comprobación rápida que o resolve. Di o porto e o protocolo que o cliente VPN indica no seu rexistro. Se esa liña segue dicindo UDP 500 ou UDP 51820, o campo de proxy non cambiou nada nela.
Cando o campo é a ferramenta correcta
Hai un caso real no que un proxy se sitúa diante do túnel, pero é unha función do cliente e non un campo do perfil. O manual de OpenVPN documenta --http-proxy para conexións TCP transportadas por un proxy HTTP CONNECT. Usalo require a opción correspondente do cliente, unha pasarela accesible por esa vía e un proxy que permita CONNECT ao porto en uso.
Se o teu cliente expón esa opción e a rede permite CONNECT ao porto, pode funcionar. Se o cliente non a expón, encher un proxy do sistema non ten ningún efecto sobre o túnel.
Cando non cambia nada
Un perfil IKEv2 ou IPsec non se converte nun túnel HTTP porque o campo de proxy estea cheo. WireGuard tampouco, xa que o seu formato de configuración non ten o concepto de proxy. Cambiar o porto da pasarela tampouco cambia o seu protocolo. E un extremo que responde a HTTPS normal non é automaticamente un oínte de VPN.
A mesma trampa atrapa a quen copia perfís da era PPTP de guías antigas de iPad. As opcións seguen existindo na interface; o servizo que hai detrás xa non fala ese protocolo.
Decidir que capa hai que arranxar
Pregunta que capa fallou antes de cambiar nada. Se o cliente non pode establecer unha sesión, o problema é o transporte e o campo de proxy é irrelevante. Se o túnel está activo pero unha aplicación non chega ao seu servidor, paga a pena inspeccionar o proxy da aplicación. Se o túnel está activo e todas as aplicacións fallan, os sospeitosos son o encamiñamento e o DNS dentro do túnel.
Para o primeiro caso, pregunta ao operador que transporte ou rede alternativa aprobada admite. OpenVPN sobre TCP 443 existe porque algunhas redes só permiten iso, e segue esixindo que o servidor o escoite.
Non tomes un porto UDP bloqueado como permiso para improvisar. Mantén intactas as comprobacións de certificado ou de identidade da pasarela en lugar de desactivalas para que encaixe o handshake.
Confirma as dúas capas unha de cada vez
Confirma primeiro o túnel: mira a páxina de estado do cliente para ver unha sesión establecida e un reconto de bytes distinto de cero. Despois consulta o axuste de proxy directamente, con scutil --proxy para a configuración efectiva ou networksetup -getwebproxy Wi-Fi para o valor gardado. Logo proba unha aplicación que respecte o proxy do sistema e outra que o ignore, porque moitas aplicacións nativas ignórano.
Tres resultados, tres correccións distintas.
Se ambas as capas informan de éxito e a aplicación segue fallando, revisa o túnel dividido, o DNS e os axustes de rede propios da aplicación. Esa é unha terceira capa, e tampouco é o campo de proxy.