Ce que fait réellement le champ Proxy d’un profil VPN Apple
Remplir un champ proxy ne transforme pas un VPN en HTTP. Deux connexions sont en jeu, et le champ n’en atteint qu’une.
Remplir le champ Proxy d’une configuration VPN Apple donne l’impression que le tunnel devrait passer par un port web. Ce n’est pas le cas. Le champ choisit un intermédiaire de niveau applicatif pour le trafic qu’une application compatible décide d’y envoyer. La connexion du client VPN lui-même à sa passerelle, elle, dépend du protocole, de l’écouteur et du transport que vous avez configurés, et ce sont des décisions distinctes.
Deux connexions, deux responsables
Toute configuration de ce type comporte une connexion du client vers la passerelle et une connexion de l’application vers la destination. La section Proxy concerne la seconde, même si elle figure dans le même profil que la première.
| 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 |
La référence des réglages de proxy d’Apple liste HTTP, HTTPS, SOCKS et la configuration automatique de proxy, ce qui décrit les choix de proxy des applications. Aucune de ces entrées ne dit comment un paquet IPsec ou WireGuard atteint une passerelle.
Voici une vérification rapide qui tranche. Nommez le port et le protocole que le client VPN indique dans son journal. Si cette ligne dit toujours UDP 500 ou UDP 51820, le champ proxy n’y a rien changé.
Quand le champ est le bon outil
Il existe un cas réel où un proxy se place devant le tunnel, mais c’est une fonction du client, pas un champ du profil. Le manuel d’OpenVPN documente --http-proxy pour les connexions TCP transportées par un proxy HTTP CONNECT. L’utiliser exige l’option client correspondante, une passerelle joignable ainsi et un proxy qui autorise CONNECT vers le port utilisé.
Si votre client expose cette option et que le réseau autorise CONNECT vers le port, cela peut fonctionner. Si le client ne l’expose pas, remplir un proxy système n’a aucun effet sur le tunnel.
Quand cela ne change rien
Un profil IKEv2 ou IPsec ne devient pas un tunnel HTTP parce que le champ proxy est rempli. WireGuard non plus, dont le format de configuration ignore la notion de proxy. Changer le port de la passerelle ne change pas non plus son protocole. Et un point de terminaison qui répond à un HTTPS ordinaire n’est pas automatiquement un écouteur VPN.
Le même piège attrape ceux qui copient des profils de l’époque PPTP dans de vieux guides iPad. Les options existent toujours dans l’interface ; le service derrière ne parle plus ce protocole.
Décider quelle couche corriger
Demandez quelle couche a échoué avant de changer quoi que ce soit. Si le client ne peut pas établir de session, le transport est en cause et le champ proxy est sans objet. Si le tunnel est actif mais qu’une application n’atteint pas son serveur, le proxy applicatif mérite un examen. Si le tunnel est actif et que toutes les applications échouent, le routage et le DNS à l’intérieur du tunnel sont suspects.
Pour le premier cas, demandez à l’opérateur quel transport ou réseau alternatif approuvé il prend en charge. OpenVPN sur TCP 443 existe parce que certains réseaux n’autorisent que cela, et il exige encore que le serveur l’écoute.
Ne prenez pas un port UDP bloqué pour une autorisation d’improviser. Gardez intactes les vérifications de certificat ou d’identité de la passerelle au lieu de les désactiver pour faire passer une poignée de main.
Confirmez les deux couches une par une
Confirmez d’abord le tunnel : vérifiez sur la page d’état du client qu’une session est établie et que le compteur d’octets n’est pas nul. Puis lisez le réglage de proxy directement, avec scutil --proxy pour la configuration effective ou networksetup -getwebproxy Wi-Fi pour la valeur enregistrée. Testez ensuite une application qui respecte le proxy système et une qui l’ignore, car beaucoup d’applications natives l’ignorent.
Trois résultats, trois corrections différentes.
Si les deux couches signalent un succès et que l’application échoue encore, examinez le tunnel divisé, le DNS et les réglages réseau propres à l’application. C’est une troisième couche, et ce n’est pas non plus le champ proxy.