On ouvre l’application VPN, le bouton passe au vert, le mot « connecté » s’affiche. Tout semble en ordre. Mais ce statut visuel ne garantit pas que l’ensemble du trafic transite réellement par le tunnel chiffré. Vérifier si on est sous VPN demande quelques manipulations concrètes, directement dans le navigateur et les paramètres système qu’on utilise au quotidien.
Extension VPN de navigateur ou application système : deux niveaux de protection distincts
Avant même de lancer un test, il faut savoir ce qu’on a installé. Une extension VPN dans le navigateur ne protège généralement que le trafic de ce navigateur. Les autres applications de l’appareil (messagerie, client mail, visioconférence) continuent d’envoyer leurs données en clair, sans passer par le tunnel.
A découvrir également : Les alternatives au chargeur filaire séduisent les utilisateurs de smartphones
Une application VPN installée au niveau du système, elle, prend en charge l’ensemble du trafic, y compris les flux UDP utilisés par les appels vidéo. Vérifier quel type de VPN est actif change tout le diagnostic.
Sur Android, les réglages proposent deux options utiles : « VPN permanent » et « Bloquer les connexions sans VPN ». Cette combinaison coupe automatiquement l’accès Internet si le tunnel tombe. Sur iOS, macOS et Windows, cette protection dépend davantage de l’application VPN elle-même et de sa fonction kill switch. Les retours varient sur ce point selon les fournisseurs.
A voir aussi : Quelle est la manière la plus durable de stocker des données ?
Test d’adresse IP : la première vérification concrète
La méthode la plus directe consiste à comparer son adresse IP avant et après connexion au VPN. On note l’adresse affichée sur un site comme « whatismyipaddress.com » sans VPN, puis on active la connexion et on recharge la page.
Si l’adresse IP change et correspond au pays du serveur choisi, le VPN route bien le trafic du navigateur. Si l’adresse reste identique, le tunnel ne fonctionne pas pour ce navigateur, même si l’application indique « connecté ».
Ce test a une limite : il ne couvre que le trafic HTTP du navigateur utilisé. Pour les autres applications, on doit passer par des vérifications complémentaires.
Fuites DNS : quand les requêtes échappent au tunnel VPN
Chaque fois qu’on tape une adresse web, le navigateur envoie une requête DNS pour la traduire en adresse IP. Normalement, le VPN redirige ces requêtes vers ses propres serveurs DNS. En cas de fuite DNS, elles partent vers les serveurs du fournisseur d’accès Internet, qui peut alors voir les sites visités.
Pour tester, on utilise un outil de test de fuite DNS en ligne. On lance le test étendu et on examine la liste des serveurs DNS qui répondent.
- Si les serveurs affichés appartiennent au fournisseur VPN ou à un pays cohérent avec le serveur choisi, pas de fuite
- Si les serveurs DNS correspondent à ceux du fournisseur d’accès habituel, le VPN ne protège pas les requêtes DNS
- Si des serveurs inconnus apparaissent en plus de ceux du VPN, un split tunneling mal configuré peut en être la cause
Fuite WebRTC : le piège de la visioconférence et des appels navigateur
WebRTC est un protocole intégré à la plupart des navigateurs pour la communication en temps réel (appels vidéo, partage d’écran). Le problème : WebRTC peut exposer l’adresse IP locale et publique par un chemin réseau séparé du tunnel VPN.
Concrètement, un site peut afficher l’adresse IP du serveur VPN lors d’un test classique, tout en récupérant la vraie adresse IP via WebRTC. Les appels en visioconférence constituent un cas de fuite distinct du simple chargement de pages.
Pour vérifier, on accède à un outil de test WebRTC dans le navigateur qu’on utilise réellement au quotidien. Les résultats peuvent varier d’un navigateur à l’autre, selon les extensions installées et la configuration IPv6.
- Sur Firefox, on peut désactiver WebRTC dans les paramètres avancés (about:config, clé « media.peerconnection.enabled » passée à false)
- Sur Chrome et les navigateurs Chromium, il faut une extension dédiée ou un réglage dans l’application VPN elle-même
- Sur les navigateurs mobiles, les options de désactivation WebRTC sont souvent limitées, voire absentes
Répéter le test après chaque changement de réseau
Un test réalisé une seule fois sur le Wi-Fi domestique ne vaut pas validation définitive. Changer de réseau (Wi-Fi public, partage de connexion, réseau d’entreprise) peut modifier le comportement du VPN. Certains réseaux bloquent les protocoles VPN ou forcent un DNS spécifique qui contourne le tunnel.
Le réflexe à prendre : relancer un test d’IP et un test DNS à chaque connexion sur un nouveau réseau. C’est aussi valable après une mise à jour de l’application VPN ou du système d’exploitation, qui peut réinitialiser certains paramètres.
Un autre point souvent négligé : le test doit être fait dans le navigateur qu’on utilise au quotidien, avec les mêmes extensions actives. Tester dans un navigateur vierge puis naviguer dans un autre avec des extensions qui modifient le trafic ne donne pas un résultat représentatif.
Que vérifier en priorité
Plutôt que de multiplier les tests, on se concentre sur trois points. D’abord, l’adresse IP visible correspond au serveur VPN choisi. Ensuite, les serveurs DNS qui répondent ne sont pas ceux du fournisseur d’accès. Enfin, aucune adresse IP locale n’est exposée via WebRTC dans le navigateur principal.
Si ces trois vérifications passent, le VPN remplit son rôle pour le trafic web courant. Pour les applications hors navigateur, seul un VPN système avec kill switch activé offre une couverture complète. Le bouton vert de l’application reste un indicateur, pas une preuve.
