Pourquoi l’étiquette de pays d’un VPN n’est pas l’adresse de sortie

Vous choisissez un pays, vous vous connectez, et un site web vous accueille dans un autre. L’étiquette de la liste n’a jamais rien promis sur l’adresse depuis laquelle vous sortiriez : c’est un champ que quelqu’un a publié, dérivé par une méthode que vous n’avez pas vue. Traiter ce champ comme une adresse, c’est là que commence la confusion.

Trois choses distinctes portent une valeur de pays, et elles peuvent se contredire sans que personne mente. Les distinguer rend l’écart diagnosticable au lieu de mystérieux.

Trois choses différentes portent une étiquette de pays

La première est le champ propre à l’annuaire, qui peut être déclaré par l’opérateur, déduit d’une base d’adresses ou simplement recopié lors de la création de l’entrée. La seconde est l’adresse elle-même, qui appartient au réseau qui l’annonce, et c’est ce à quoi répond une requête de géolocalisation en utilisant des données de mappage publiées sous la forme décrite par la RFC 8805. La troisième est ce qu’une application décide d’afficher, qui peut venir d’une autre base, d’un réglage de compte ou d’une autorisation accordée sur l’appareil. Seule la seconde est un fait de réseau, et même celle-là est une requête plutôt qu’une observation.

La cohérence entre ces trois serait agréable et n’est exigée nulle part. Un écart est la preuve qu’elles ont été dérivées différemment, rien de plus.

Vérifiez l’adresse, pas le drapeau

La question utile est de quelle adresse publique votre trafic sort réellement. Cela se répond depuis le client, et cela ne dépend d’aucun champ de la liste. Comparez la réponse au préfixe que vous attendiez et à ce qu’une requête de géolocalisation en dit, en gardant les deux résultats séparés dans vos notes. Un écart entre le pays attendu et la requête est une question de routage ou de base de données, tandis qu’un écart entre la requête et l’avis de l’application est de nouveau une question de base de données.

Faites la vérification deux fois si le service a plusieurs sorties dans la région. Un pool peut distribuer des adresses différentes lors de connexions successives, et un échantillon n’en décrit qu’une.

La proximité sur une carte n’est pas la proximité sur le réseau

Un pays proche peut être un chemin plus long qu’un pays lointain, car la route de fibre ne suit pas la frontière. Choisir un nœud pour la latence signifie mesurer la destination qui vous importe plutôt que prendre le drapeau le plus proche. La même logique vaut pour la capacité, puisqu’une sortie peu chargée à deux pays de distance peut battre une sortie saturée à côté. Mesurez d’abord, décidez ensuite, et notez l’heure car les deux chiffres bougent.

La localisation ne dit rien non plus sur la conservation ni sur qui exploite le point de sortie. Cela demande ses propres preuves, qu’une colonne de pays ne peut pas contenir.

Confirmez vous-même l’adresse de sortie

Demandez au client et à un service extérieur à quoi ressemble votre adresse, puis demandez à la table de routage locale comment ce chemin a été choisi. Les commandes ci-dessous font les trois, et la troisième est celle que les gens sautent. Remplacez le nom de l’interface par votre propre périphérique tunnel.

curl -sS https://api.ipify.org; echo
curl -sS --interface tun0 https://api.ipify.org; echo
ip route get 1.1.1.1
ip -6 addr show dev tun0

Les deux premières lignes devraient concorder, et lorsqu’elles ne le font pas, la route que vous croyez avoir n’est pas celle qui porte votre trafic. La requête de route nomme l’interface et l’adresse source que le noyau utiliserait pour une destination, et c’est le mécanisme derrière l’adresse de sortie. La ligne IPv6 compte parce qu’une machine peut tenir un tunnel pour une famille et un chemin direct pour l’autre. Une étiquette de pays ne couvre aucun de ces cas à elle seule.

Écrivez l’adresse observée, l’avis de la base de données et l’affichage de l’application comme trois notes séparées. L’écart suivant que vous rencontrerez sera alors facile à attribuer.