Vérifiez IPv4 et IPv6 quand vous contrôlez votre VPN

Une page d’adresse publique peut afficher une autre adresse IPv4 après la connexion au VPN tout en laissant une question importante ouverte : que se passe-t-il lorsqu’une application utilise IPv6 ? Beaucoup de connexions courantes disposent de plusieurs familles d’adresses, tandis que certains réseaux n’en offrent qu’une. Une vérification utile examine les possibilités disponibles et le fonctionnement prévu de la configuration choisie. Le but n’est ni de forcer IPv6 partout ni de le désactiver partout, mais de ne pas confondre une requête réussie avec la description complète de tous les trajets possibles de l’appareil.

Commencer la vérification IPv6 par un résultat attendu

Demandez si le client et la configuration doivent transporter IPv6, le bloquer hors du tunnel ou appliquer une autre organisation documentée. Ce sont des politiques différentes. L’absence de résultat IPv6 peut être normale dans un montage et constituer une panne dans un autre. Sans connaître le comportement prévu, le test se prête mal à l’interprétation.

L’adresse du point de connexion et le trafic dans le tunnel sont également deux notions distinctes. Se connecter au serveur VPN par une adresse IPv4 ne détermine pas à lui seul les familles transportées par le tunnel. De même, une adresse IPv6 du serveur ne prouve pas que toutes les applications utiliseront ensuite IPv6. Cela dépend de la configuration complète et du réseau environnant.

Consultez les consignes du protocole et du client avant de modifier quoi que ce soit. La comparaison VLESS et WireGuard aide à reconnaître le montage testé, mais un nom de protocole ne constitue pas une politique de routage. Notez l’application, sa version, la configuration choisie et les éventuels tunnels fractionnés ou exceptions locales.

Déterminer ce que fournit le réseau ordinaire

Lorsqu’une comparaison non sensible sans VPN convient, déterminez si le réseau sous-jacent fournit IPv4, IPv6 ou les deux. Ne déconnectez pas un tunnel professionnel obligatoire et n’exposez pas d’activité sensible uniquement pour établir une référence. Si la politique l’interdit, signalez cette limite et demandez une méthode approuvée à l’administrateur.

Utilisez un diagnostic qui distingue les familles d’adresses. Une page n’affichant qu’une adresse peut simplement avoir emprunté le premier chemin fonctionnel. La spécification Happy Eyeballs de l’IETF explique comment les applications essaient d’autres adresses ou familles afin de réduire le délai de connexion. Cela améliore l’utilisation, mais une page chargée ne démontre pas nécessairement que les deux chemins fonctionnent.

Rattachez l’observation au réseau réellement utilisé. Un résultat en Wi-Fi domestique ne décrit pas les données mobiles, et un ordinateur connecté en partage de connexion n’est pas forcément équivalent au téléphone qui le fournit. Notez le mode d’accès et l’heure. Si IPv6 est indisponible, n’inventez pas d’adresse et ne qualifiez pas cette absence de fuite simplement pour compléter un tableau.

Répéter les observations avec le tunnel actif

Connectez la configuration voulue et effectuez de nouvelles requêtes depuis le même appareil et la même application. Notez séparément le résultat IPv4 et, si disponible, IPv6. Conservez les échecs comme tels au lieu de les ignorer parce qu’une autre page a chargé. Gardez le même point VPN pendant la comparaison.

Un test dans le navigateur mesure les requêtes du navigateur. Si une autre application importe, utilisez un diagnostic adapté ou demandez-en un au support. Exceptions, proxys système et fonctionnement propre à l’application peuvent modifier la portée. Le guide du statut VPN explique pourquoi l’indicateur connecté est un point de départ, pas la preuve de toutes les connexions suivantes.

Si un résultat semble montrer l’adresse du fournisseur ordinaire là où vous attendiez un trajet protégé, cessez les tâches sensibles avec ce montage jusqu’à vérification de la politique. Gardez l’observation privée et décrivez-la précisément. Ne publiez pas de configuration complète ou de clés avec un test d’adresse. Le support a généralement besoin du client et du comportement attendu avant tout élément d’accès secret.

Interpréter les adresses plus finement que les pays affichés

Un service de recherche peut associer une organisation ou un pays à l’adresse observée. Ces étiquettes apportent du contexte, sans être une mesure définitive de position physique. Les bases peuvent diverger et classer différemment les adresses IPv4 et IPv6 d’un même service.

Pour vérifier le routage, comparez les adresses observées aux attentes du fournisseur pour cette configuration. Traitez le comportement géographique séparément. L’article sur le pays du VPN et la langue du site explique pourquoi la préférence linguistique d’un site ne règle pas la question. Une interface russe ou une recherche en anglais ne remplace pas une vérification des familles d’adresses.

Faites un relevé simple à quatre entrées : IPv4 ordinaire, IPv6 ordinaire, IPv4 dans le tunnel et IPv6 dans le tunnel. Marquez explicitement les éléments indisponibles ou non testés. Ajoutez la politique prévue dessous. Ce format distingue mieux une famille non prise en charge, un trajet direct inattendu et un désaccord de géolocalisation, sans tout résumer à « le VPN est cassé ».

Ne pas réparer le routage en devinant les paramètres

N’ajoutez ou ne retirez pas de routes générales uniquement parce qu’un exemple de forum les contient. La documentation VPN d’Android décrit notamment des routes distinctes couvrant toutes les destinations IPv4 et IPv6. Ces réglages déterminent quels trafics entrent dans l’interface virtuelle ; ce ne sont pas des lignes décoratives à copier sans comprendre le reste.

La même prudence vaut pour les configurations importées manuellement. Modifier le routage peut affecter l’accès au DNS, les services locaux et la reconnexion. Conservez de manière sûre le fichier original fonctionnel et utilisez la configuration prise en charge par le fournisseur pour le client. Ne publiez jamais un fichier pour demander si une seule ligne est correcte.

Si la solution prévue bloque volontairement une famille indisponible, vérifiez ce comportement avec les commandes documentées du client. Désactiver globalement IPv6 sur le système ou le routeur peut affecter d’autres applications et utilisateurs. Ne faites ce changement qu’avec une raison claire et l’autorisation appropriée, pas comme remède universel à un résultat inexpliqué d’un seul site.

Revérifier quand le réseau d’accès change

Le résultat du Wi-Fi d’hier ne garantit pas le même comportement sur le réseau mobile aujourd’hui. Répétez cette petite observation après une mise à jour majeure du client, le remplacement d’une configuration ou un changement du mode d’accès utilisé. Inutile de tester indéfiniment un montage inchangé : concentrez-vous sur les transitions pouvant modifier les chemins disponibles.

Pour un cas non résolu, transmettez à l’aide Lumeraya la version du client, le type de réseau, la politique attendue et les résultats séparés des deux familles. Indiquez si la référence sans VPN était possible. Excluez les clés privées et ne revendiquez pas une panne générale si une seule application a été testée.

Une vérification claire des deux piles se termine par une conclusion limitée : le trajet IPv4 observé correspondait à l’attente, IPv6 aussi ou était volontairement indisponible, et les incertitudes restantes sont précisées. C’est plus utile qu’une adresse unique rassurante, car le résultat reste lié à la configuration réelle et au trafic à protéger.