« Le VPN est connecté » et « tout mon trafic est protégé » sont deux affirmations différentes. Entre les deux se glissent la fenêtre de reconnexion lors des changements de réseau, les requêtes DNS qui sortent du tunnel, le trafic IPv6 non routé, et l'application VPN suspendue par le système. Cette page décrit chacun de ces chemins et la manière de les neutraliser. Elle complète l'approche générale des critères d'évaluation d'un VPN gratuit pour Android : un service peut avoir un chiffrement irréprochable et rester poreux si sa gestion des fuites est négligée, ce qui est fréquent sur les paliers gratuits.
Le kill switch, à deux niveaux
Le terme « kill switch » recouvre deux mécanismes de fiabilité très différente.
Le kill switch applicatif est géré par le client VPN lui-même : quand il détecte que le tunnel est tombé, il coupe l'accès réseau des applications. Son efficacité dépend de trois conditions — l'application doit être en cours d'exécution, elle doit détecter la coupure rapidement, et le système ne doit pas l'avoir suspendue. Sur un palier gratuit, cette fonction est souvent absente, ou présente mais désactivée par défaut, ou dégradée quand l'application passe en arrière-plan.
Le kill switch système est intégré à Android : dans Paramètres → Réseau et Internet → VPN, la roue crantée à côté de l'application donne accès à « VPN permanent » et « Bloquer les connexions sans VPN ». Quand cette seconde option est active, le noyau bloque tout paquet qui ne passe pas par l'interface du VPN — pendant le démarrage du téléphone, pendant une reconnexion, pendant un plantage de l'application, sans dépendre de quoi que ce soit qui tourne en espace utilisateur. C'est la protection la plus solide disponible sur Android, et elle est gratuite. Sa seule condition : l'application VPN doit déclarer prendre en charge le mode permanent ; celles qui ne le font pas grisent l'option.
Sur un appareil où la confidentialité compte, activer « VPN permanent » + « Bloquer les connexions sans VPN » au niveau système est le premier geste, avant même de se fier au kill switch du client. Un client gratuit qui ne prend pas en charge le mode permanent Android part avec un handicap sérieux.
La fenêtre de reconnexion
Un téléphone change de réseau en permanence : on quitte le Wi-Fi de la maison, l'appareil bascule sur les données mobiles ; on entre dans un bâtiment, il rejoint un Wi-Fi ; on se déplace, la cellule 4G change. À chaque bascule, le tunnel doit se rétablir. Sans blocage système, le trafic reprend sur la nouvelle connexion pendant que le tunnel se reconstruit — une fenêtre de quelques secondes à une demi-minute durant laquelle l'adresse IP réelle est exposée aux serveurs contactés.
La durée de cette fenêtre dépend du protocole. WireGuard, sans état au niveau du transport, reprend dès le premier paquet chiffré échangé, souvent en moins d'une seconde. IKEv2 avec MOBIKE migre la session sans renégocier. OpenVPN impose une renégociation TLS complète, plus lente. Ce point est développé dans la page sur les protocoles VPN sur Android. Quel que soit le protocole, le blocage système reste le filet de sécurité qui rend cette fenêtre inoffensive.
Les fuites DNS
Résoudre un nom de domaine en adresse IP passe par une requête DNS. Si le client VPN ne force pas ces requêtes dans le tunnel, elles partent vers le résolveur configuré par le réseau — celui du fournisseur d'accès ou du point Wi-Fi. Résultat : l'adresse IP est masquée, mais la liste des domaines consultés est visible par l'opérateur du réseau, ce qui vide le VPN d'une grande partie de son intérêt.
Un client correct pousse son propre résolveur DNS via l'interface du tunnel et intercepte toutes les requêtes. Sur Android, un facteur complique la situation : le réglage « DNS privé » (DNS-over-TLS, dans Paramètres → Réseau et Internet) opère au niveau système et peut coexister mal avec certains clients VPN — soit le DNS privé court-circuite le résolveur du VPN, soit l'inverse. En cas de doute, régler le DNS privé sur « Automatique » pendant l'usage du VPN et vérifier au test que les requêtes sortent bien par le tunnel.
Les fuites IPv6
Beaucoup de services, en particulier sur les paliers gratuits, ne routent que l'IPv4 dans le tunnel. Or les réseaux mobiles français et une part croissante des accès fixes fournissent nativement de l'IPv6. Si l'appareil a une connectivité IPv6 et que le VPN ne la prend pas en charge, le trafic vers les services accessibles en IPv6 sort hors tunnel, avec l'adresse IPv6 réelle — laquelle identifie l'abonnement aussi sûrement qu'une adresse IPv4.
Un client sérieux gère l'un des deux comportements corrects : router aussi l'IPv6 dans le tunnel, ou désactiver l'IPv6 de l'appareil pendant la connexion pour forcer tout le trafic en IPv4. Un client qui ne fait ni l'un ni l'autre laisse une fuite permanente, invisible sans test explicite.
WebRTC et portails captifs
Dans les navigateurs Android, la technologie WebRTC peut, via une requête à un serveur STUN, révéler des adresses IP locales et parfois publiques indépendamment du proxy du navigateur. Le risque est plus faible que sur ordinateur — pas d'extension à installer, moteur unique — mais il existe pour les usages sensibles ; certains navigateurs mobiles offrent un réglage pour le limiter.
Les portails captifs — hôtels, aéroports, trains — posent un autre problème. Android détecte l'existence du portail par une requête de contrôle de connectivité ; tant que l'authentification n'est pas faite, l'accès complet n'est pas disponible, et le client VPN doit se suspendre le temps de la page de connexion puis reprendre. Cette séquence crée une brève fenêtre pendant laquelle le navigateur communique hors tunnel. Après authentification, il faut vérifier que le VPN s'est bien rétabli avant toute activité sensible.
Pourquoi les paliers gratuits fuient plus souvent
Les fuites décrites ici ne sont pas propres au gratuit, mais elles y sont plus fréquentes pour des raisons de coût d'ingénierie. Prendre en charge correctement l'IPv6, maintenir un résolveur DNS dans le tunnel sur toutes les versions d'Android, gérer proprement les portails captifs et déclarer le mode VPN permanent demandent du développement et des tests continus. Sur une offre payante, cet effort est rentabilisé ; sur un palier gratuit traité comme un coût, il est souvent réduit au minimum. Le kill switch système d'Android compense la plupart de ces lacunes pour ce qui concerne le blocage du trafic hors tunnel, mais il ne corrige pas une fuite DNS qui se produit à l'intérieur d'un tunnel mal configuré côté serveur — d'où l'importance du test.
Tester une connexion en cinq minutes
- Test de base. VPN activé, ouvrir un site de test de fuites depuis le navigateur Android. Vérifier que l'adresse IPv4 affichée est celle du serveur VPN, qu'aucune adresse IPv6 réelle n'apparaît, et que les serveurs DNS listés appartiennent au VPN et non au fournisseur d'accès.
- Test WebRTC. Sur la même page, contrôler la section WebRTC : aucune adresse IP publique réelle ne doit être exposée.
- Test sur les deux réseaux. Refaire le test une fois en Wi-Fi, une fois en données mobiles. Le comportement IPv6 diffère souvent entre les deux.
- Test de coupure. VPN activé, lancer un téléchargement, activer le mode avion cinq secondes puis le désactiver. Pendant la reconnexion, aucune requête ne doit aboutir si le blocage système est actif.
- Test d'arrière-plan. Laisser le téléphone verrouillé une heure, puis consulter l'historique de connexion du client : le tunnel est-il resté actif ? Ce point renvoie au comportement du VPN en arrière-plan.
Ces cinq tests forment le sixième critère de la grille d'évaluation. Un service qui les passe tous, sur les deux types de réseau, offre une étanchéité réelle. Un service qui échoue sur le DNS ou l'IPv6 laisse fuir précisément l'information qu'un VPN est censé cacher — et aucun réglage utilisateur ne corrige une fuite DNS côté serveur.