VPN ou proxy : ce que chacun couvre et ce qu'il ne couvre pas

Un VPN et un proxy direct changent tous deux l'adresse que voit un site web, et c'est là que s'arrêtent la plupart des comparaisons. La différence qui décide de votre configuration, c'est la couverture : un proxy direct est un intermédiaire que votre application choisit d'utiliser, contrairement au proxy inverse placé devant un site web, tandis qu'un VPN déplace tout ce que le système d'exploitation route vers un tunnel. Le chiffrement, la gestion du DNS et le comportement en cas de panne découlent tous de ce partage. Effectuez ces cinq vérifications dans l'ordre, et la première qui échoue vous dira de quel outil vous avez réellement besoin.

Quelles applications l'intermédiaire couvre-t-il ?

Une extension de proxy de navigateur ne s'applique qu'à ce profil de navigateur. Les clients de messagerie, les gestionnaires de paquets et un second navigateur continuent d'utiliser leurs propres réglages, et certaines applications ignorent totalement les variables de proxy du système. Un VPN couvre ce que la table de routage envoie dans le tunnel, ce qui peut être toutes les applications ou un sous-ensemble en tunnel divisé selon les routes et la stratégie du client.

Testez les applications qui comptent au lieu de généraliser à partir d'un seul chargement de page. curl https://ifconfig.me suit les variables d'environnement de proxy ; une application de bureau peut ne pas le faire. Sous Windows, netsh winhttp show proxy affiche le proxy WinHTTP utilisé par les services, et c'est un réglage différent de celui du navigateur.

Le saut est-il chiffré, et où le TLS se termine-t-il ?

Un protocole de proxy est un point de rencontre, pas une garantie. SOCKS5 relaie le TCP sans le chiffrer, et un proxy HTTP simple transporte la ligne de requête et les en-têtes en clair. HTTPS via un proxy utilise CONNECT, si bien que votre session TLS se termine toujours à la destination, et non au proxy. Le guide MDN des serveurs proxy et du tunneling décrit cette distinction du côté du protocole.

Un VPN chiffre le segment entre votre appareil et son point de terminaison. Au-delà du point de terminaison, les mêmes règles s'appliquent que sur tout autre réseau, ce qui explique pourquoi un tunnel seul ne protège pas une application qui envoie des identifiants en HTTP simple. Aucune des deux conceptions ne masque un compte connecté, un cookie ou une empreinte de navigateur.

curl -v -x http://127.0.0.1:3128 https://example.com/ -o /dev/null
curl -v -x socks5h://127.0.0.1:1080 https://example.com/ -o /dev/null

La sortie détaillée montre si curl a émis CONNECT vers le port 443 ou un GET simple avec une URL complète. Avec socks5h://, le proxy reçoit le nom d'hôte dans la requête SOCKS5 puis relaie un TLS qu'il ne peut pas lire, il voit donc le nom et le nombre d'octets. Via un proxy http://, une URL https:// est un CONNECT, donc ce proxy voit aussi le nom et le volume de la destination, mais pas la requête ni le corps de la réponse.

Quel résolveur voit le nom ?

La résolution de noms peut avoir lieu localement avant que la requête ne parte, ou à distance au niveau du proxy. Avec curl, socks5h:// envoie le nom d'hôte au proxy tandis que socks5:// le résout d'abord localement. Les réglages de proxy du navigateur offrent une option DNS comparable, et les fichiers PAC peuvent router différents hôtes de différentes manières.

Deux protocoles peuvent contourner un proxy sans aucune erreur de configuration. WebRTC recueille des candidats via STUN, et QUIC fait tourner HTTP/3 sur UDP, ce qu'un proxy TCP ne peut pas transporter. Le navigateur reviendra au TCP si l'UDP 443 est bloqué, donc bloquer l'UDP 443 sur le pare-feu de l'hôte (ou sur le routeur pour tout un réseau), et non un indicateur du navigateur, est le moyen fiable de garder HTTP/3 dans le chemin du proxy.

Vérifiez le résolveur du point de vue de la destination, pas de votre portable. Une requête qui arrive avec l'adresse de sortie du proxy mais un nom résolu localement indique quand même au résolveur local quels sites vous visitez.

Que se passe-t-il lorsque l'intermédiaire tombe en panne ?

Un proxy explicite échoue en mode fermé : arrêtez le processus du proxy et le navigateur ou l'application renvoie une erreur de connexion au lieu de passer en direct. Les configurations PAC et WPAD sont celles qui échouent en mode ouvert - si le script ne peut pas être récupéré, le client revient à DIRECT et le site voit de nouveau votre adresse réelle. Un VPN peut échouer en mode ouvert ou fermé selon le client et selon qu'un kill switch ou une règle de pare-feu est actif.

Testez le cas de panne exprès : arrêtez le service de proxy et rechargez ; si vous obtenez une page d'erreur au lieu d'un chargement direct, pointez l'URL PAC vers un hôte injoignable pour voir le repli. Si la page se charge encore par votre route habituelle, le proxy n'offre aucune protection contre sa propre panne, et c'est une propriété que vous devez connaître avant de vous y fier.

L'ordre décide de ce que le site voit. Un proxy dont le trafic sortant passe par le VPN laisse le site voir l'adresse du point de terminaison du VPN ; placez le proxy hors du tunnel (VPN vers un proxy sur un hôte distant) et le site verra à la place l'adresse de sortie de ce proxy. Dans les deux cas, les deux sauts peuvent journaliser des choses différentes.

Cinq vérifications, dans l'ordre

La liste ci-dessous contient toute la décision en un seul endroit. La couverture vient en premier parce qu'elle élimine la plupart des inadéquations : si l'application à couvrir ne respecte pas le réglage, rien plus loin dans la liste ne la sauve.

Confirmez ensuite le résultat avec l'application qui a motivé le changement. Chargez une page dans le navigateur configuré, récupérez la même page avec curl, et comparez l'adresse que chacune rapporte. Si elles divergent, une extension, une règle PAC ou une substitution au niveau de l'application est encore en jeu, et aucun réglage du tunnel n'y remédiera.

Notez ce que vous avez configuré : quelles applications utilisent le proxy, si le DNS est local ou distant, si l'UDP est bloqué et quel est le comportement en cas de panne. Ce petit inventaire est ce qui rend la comparaison suivante possible, car « l'IP a changé » ne vous a jamais dit laquelle de ces cinq vérifications avait réussi.