VPN connecté mais l'adresse IP n'a pas changé : pourquoi

Vous vous connectez, le client indique connecté, et le test d'adresse affiche toujours le même numéro qu'avant. L'indicateur n'a rien de défectueux ; quelque chose entre le profil et l'application a maintenu cette requête hors du tunnel. Décidez laquelle de trois choses vous examinez avant de toucher à la moindre configuration : un test qui n'a jamais mesuré l'adresse publique, un tunnel qui ne couvre qu'une partie du trafic, ou un second chemin qui gagne la décision de routage. Chacune a une vérification qui prend moins d'une minute.

Confirmez ce que le test a réellement mesuré

L'adresse affichée dans la boîte de dialogue Wi-Fi ou Ethernet est celle de l'interface de votre propre segment, pas celle qu'un site web voit, elle peut donc rester identique pendant que le tunnel fonctionne parfaitement. L'emplacement est encore un signal distinct : une région de compte enregistrée ou une lecture de géolocalisation autorisée ne bouge pas quand vous changez de sortie, et une connexion qui vous reconnaît déjà non plus.

Utilisez un écho d'adresse publique et interrogez chaque famille séparément, car un résultat de test en double pile masque le cas intéressant :

curl -4 -s https://ifconfig.me
curl -6 -s https://ifconfig.me

Exécutez les deux avant et après la connexion. Si la réponse IPv4 passe à l'adresse de sortie et que la réponse IPv6 ne change pas, vous n'avez pas un tunnel cassé ; vous avez une famille qui voyage en dehors. Si les deux réponses restent identiques, la requête n'a jamais atteint le tunnel et le reste de ce texte s'applique.

Le profil peut ne couvrir qu'une partie du trafic

Un profil en tunnel divisé est la réponse courante, et ce n'est pas un défaut. OpenVPN ne fait tout passer par le tunnel que lorsque redirect-gateway figure parmi les options poussées ; sans lui, le client reçoit une poignée de routes précises et votre route par défaut reste sur la liaison physique. Sous Windows, le même commutateur apparaît comme « Utiliser la passerelle par défaut sur le réseau distant » dans les propriétés IPv4 de l'adaptateur, et le décocher est un choix délibéré qui survit à chaque reconnexion.

La portée par application est la deuxième couche. Le réglage VPN par application d'Android décide quelles applications sont incluses, donc la clé VPN de la barre d'état ne prouve pas que le navigateur est dedans. Une extension de navigateur qui proxifie son propre trafic crée l'image miroir : le navigateur affiche l'adresse de sortie tandis qu'un client de messagerie ou un jeu sur la même machine affiche encore la vôtre. Comparez la même requête dans deux applications. Si l'une change et pas l'autre, vous regardez la portée, pas un tunnel défaillant.

Une famille d'adresses peut encore passer en direct

La plupart des profils VPN ont été écrits pour IPv4, et beaucoup le sont encore. Sur un réseau en double pile, le tunnel prend 10.8.0.x pour IPv4 tandis que la liaison physique conserve une adresse IPv6 globale et une route par défaut, donc un site compatible IPv6 est atteint directement et l'adresse qu'il rapporte est celle de votre fournisseur. C'est une fuite avec un tunnel IPv4 qui fonctionne, et elle est invisible pour un test qui ne parle qu'IPv4.

ip -4 route get 1.1.1.1
ip -6 route get 2606:4700:4700::1111

Lisez l'interface dans chaque réponse. Si la recherche IPv6 nomme votre périphérique Ethernet ou Wi-Fi alors que la recherche IPv4 nomme le tunnel, la politique de cette famille manque plutôt que d'être cassée. Désactiver IPv6 sur tout l'appareil fait disparaître le symptôme et cache la décision ; préférez corriger la couverture du profil ou désactiver la famille sur cette seule connexion, et notez laquelle des deux vous avez choisie.

Un second chemin peut gagner la recherche

Un proxy concurrent, un second client VPN, un adaptateur virtuel d'un conteneur ou d'un outil de bureau à distance, ou une route supplémentaire pour le préfixe exact que vous testez peuvent tous prendre le pas. Une route précise bat toujours une route par défaut, donc un /24 résiduel pour le site que vous mesurez, pointant vers votre passerelle LAN, continue d'envoyer ce trafic hors du tunnel, quelle que soit la santé du tunnel.

Faites un inventaire avant de changer quoi que ce soit, avec des commandes en lecture seule :

route print -4
Get-NetRoute -DestinationPrefix 0.0.0.0/0 | Sort-Object RouteMetric
nmcli connection show --active

Cherchez plus d'une route par défaut avec une métrique plausible, et une route précise couvrant la destination. Dans un navigateur, vérifiez aussi si une extension proxy ou le réglage proxy du système possède la connexion ; une extension peut nommer son propre amont et laisser la sortie du système d'exploitation intacte, ce qui produit une adresse différente dans le navigateur que dans un terminal sur la même machine.

Remesurez avec une requête neuve

Reconnectez-vous, puis répétez la mesure depuis la même application que lors du premier test, car une page en cache ou une connexion réutilisée rapporte l'ancien état. Surveillez le journal ou la vue d'événements du client pendant la connexion : une erreur d'application des routes après l'authentification est une preuve plus forte que n'importe quel indicateur, et elle nomme généralement la route ou l'adaptateur qui a échoué.

Gardez deux résultats distincts. Si l'adresse change mais qu'un site vous refuse encore, le tunnel fonctionne et le site rejette une adresse de centre de données ; c'est un autre problème avec une autre réponse. Si l'adresse ne change jamais, parcourez les quatre questions dans l'ordre : quelle adresse le test a-t-il imprimée, de quelle famille s'agissait-il, quelle application a fait la requête, et quelle route cette requête a-t-elle suivie. La documentation Microsoft sur les décisions de routage VPN explique comment un client Windows choisit entre le tunnel et l'adaptateur physique lorsque les deux ont une route.