Le VPN fonctionne en Wi-Fi mais pas en données mobiles : pourquoi

Commencez par une comparaison, pas par une conclusion : même téléphone, même profil, deux réseaux. Si le tunnel échoue sur l’un et fonctionne sur l’autre, la différence se situe quelque part sur le chemin et non dans les identifiants. Notez le type d’échec obtenu, car un refus avant la connexion et une connexion qui ne transporte rien sont deux problèmes différents. Tout ce qui suit suppose ce test, réalisé en ne changeant que le réseau.

Un VPN a besoin de la connexion sous-jacente ; il ne la remplace pas et ne peut pas forcer un opérateur à transporter ce que l’opérateur refuse de transporter.

Gardez le téléphone fixe, ne changez que le réseau

Changer le réseau et le serveur en même temps laisse deux causes possibles et aucun moyen de les séparer. Comparez le même point de terminaison d’abord en Wi-Fi, puis en données mobiles, et notez à chaque fois le symptôme exact. Un échec avant l’authentification désigne l’accessibilité, un refus d’identifiants désigne le compte, et un tunnel connecté qui ne transporte rien désigne le routage ou le DNS. Seul le premier concerne vraiment le réseau.

Un refus explicite à la connexion relève aussi des contrôles d’authentification, même s’il n’apparaît que sur un réseau. Certains opérateurs et réseaux invités interceptent le trafic d’une manière qui produit des erreurs trompeuses.

Ce que le réseau d’accès peut voir et facturer

L’opérateur qui transporte le tunnel observe la connexion elle-même : le moment, le volume et l’adresse du point de terminaison du VPN. Chiffrer la charge utile ne cache pas ces propriétés, et cela vaut pour une liaison Wi-Fi domestique autant que pour les données mobiles. Ce qu’un VPN change, c’est qui peut voir quoi, et la réponse diffère à chaque saut. Notez-le saut par saut plutôt que de décrire la connexion comme privée en général.

La facturation est l’autre différence pratique. L’encapsulation, les signaux de maintien et les nouvelles tentatives consomment des octets, et les applications peuvent reprendre un transfert après un transfert de connexion. Il existe aussi du Wi-Fi domestique au forfait, alors vérifiez les compteurs de l’appareil et l’offre plutôt que de supposer que l’un des réseaux est illimité.

Connexions au portail et restrictions de l’opérateur

Un portail captif doit être satisfait avant que le tunnel puisse atteindre quoi que ce soit. Reconnecter le VPN n’admettra pas un appareil que le réseau n’a pas autorisé, et une politique toujours connecté peut rendre le portail inaccessible. Terminez d’abord la connexion via le parcours habituel du navigateur, puis montez le tunnel. Si une politique gérée empêche cet ordre, suivez la procédure documentée de l’opérateur ou de l’administrateur.

Les restrictions de l’opérateur sont l’autre variable : certains chemins ne transportent que certains protocoles, d’autres traduisent les adresses de façon agressive, et d’autres traitent une famille d’adresses différemment de l’autre. La comparaison réduit l’échec au chemin sans identifier quel mécanisme en est responsable.

Le transfert n’est pas la même chose qu’une reconnexion

Une fois que chaque réseau fonctionne seul, observez un vrai transfert. Le client peut détecter le changement et se reconnecter, ou conserver une session désormais morte. Les applications déjà utilisées récupèrent différemment de celles ouvertes après le basculement, donc une icône de tunnel persistante ne prouve pas grand-chose. Testez l’application qui vous importe vraiment pendant la transition et notez si elle récupère sans intervention manuelle.

Si le tunnel n’échoue qu’après une période d’inactivité, un signal de maintien peut traiter un cas d’état NAT. Il ne répare pas un signal faible et ne corrige pas tous les transferts. Distinguez l’inactivité du mouvement avant de modifier des réglages.

Notez le réseau, l’étape de l’échec et le comportement lors d’un transfert. Ces trois éléments séparent un problème de chemin d’un problème de client.