Homme vérifiant sa connexion VPN sur son ordinateur portable dans un bureau à domicile minimaliste

Comment puis-je vérifier si je suis sur un VPN ?

L’icône VPN affichée dans la barre d’état de votre appareil ne prouve rien. Un tunnel peut être établi sans acheminer la totalité du trafic IP, selon le profil de configuration et la politique de routage appliquée. Sur les appareils Apple par exemple, un profil IKEv2 « toujours actif » peut laisser passer certaines connexions hors tunnel si le profil déclaratif ne couvre pas tous les flux.

Nous recommandons de ne jamais se fier à un indicateur visuel pour valider la protection effective d’un VPN.

Lire également : Faut-il utiliser un VPN en 2026 ?

Fuite IPv6 et split tunneling : les angles morts du diagnostic VPN

La majorité des guides de vérification VPN se concentrent sur l’adresse IPv4. C’est insuffisant. Votre appareil peut exposer son adresse IPv6 réelle si le fournisseur VPN ne gère pas correctement le trafic IPv6, ce qui arrive plus souvent qu’on ne le pense.

Pour vérifier, relevez vos adresses IPv4 et IPv6 avant connexion au VPN, puis après. Si l’IPv6 reste identique, le tunnel ne couvre pas ce protocole. Vous naviguez alors partiellement à découvert.

A découvrir également : Comment savoir si un texte vient d'un IA ?

Le split tunneling aggrave ce problème. Certains VPN, par défaut ou par configuration utilisateur, n’acheminent qu’une partie du trafic dans le tunnel. Des applications comme le client mail ou les services de streaming peuvent contourner le VPN sans notification. Nous observons régulièrement ce comportement sur des configurations Android et Windows où le split tunneling est activé par défaut dans l’application VPN.

Femme consultant les paramètres réseau sur son smartphone pour vérifier une connexion VPN dans un café

DNS over HTTPS : quand le navigateur contourne le tunnel VPN

Même avec un VPN connecté et fonctionnel, vos requêtes DNS peuvent emprunter un chemin totalement différent. C’est le cas lorsque votre navigateur utilise son propre résolveur DNS over HTTPS (DoH), indépendamment des paramètres DNS imposés par le VPN.

Firefox active DoH par défaut dans certaines régions et achemine les requêtes vers Cloudflare. Chrome propose une option similaire. Dans les deux cas, le résolveur DNS du VPN est ignoré. Vos requêtes de résolution de noms de domaine transitent en clair vers un serveur tiers, révélant les sites que vous consultez.

Identifier le résolveur DNS effectivement utilisé

Un test de fuite DNS classique ne suffit pas toujours. Il faut distinguer le résolveur système du résolveur navigateur. Voici une méthode fiable :

  • Lancez un test de fuite DNS depuis votre navigateur principal (pas depuis un outil système) pour capturer le résolveur réellement sollicité par vos requêtes web
  • Comparez le résultat avec les serveurs DNS de votre fournisseur VPN : si le résolveur affiché est celui de Cloudflare, Google ou de votre FAI, le navigateur contourne le tunnel
  • Désactivez DoH dans les paramètres réseau du navigateur, puis relancez le test pour confirmer que les requêtes passent bien par le VPN
  • Vérifiez également depuis un second navigateur, car chaque navigateur peut avoir sa propre configuration DoH

Ce diagnostic prend quelques minutes mais révèle un angle mort que la plupart des tests VPN automatisés ne couvrent pas.

Test de fuite WebRTC : pourquoi le navigateur trahit votre IP

Le protocole WebRTC est intégré nativement dans Chrome, Firefox, Edge et la plupart des navigateurs modernes. Il permet la communication en temps réel (visioconférence, partage de fichiers peer-to-peer) mais expose les adresses IP locales et publiques de l’appareil, y compris derrière un VPN.

Une fuite WebRTC se produit quand le navigateur répond à une requête STUN avec votre adresse IP réelle au lieu de celle attribuée par le VPN. Ce comportement est indépendant du tunnel : le VPN peut fonctionner parfaitement pour le trafic HTTP tout en laissant WebRTC divulguer votre localisation.

Neutraliser WebRTC selon le navigateur

Sur Firefox, la désactivation passe par about:config en basculant media.peerconnection.enabled sur false. Sur Chrome, il n’existe pas de réglage natif équivalent : une extension dédiée est nécessaire. Sur Safari, WebRTC est désactivable via les préférences développeur.

Nous recommandons de tester la fuite WebRTC après chaque mise à jour du navigateur. Les mises à jour réinitialisent parfois les paramètres de confidentialité sans prévenir.

Homme vérifiant l'état de son VPN sur un double écran dans un salon moderne avec vue urbaine

Kill switch VPN : tester une coupure réelle, pas un voyant vert

Activer le kill switch dans les paramètres de votre application VPN ne démontre pas qu’il fonctionne. La seule vérification probante consiste à provoquer une interruption contrôlée du tunnel et observer le comportement de l’appareil.

La méthode : connectez-vous au VPN, ouvrez une page de test d’adresse IP en rafraîchissement automatique, puis forcez la déconnexion du serveur VPN (en coupant le Wi-Fi brièvement ou en tuant le processus VPN). Si la page continue de charger et affiche l’adresse IP de votre fournisseur d’accès, le kill switch ne remplit pas son rôle.

Différence entre kill switch applicatif et système

Un kill switch applicatif ne coupe que le trafic de l’application VPN elle-même. Un kill switch système bloque tout le trafic réseau de l’appareil tant que le tunnel n’est pas rétabli. La distinction est capitale :

  • Un kill switch applicatif laisse passer le trafic des autres applications pendant la coupure du tunnel
  • Un kill switch système (firewall-level) empêche toute fuite, mais peut bloquer des services critiques si le VPN met du temps à se reconnecter
  • Sur mobile, le kill switch système dépend des capacités de l’OS : Android propose un VPN « toujours actif » avec blocage des connexions sans VPN dans les paramètres natifs

Vérifiez dans les paramètres avancés de votre client VPN quel type de kill switch est implémenté. Un simple libellé « kill switch activé » ne donne aucune indication sur le niveau de protection réel.

Détection du VPN par les sites web

Même si votre VPN ne présente aucune fuite, certains sites détectent et bloquent les connexions VPN. Les méthodes employées vont du blocage d’IP connues (les plages d’adresses des datacenters sont cataloguées) à l’analyse comportementale : décalage entre le fuseau horaire du navigateur et la géolocalisation IP, empreinte de navigateur atypique, ou nombre anormal de connexions depuis une même adresse.

Ces détections ne signifient pas que votre VPN dysfonctionne. Elles indiquent que le site identifie votre trafic comme provenant d’un serveur VPN, ce qui est différent d’une fuite de données personnelles. Un VPN détecté n’est pas un VPN compromis.

La vérification complète d’un VPN ne se limite pas à un test unique. Elle combine la comparaison des adresses IPv4 et IPv6, l’audit du résolveur DNS réel du navigateur, le test WebRTC et une coupure volontaire pour valider le kill switch. Chaque couche couvre un vecteur de fuite distinct, et aucune ne compense l’absence d’une autre.

Publications similaires