Utiliser ipinfo à la maison : comment localiser une IP dans le CLI à l’aide de la latence

 (blog.globalping.io)
2 points par GN⁺ 2026-02-02 | 1 commentaires | Partager sur WhatsApp
  • La latence permet d’estimer une adresse IP au niveau du pays, de l’État ou de la ville via un outil CLI
  • En s’appuyant sur plus de 3 000 sondes du réseau Globalping, l’outil effectue des mesures de ping et de traceroute pour chaque IP
  • Il compare ensuite la latence par étapes — continent → pays → État → ville — et considère comme emplacement réel la zone présentant la valeur la plus faible
  • Les tests montrent une précision conforme aux résultats d’ipinfo pour des localisations comme la Pologne, la Floride ou Miami
  • Disponible comme outil CLI open source, il montre la pertinence pratique d’une vérification de géolocalisation IP fondée sur la latence

Vue d’ensemble de l’estimation de localisation IP basée sur la latence

  • Un outil CLI a été créé pour interpréter une adresse IP au niveau du pays, d’un État américain et de la ville
  • L’approche s’inspire d’un cas où ipinfo a démontré que des fournisseurs VPN enregistraient de fausses données de localisation
    • ipinfo a mis en place un vaste réseau de sondes pour suivre toutes les IP et leur faire passer des tests de ping afin d’en vérifier l’emplacement physique réel
  • Cette méthode écarte les erreurs des données publiques et permet une identification de localisation plus fiable à partir de la latence et des données de saut (hop)

Utilisation du réseau Globalping

  • Globalping est un projet communautaire open source qui permet d’auto-héberger des sondes sous forme de conteneurs
    • Il compte actuellement plus de 3 000 sondes réparties dans le monde
    • Les utilisateurs peuvent y exécuter des tests réseau comme ping ou traceroute
  • L’outil CLI automatise ces opérations à l’aide de la bibliothèque globalping-ts
    • Il lance des tests de ping sur l’IP saisie depuis plusieurs continents
    • Il sélectionne le continent avec la latence la plus faible
    • Il effectue ensuite des mesures plus fines avec plusieurs sondes dans ce continent

Structure des étapes de mesure

  • Étape 1 (détection du continent) : test de ping avec 5 sondes par continent
    • Exemple de résultat : Europe 32,39 ms, Amérique du Nord 137,18 ms → Europe retenue
  • Étape 2 (détection du pays) : mesure avec 50 sondes dans le continent sélectionné
    • Résultat : Pologne 7,29 ms, Allemagne 13,42 ms, Lituanie 17,65 ms → verdict : Pologne
  • Étape 3 (détection de l’État américain) : test avec 50 sondes aux États-Unis
    • L’IP « Bahamas » de NordVPN est en réalité identifiée comme étant en Floride (0,45 ms)
  • Étape 4 (détection de la ville) : mesure avec 36 sondes dans l’État
    • Résultat : Miami (0,00 ms), puis West Palm Beach et Tampa

Précision et limites

  • Le « magic field » de Globalping sélectionne les sondes de manière aléatoire à l’échelle du continent, ce qui peut exclure certains pays
    • Cela peut entraîner des erreurs vers des pays voisins
  • Pour améliorer la précision, il faut spécifier directement les sondes par pays ou par État et ajuster leur nombre
    • Exemple : en Amérique du Nord, il est recommandé d’utiliser 200 sondes aux États-Unis, 20 au Canada et 10 au Mexique
  • La version actuelle utilise un nombre minimal de sondes afin de rester exécutable même pour les utilisateurs non authentifiés
    • Avec authentification, il est possible d’effectuer 500 tests par heure, et des crédits supplémentaires peuvent être obtenus via l’hébergement de sondes ou le sponsoring GitHub

