ipinfo zu Hause nutzen: So findet man den Standort einer IP per Latenz in der CLI

 (blog.globalping.io)
2 Punkte von GN⁺ 2026-02-02 | 1 Kommentare | Auf WhatsApp teilen
  • Ein CLI-Tool, das mithilfe von Latenz eine IP-Adresse auf Länder-, Bundesstaat-/Provinz- und Stadtebene schätzen kann
  • Nutzt mehr als 3000 Probes im Globalping-Netzwerk, um für jede IP Ping- und Traceroute-Messungen durchzuführen
  • Vergleicht die Latenz schrittweise über Kontinent → Land → Bundesstaat → Stadt und bewertet die Region mit dem niedrigsten Wert als tatsächlichen Standort
  • Tests zeigen eine Genauigkeit, die mit den Ergebnissen von ipinfo übereinstimmt, etwa für Polen, Florida und Miami
  • Als Open-Source-CLI-Tool für alle ausführbar und ein Nachweis für die Praxis­tauglichkeit latenzbasierter IP-Standortprüfung

Überblick über die latenzbasierte IP-Standortbestimmung

  • Es wurde ein CLI-Tool entwickelt, das IP-Adressen auf Länder-, US-Bundesstaat- und Stadtebene auflösen kann
  • Ausgangspunkt war ein Fall von ipinfo, der belegte, dass VPN-Anbieter falsche Standortdaten registrieren
    • ipinfo baut ein großes Probe-Netzwerk auf und verfolgt sowie pingt alle IPs, um ihren tatsächlichen physischen Standort zu verifizieren
  • Dieser Ansatz schließt Fehler in öffentlichen Datenquellen aus und ermöglicht eine verlässliche Standortbestimmung auf Basis von Latenz- und Hop-Daten

Nutzung des Globalping-Netzwerks

  • Globalping ist ein Open-Source-Community-Projekt, bei dem sich containerisierte Probes selbst hosten lassen
    • Derzeit sind mehr als 3000 Probes weltweit verteilt
    • Nutzer können über dieses Netzwerk Netzwerktests wie Ping und Traceroute durchführen
  • Das CLI-Tool automatisiert dies mit der globalping-ts-Bibliothek
    • Führt für die eingegebene IP Ping-Tests von mehreren Kontinenten aus
    • Wählt den Kontinent mit der geringsten Latenz
    • Führt danach innerhalb dieses Kontinents detailliertere Messungen mit mehreren Probes durch

Aufbau der einzelnen Messstufen

  • Stufe 1 (Kontinenterkennung): Ping-Test mit je 5 Probes pro Kontinent
    • Beispielergebnis: Europa 32.39ms, Nordamerika 137.18ms → Europa gewählt
  • Stufe 2 (Ländererkennung): Messung mit 50 Probes innerhalb des gewählten Kontinents
    • Ergebnis: Polen 7.29ms, Deutschland 13.42ms, Litauen 17.65ms → als Polen bewertet
  • Stufe 3 (US-Bundesstaatenerkennung): Test mit 50 Probes innerhalb der USA
    • Die „Bahamas“-IP von NordVPN wurde tatsächlich als Florida (0.45ms) eingestuft
  • Stufe 4 (Stadterkennung): Messung mit 36 Probes innerhalb des Bundesstaats
    • Ergebnis: Miami (0.00ms), danach West Palm Beach und Tampa

Genauigkeit und Grenzen

  • Das „magic field“ von Globalping wählt Probes auf Kontinentebene zufällig aus, wodurch einzelne Länder fehlen können
    • Dadurch sind Fehleinstufungen in Nachbarländer möglich
  • Für höhere Genauigkeit sollten Probes pro Land oder Bundesstaat gezielt angegeben und die Anzahl der Probes angepasst werden
    • Beispiel: Für Nordamerika werden 200 US-, 20 kanadische und 10 mexikanische Probes empfohlen
  • Die aktuelle Version verwendet die minimale Probe-Anzahl, damit sie auch ohne Authentifizierung nutzbar ist
    • Mit Authentifizierung sind 500 Tests pro Stunde möglich; zusätzliche Credits lassen sich durch Probe-Hosting oder GitHub-Sponsoring erhalten

