L’icône VPN active dans la barre d’état ne garantit pas que l’intégralité du trafic transite par le tunnel chiffré. Sur iOS avec une configuration Always-On IKEv2 imposée par une organisation, le routage complet est théoriquement assuré, mais une application VPN grand public peut laisser échapper des paquets hors tunnel sans que l’interface ne signale quoi que ce soit. La seule vérification fiable passe par un contrôle de l’adresse IP visible depuis Internet, complété par des tests DNS et WebRTC.
Fuite IPv6 : le test que la plupart des vérifications VPN ignorent
Un VPN peut parfaitement masquer l’adresse IPv4 tout en laissant filtrer l’adresse IPv6 réelle de l’appareil. Ce cas de figure est fréquent chez les fournisseurs qui n’ont pas implémenté le double stack ou qui se contentent de désactiver IPv6 côté client sans bloquer les requêtes sortantes.
A lire également : Quel type de moniteur est le meilleur pour travailler à domicile
Pour tester, connectez-vous à votre VPN puis ouvrez un site de test IPv6 dédié (test-ipv6.com, par exemple). Si le résultat affiche une adresse IPv6 publique qui correspond à votre FAI, le tunnel ne couvre pas ce protocole. Deux approches existent côté fournisseur : le routage IPv6 complet dans le tunnel ou le blocage des connexions IPv6 au niveau de l’interface réseau.
Désactiver IPv6 manuellement dans les paramètres de l’OS reste un contournement, pas une solution pérenne. Un fournisseur VPN sérieux prend en charge IPv6 nativement.
A voir aussi : Quel est le meilleur outil de traduction ?
Vérifier l’adresse IP et les requêtes DNS après connexion VPN
La méthode de base consiste à relever votre adresse IP avant et après activation du VPN. N’importe quel service web affichant l’IP publique convient. Si l’adresse change et pointe vers le pays du serveur VPN sélectionné, le tunnel IP fonctionne.
Ce contrôle ne suffit pas. Les requêtes DNS peuvent emprunter un chemin différent du tunnel, notamment si le système utilise les serveurs DNS du FAI plutôt que ceux du fournisseur VPN. Un test de fuite DNS révèle quels serveurs résolvent vos noms de domaine. Si les serveurs affichés appartiennent à votre fournisseur d’accès alors que le VPN est actif, le DNS fuit.
Corriger une fuite DNS
La plupart des clients VPN proposent une option « DNS privé » ou « Protection contre les fuites DNS » dans leurs réglages. Vérifiez qu’elle est activée. Sur un appareil configuré manuellement (WireGuard, OpenVPN), il faut forcer les serveurs DNS du fournisseur VPN dans le fichier de configuration ou dans les paramètres réseau de l’OS.
Nous recommandons de relancer le test DNS après chaque changement de serveur VPN, car certaines implémentations ne réinitialisent pas correctement le cache DNS lors d’un switch.
Fuite WebRTC : un risque propre au navigateur web
WebRTC permet aux navigateurs d’établir des connexions pair-à-pair pour la voix et la vidéo. Le problème : WebRTC peut révéler l’IP locale et publique réelle, même avec un VPN actif, parce que les requêtes STUN contournent le tunnel.
Pour tester, ouvrez un outil de détection de fuite WebRTC dans votre navigateur pendant que le VPN est connecté. Si votre IP réelle apparaît dans les résultats, le navigateur expose votre connexion.
- Sur Firefox, désactivez WebRTC via media.peerconnection.enabled dans about:config (valeur à passer sur false).
- Sur Chrome et les navigateurs Chromium, une extension dédiée bloque les requêtes STUN, car le réglage natif n’existe pas.
- Sur Safari, le risque est moindre depuis les versions récentes qui restreignent WebRTC aux contextes HTTPS, mais un test reste utile.
Tester le kill switch par une coupure réseau forcée
Activer le kill switch dans les réglages ne prouve rien en soi. Un kill switch doit être testé par une interruption réelle du tunnel. La procédure : connectez-vous au VPN, ouvrez une page de test IP en rafraîchissement automatique, puis forcez la coupure du VPN (arrêt brutal de l’application, bascule Wi-Fi vers données mobiles, déconnexion du réseau).
Si la page continue de charger et affiche votre IP FAI, le kill switch ne bloque pas le trafic hors tunnel. Ce comportement signifie que pendant la reconnexion, toutes vos requêtes transitent en clair.
Différence entre kill switch applicatif et système
Un kill switch applicatif coupe uniquement les connexions de certaines applications quand le VPN tombe. Un kill switch système (parfois appelé « network lock ») bloque toute sortie réseau au niveau de l’interface. Le second offre une protection réelle, le premier laisse le navigateur ou d’autres processus communiquer sans tunnel pendant la coupure.
Checklist rapide pour valider une connexion VPN
Voici la séquence de contrôles à enchaîner après chaque connexion à un serveur VPN :
- Vérifiez que l’adresse IPv4 affichée correspond au serveur VPN choisi, pas à votre FAI.
- Lancez un test IPv6 pour confirmer que cette adresse est masquée ou bloquée par le tunnel.
- Exécutez un test de fuite DNS et vérifiez que les serveurs listés appartiennent au fournisseur VPN.
- Ouvrez un test WebRTC dans chaque navigateur utilisé pour détecter une éventuelle exposition de l’IP réelle.
- Provoquez une coupure du VPN et confirmez que le kill switch interrompt tout trafic sortant.
Aucun de ces tests ne prend plus de quelques minutes. L’ensemble couvre les trois vecteurs de fuite principaux (IP, DNS, WebRTC) et valide le comportement du client en cas de rupture du tunnel. Un seul test positif sur cinq suffit à considérer que la connexion VPN ne protège pas correctement le trafic.