Exécution et usages de l’outil open source

  • Commande : geolocate $IP
    • L’option –limit permet d’ajuster le nombre de sondes à chaque étape
  • La documentation GitHub détaille l’ensemble de l’utilisation
  • Les propositions d’amélioration via Pull Request sont les bienvenues
  • Il est possible de demander des crédits gratuits et de participer à l’hébergement de sondes

Conclusion

  • L’estimation de localisation IP fondée sur la latence constitue une méthode précise et pratique dès lors que l’on dispose d’un nombre suffisant de points d’observation
  • Grâce au réseau Globalping et à l’outil CLI open source, chacun peut facilement vérifier l’emplacement réel d’une IP
  • Cette approche se prête à de nombreux usages, comme la vérification d’usurpation de localisation VPN, l’analyse du routage réseau ou le débogage de performances

À lire aussi

1 commentaires

 
GN⁺ 2026-02-02
Commentaires sur Hacker News
  • Petit projet expérimental pour voir s’il est possible d’estimer une géolocalisation avec un service comme Globalping
    Ça reste au niveau d’une simple démo, insuffisant pour un usage en production
    Pour bien faire, il faudrait au moins 500 probes à chaque étape
    L’optimisation a été volontairement évitée pour ne pas dépasser les limites imposées aux utilisateurs anonymes
    • Il devrait être possible d’utiliser une approche de descente de gradient pour réduire le nombre de probes tout en gagnant en efficacité
      L’idée serait de commencer par trois mesures sur plusieurs continents, d’éliminer la probe la plus lente, puis d’en ajouter une nouvelle près des plus rapides, et de répéter
      Cela permettrait peut-être de « suivre » la position réelle en temps réel au lieu de découper la recherche en cinq étapes
      Le concept consiste à voir la latence comme un champ de potentiel scalaire et à exploiter son gradient
    • En théorie, trois probes ne devraient-elles pas suffire ?
  • Le fait que ce soit fait sans IA est impressionnant
    Les messages de commit d’un seul mot m’ont fait rire, mais ça donne au contraire un côté très humain
    • La présence de séparateurs « ══════ » dans le code fait penser qu’une partie a pu être générée par Claude
  • Je me demande s’il serait possible pour le serveur mesuré d’ajouter une latence artificielle selon l’IP source afin de tromper la localisation
    • C’est tout à fait possible
      Par exemple, des outils comme fakeroute permettent des tromperies encore plus sophistiquées
      Ce serait presque sans utilité pratique, mais l’idée est amusante
    • Ce n’est pas impossible, mais il est bien plus simple de ne pas répondre au ping
    • traceroute est déjà un outil difficile à interpréter, donc la falsification est très facile
      Comme dans l’ancien cas où The Pirate Bay avait fait croire à un déplacement en Corée du Nord, un AS peut aussi ajouter de faux AS dans le chemin BGP pour rendre le tout plus crédible
      Ce genre de technique pourrait déboucher sur un véritable jeu du chat et de la souris avec les VPN
      Références : discussion Reddit, cas HN
    • Certains FAI régionaux américains (Xfinity, Charter, etc.) ont déjà une latence artificielle à cause du Bufferbloat
      On peut monter jusqu’à 2500 ms de latence, même sur une ligne 1000/30 Mbps
  • J’ai vu une approche similaire dans la recherche « You Can’t Cheat Time », présentée à DEFCON 31
    Vidéo de la présentation
    Les limites de la géolocalisation basée sur le ping sont les suivantes :
    les IP ont déjà des informations de localisation dans des bases de données, l’asymétrie du routage casse les modèles de distance, un même IP peut exister dans plusieurs régions via Anycast/CDN, et l’ICMP est souvent bloqué ou peu prioritaire
    À la place du ping, j’ai utilisé un modèle basé sur la latence HTTP(S) + ML(SVR) entraîné sur 39 000 points de données
    Sur des serveurs derrière CloudFront, l’erreur était d’environ 600 km
    L’essentiel n’est pas la précision absolue, mais la détection de sandbox, les malwares géorestreints, et le fait d’apporter un signal de localisation secondaire quand les bases IP échouent
    • Si l’on voulait éviter ce type de suivi, on pourrait ajouter un délai aléatoire à tous les paquets, ou définir des règles de latence intentionnelle selon la source du ping afin d’apparaître à l’endroit souhaité
  • Je suis surpris que ce genre de méthode fonctionne malgré les fortes variations de latence
    En discutant autrefois avec un ami néerlandais, il m’est arrivé d’accéder à du contenu NL depuis le Royaume-Uni avec une latence plus faible que lui
    C’était probablement dû à une différence de qualité du peering
    • Je travaille chez IPinfo
      Nous menons avec des IXP et de grandes institutions de l’Internet un projet de partage de données sur le routage et le peering
      Dans certains pays, il existe un peering direct avec des IXP d’un autre continent, ce qui crée des écarts de latence correspondant à plusieurs milliers de kilomètres
      Il arrive aussi que le trafic entre deux opérateurs d’un même pays passe en réalité par l’étranger
      Nous corrigeons ce phénomène avec des algorithmes de géolocalisation basés sur la mesure
      L’objectif final est d’aider les IXP, les opérateurs et les organismes de gouvernance de l’Internet à résoudre ces problèmes
    • Cela peut aussi venir simplement de la latence de la boucle locale
      Avec du VDSL ou du DOCSIS, on peut déjà avoir 5 à 15 ms de latence sur seulement 1 km
      Entre Londres et Amsterdam, on est à environ 7 ms
    • Il est aussi possible que le contenu ait été servi depuis un PoP proche grâce au cache
      Autrefois, même les grands centres urbains néerlandais manquaient de fibre optique
    • Depuis ma ville, la distance à vol d’oiseau jusqu’à un serveur français est de 250 km, mais le ping l’estime à 2000 km
      Cela signifie une distance gonflée de plus de 8 fois par rapport à la réalité
      Un serveur britannique est plus loin, mais affiche pourtant un ping plus bas
      Une approche basée sur traceroute paraît plus réaliste qu’avec le seul ping
  • Merci à Dimitry. Toute l’équipe IPinfo apprécie la mention
    Notre chercheur Calvin présentera bientôt un exposé sur la géolocalisation IP basée sur la mesure au NANOG96
    Lien vers la présentation
  • Très belle idée, et très belle exécution
    J’aimerais voir plus souvent ce genre de projet sur HN
  • À lire l’article, on dirait qu’il se contente de choisir comme localisation le ping le plus court
    C’est une approche beaucoup trop simple, et utiliser la triangulation devrait donner de meilleurs résultats
    • Comme indiqué dans l’article, l’objectif était surtout un simple proof of concept
      Avec assez de probes et un peu de chance, ça fonctionne étonnamment bien
      Bien sûr, il existe des méthodes bien plus intelligentes
    • Mais les paquets ne se déplacent pas en ligne droite, donc un calcul de distance simple n’a pas beaucoup de sens
  • Retour d’expérience sur l’usage de cette technique en conditions réelles
    1. En routage Internet, la trilatération ne fonctionne presque jamais
      En pratique, il vaut mieux s’appuyer sur la mesure unique la plus proche
      Pour obtenir des données utiles, il faut des milliers de nœuds à l’échelle d’une ville
    2. Ce type de mesure convient surtout pour valider des données de localisation existantes
    3. Les hops de traceroute sont utiles pour localiser les routeurs
      RIPE IPmap cartographie déjà correctement la plupart des routeurs publics
    4. Cela fonctionne bien sur les IP d’infrastructure ou de serveurs, mais atteint vite ses limites sur les réseaux grand public
      Je recommande aussi ping.sx comme outil de comparaison
  • En regardant l’IP route du chemin retour, on arrive souvent à une localisation assez juste au niveau de l’État américain
    Le FQDN du dernier hop contient souvent un code d’aéroport ou un code de ville, ce qui aide beaucoup