Ausführung und Einsatz des Open-Source-Tools

  • Befehl: geolocate $IP
    • Mit der Option –limit lässt sich die Anzahl der Probes pro Stufe anpassen
  • Die vollständige Nutzung ist in der GitHub-Dokumentation beschrieben
  • Verbesserungsvorschläge per Pull Request sind willkommen
  • Kostenlose Credits anfragen und sich am Probe-Hosting beteiligen ist möglich

Fazit

  • Latenzbasierte IP-Standortbestimmung ist bei genügend Beobachtungspunkten eine genaue und praxisnahe Methode
  • Mit dem Globalping-Netzwerk und dem Open-Source-CLI-Tool kann praktisch jeder den tatsächlichen Standort einer IP einfach verifizieren
  • Geeignet unter anderem für die Prüfung gefälschter VPN-Standorte, die Analyse von Netzwerk-Routing und Performance-Debugging

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2026-02-02
Hacker-News-Kommentare
  • Ein kleines Projekt, das ausprobiert, ob sich mit Diensten wie Globalping eine geografische Standortschätzung machen lässt.
    Es ist nur auf Demo-Niveau und für den produktiven Einsatz unzureichend.
    Um es richtig zu nutzen, bräuchte man in jedem Schritt mindestens 500 Probes.
    Um die Limits für anonyme Nutzer nicht zu überschreiten, wurde bewusst auf Optimierung verzichtet.
    • Man könnte wohl einen Gradient-Descent-Ansatz nutzen, um die Zahl der Probes zu senken und zugleich die Effizienz zu erhöhen.
      Anfangs würde man auf mehreren Kontinenten jeweils dreimal messen, dann die langsamste Probe verwerfen und in der Nähe der schnelleren neue Probes hinzufügen, wiederholt als Iteration.
      So könnte man den tatsächlichen Standort womöglich in Echtzeit „verfolgen“, statt ihn in fünf Stufen einzugrenzen.
      Die Idee ist, Latenz als skalares Potentialfeld zu betrachten und dessen Gradienten zu nutzen.
    • Reichen theoretisch nicht schon drei Probes?
  • Beeindruckend, dass es ohne AI gebaut wurde.
    Die Commit-Messages mit nur einem Wort waren lustig, wirkten aber gerade dadurch menschlich.
    • Wegen der Trennlinien „══════“ im Code wirkt es so, als seien einige Teile von Claude erzeugt worden.
  • Ich frage mich, ob der gemessene Server dem Quell-IP je nach Herkunft künstliche Latenz hinzufügen könnte, um seinen Standort zu verschleiern.
    • Durchaus möglich.
      Mit Tools wie fakeroute ließen sich zum Beispiel noch ausgefeiltere Täuschungen umsetzen.
      Praktisch wäre das kaum, aber es ist eine interessante Idee.
    • Nicht unmöglich, aber es ist viel einfacher, einfach nicht auf Ping zu antworten.
    • Traceroute ist ohnehin ein schwer zu interpretierendes Tool, daher sehr leicht zu fälschen.
      Wie in dem früheren Fall, als The Pirate Bay so tat, als wäre es nach Nordkorea umgezogen, könnte ein AS auch gefälschte AS-Einträge in den BGP-Pfad einfügen, um es glaubwürdiger wirken zu lassen.
      Solche Techniken könnten zu einem Katz-und-Maus-Spiel mit VPNs führen.
      Dazu: Reddit-Diskussion, HN-Beispiel
    • Einige regionale ISPs in den USA (Xfinity, Charter usw.) erzeugen wegen Bufferbloat bereits künstlich wirkende Latenz.
      Selbst bei 1000/30Mbps-Anschlüssen treten bis zu 2500ms Verzögerung auf.
  • Ich habe einen ähnlichen Ansatz in der auf der DEFCON 31 vorgestellten Forschung „You Can’t Cheat Time“ gesehen.
    Vortragsvideo
    Die Grenzen ping-basierter Standortbestimmung sind folgende:
    IPs haben oft bereits Standortdaten in Datenbanken, Routing-Asymmetrie zerstört Distanzmodelle, durch Anycast/CDNs kann eine einzelne IP in mehreren Regionen existieren, und ICMP wird blockiert oder niedrig priorisiert.
    Ich habe statt Ping ein Modell mit HTTP(S)-Latenz + ML(SVR) verwendet und mit 39.000 Datensätzen trainiert.
    Bei Servern hinter CloudFront lag der Fehler bei etwa 600 km.
    Wichtiger als Präzision sind Sandbox-Erkennung, Geofence-Malware und ein zusätzliches Standortsiganl, wenn IP-Datenbanken versagen.
    • Wenn man der Verfolgung entgehen will, könnte man allen Paketen zufällige Verzögerungen hinzufügen oder je nach Ping-Quelle absichtlich Latenzregeln festlegen, damit es wie ein gewünschter Standort aussieht.
  • Erstaunlich, dass so ein Ansatz trotz stark schwankender Latenz funktioniert.
    Ich hatte früher einmal mit einem Freund in den Niederlanden gesprochen, und von Großbritannien aus hatte ich teils geringere Latenz zu NL-Inhalten.
    Vermutlich lag das an Unterschieden in der Peering-Qualität.
    • Ich arbeite bei IPinfo.
      Wir führen gemeinsam mit IXPs und großen Internetinstitutionen ein Projekt zum Teilen von Routing- und Peering-Daten durch.
      In manchen Ländern gibt es direktes Peering mit IXPs auf anderen Kontinenten, wodurch die Latenz um Tausende Kilometer abweichen kann.
      Es gibt tatsächlich Fälle, in denen Verkehr zwischen zwei Providern desselben Landes über das Ausland umgeleitet wird.
      Solche Phänomene korrigieren wir mit messbasierten Geolokalisierungsalgorithmen.
      Langfristig wollen wir IXPs, Provider und Internet-Governance-Organisationen dabei helfen, solche Probleme zu lösen.
    • Es könnte auch einfach an der Latenz der letzten Meile liegen.
      Bei VDSL oder DOCSIS entstehen auf nur 1 km bereits 5–15ms Verzögerung.
      London–Amsterdam liegt bei ungefähr 7ms.
    • Vielleicht kamen die Inhalte auch aus einem nahegelegenen PoP-Cache.
      Früher gab es selbst in großen niederländischen Städten nicht genug Glasfaserkabel.
    • Von meiner Stadt bis zu einem Server in Frankreich sind es in Luftlinie 250 km, aber nach Ping-Berechnung wären es 2000 km.
      Die Distanz wird also auf mehr als das Achtfache der Realität aufgebläht.
      Ein Server in Großbritannien ist weiter weg, hat aber trotzdem einen niedrigeren Ping.
      Ein traceroute-basierter Ansatz ist realistischer als Ping.
  • Danke an Dimitry. Das ganze Team von IPinfo freut sich über die Erwähnung.
    Unser Forscher Calvin wird auf der NANOG96 einen Vortrag über messbasierte IP-Geolokalisierung halten.
    Link zum Vortrag
  • Wirklich eine großartige Idee und starke Umsetzung.
    Solche Projekte würde ich auf HN gern öfter sehen.
  • Nach dem Artikel scheint der Standort einfach über den kürzesten Ping bestimmt zu werden.
    Das ist ein zu simpler Ansatz; mit Triangulation müsste es genauer sein.
    • Wie im Artikel erwähnt, war das Ziel nur ein einfacher Proof of Concept.
      Mit genügend Probes und etwas Glück funktioniert es überraschend gut.
      Natürlich gibt es deutlich schlauere Methoden.
    • Aber Pakete bewegen sich nicht in geraden Linien, deshalb sind einfache Distanzberechnungen sinnlos.
  • Jemand teilt Erfahrungen damit, diese Technik in realen Service-Umgebungen eingesetzt zu haben.
    1. Trilateration funktioniert im Internet-Routing fast nie.
      Deshalb ist es realistischer, einfach den einzelnen nächstgelegenen Messwert zu verwenden.
      Um brauchbare Daten zu bekommen, braucht man auf Stadtebene Tausende Nodes.
    2. Solche Messungen eignen sich eher dazu, vorhandene Standortdaten zu validieren.
    3. Traceroute-Hops sind nützlich, um Router-Standorte zu finden.
      RIPE IPmap hat bereits die meisten öffentlichen Router korrekt kartiert.
    4. Für Infrastruktur- oder Server-IPs funktioniert es gut, bei normalen Nutzernetzen gibt es aber Grenzen.
      Als Vergleichstool wird auch ping.sx empfohlen.
  • Wenn man sich die IP-Route des Rückwegs ansieht, liegt man zumindest auf Bundesstaatenebene oft ziemlich richtig.
    Im FQDN des letzten Hops stehen oft Flughafencodes oder Stadtkürzel, was hilfreich sein kann.