ipinfo’yu evde kullanmak: Gecikmeyi kullanarak CLI’da bir IP’nin konumunu bulma yöntemi

 (blog.globalping.io)
2 puan yazan GN⁺ 2026-02-02 | 1 yorum | WhatsApp'ta paylaş
  • Gecikme (latency) kullanılarak bir IP adresinin ülke·eyalet·şehir düzeyinde tahmin edilmesini sağlayan bir CLI aracı
  • Globalping ağındaki 3000’den fazla probe kullanılarak her IP için ping ve traceroute ölçümleri yapılıyor
  • Kıta → ülke → eyalet → şehir adımlarında gecikmeler karşılaştırılıyor ve en düşük değere sahip bölgenin gerçek konum olduğu kabul ediliyor
  • Test sonuçlarında Polonya·Florida·Miami gibi örneklerde ipinfo’nun sonuçlarıyla örtüşen bir doğruluk gösterildi
  • Herkesin çalıştırabileceği açık kaynaklı bir CLI aracı olarak, gecikme tabanlı IP konum doğrulama yaklaşımının pratikliğini ortaya koyuyor

Gecikme tabanlı IP konum tahminine genel bakış

  • IP adreslerini ülke, ABD eyaleti ve şehir düzeyinde çözümleyebilen bir CLI aracı geliştirildi
  • ipinfo’nun, VPN sağlayıcılarının sahte konum verileri kaydettiğini kanıtladığı örneklerden ilham alındı
    • ipinfo, büyük ölçekli bir probe ağı kurarak tüm IP’leri izleyip ping testleri ile gerçek fiziksel konumu doğruluyor
  • Bu yaklaşım, açık verideki hataları dışarıda bırakarak gecikme ve hop verilerine dayalı, yüksek güvenilirlikte konum tespiti yapılmasını sağlıyor

Globalping ağından yararlanma

  • Globalping, açık kaynak topluluğu temelli bir proje ve konteyner tabanlı probe’lar self-host edilebiliyor
    • Şu anda dünya geneline yayılmış 3000’den fazla probe bulunuyor
    • Kullanıcılar bu ağ üzerinden ping, traceroute ve benzeri ağ testleri gerçekleştirebiliyor
  • CLI aracı, otomasyon için globalping-ts kütüphanesini kullanıyor
    • Girilen IP için birden fazla kıtadan ping testi yapılıyor
    • En düşük gecikmeyi veren kıta seçiliyor
    • Ardından o kıta içindeki birden fazla probe ile ayrıntılı ölçüm yapılıyor

Ölçüm aşamalarının yapısı

  • 1. aşama (kıta tespiti): Her kıta için 5 probe ile ping testi
    • Örnek sonuç: Avrupa 32.39ms, Kuzey Amerika 137.18ms → Avrupa seçiliyor
  • 2. aşama (ülke tespiti): Seçilen kıta içinde 50 probe ile ölçüm
    • Sonuç: Polonya 7.29ms, Almanya 13.42ms, Litvanya 17.65ms → Polonya olarak belirleniyor
  • 3. aşama (ABD eyaleti tespiti): ABD içinde 50 probe ile test
    • NordVPN’in “Bahamalar” IP’sinin gerçekte Florida (0.45ms) olduğu belirleniyor
  • 4. aşama (şehir tespiti): Eyalet içinde 36 probe ile ölçüm
    • Sonuç: Miami (0.00ms), ardından West Palm Beach ve Tampa

Doğruluk ve sınırlamalar

  • Globalping’in “magic field”i, probe’ları kıta düzeyinde rastgele seçtiği için bazı ülkeler dışarıda kalabiliyor
    • Bu nedenle komşu ülkenin yanlış seçilmesi ihtimali bulunuyor
  • Doğruluğu artırmak için ülke ve eyalet bazında probe’ları doğrudan belirtmek ve probe sayısını ayarlamak gerekiyor
    • Örneğin Kuzey Amerika için ABD’den 200, Kanada’dan 20, Meksika’dan 10 probe öneriliyor
  • Mevcut sürüm, kimliği doğrulanmamış kullanıcıların da çalıştırabilmesi için minimum probe sayısını kullanıyor
    • Kimlik doğrulamasıyla saatte 500 test yapılabiliyor; ek kredi ise probe barındırma veya GitHub sponsorluğu ile alınabiliyor

Açık kaynak aracın çalıştırılması ve kullanımı

  • Komut: geolocate $IP
    • Aşama başına probe sayısı –limit seçeneğiyle ayarlanabiliyor
  • Tüm kullanım şekli GitHub belgelerinde görülebilir
  • Pull Request ile geliştirme önerileri memnuniyetle karşılanıyor
  • Ücretsiz kredi talebi ve probe barındırmaya katılım mümkün

Sonuç

  • Gecikme tabanlı IP konum tahmini, yeterli gözlem noktası olduğunda doğru ve pratik bir yöntem
  • Globalping ağı ve açık kaynak CLI aracı sayesinde herkes IP’nin gerçek konumunu kolayca doğrulayabiliyor
  • VPN konum sahteciliğinin doğrulanması, ağ yönlendirme analizi ve performans hata ayıklama gibi çeşitli kullanım alanları doğrulanmış oldu

İlgili okumalar

1 yorum

 
GN⁺ 2026-02-02
Hacker News yorumları
  • coğrafi konum tahmini yapmanın Globalping gibi servislerle mümkün olup olmadığını deneyen küçük bir proje
    Sadece basit bir demo düzeyinde; gerçek operasyonel kullanım için yetersiz
    Düzgün kullanmak için her adımda en az 500 probe gerekiyor
    Anonim kullanıcı limitini aşmamak için optimizasyondan bilerek kaçınılmış
    • Probe sayısını azaltırken verimliliği artırmak için bir gradient descent yaklaşımı denenebilir gibi görünüyor
      Başta farklı kıtalardan üçer ölçüm alıp, en yavaş probe'ları eleyerek hızlı olanların yakınına yeni probe'lar eklemek şeklinde yinelemeli ilerlenebilir
      Böylece 5 adıma bölmek yerine gerçek konumu gerçek zamanlı olarak “takip etmek” mümkün olabilir
      Buradaki fikir, latency'yi bir skaler potansiyel alan olarak görüp gradyanını kullanmak
    • Teorik olarak 3 probe yeterli olmaz mı?
  • Yapay zeka olmadan yapılmış olması etkileyici
    Commit mesajlarının tek kelimelik olması komikti ama bir yandan da daha insani hissettiriyor
    • Koddaki “══════” ayraçları yüzünden bazı kısımların Claude tarafından üretilmiş olabileceğini düşündürüyor
  • Ölçülen sunucunun kaynak IP'ye göre yapay gecikme ekleyerek konumunu yanıltmasının mümkün olup olmadığı merak ediliyor
    • Oldukça mümkün
      Örneğin fakeroute gibi araçlarla daha da sofistike aldatmalar yapılabilir
      Pek pratik olmaz ama eğlenceli bir fikir
    • İmkansız değil ama ping'e hiç yanıt vermemek çok daha kolay
    • traceroute zaten yorumlaması zor bir araç, bu yüzden sahtecilik yapmak çok kolay
      Geçmişte The Pirate Bay'in Kuzey Kore'ye taşınmış gibi görünmesi örneğinde olduğu gibi, bir AS BGP yoluna sahte AS'ler ekleyerek işi daha inandırıcı hale getirebilir
      Bu da VPN'lerle bir kedi-fare oyununa dönüşebilir gibi görünüyor
      İlgili kaynaklar: Reddit tartışması, HN örneği
    • ABD'deki bazı bölgesel ISP'lerde (Xfinity, Charter vb.) Bufferbloat yüzünden zaten yapay gecikmeler oluşuyor
      1000/30Mbps bağlantıda bile gecikme 2500ms'ye çıkabiliyor
  • DEFCON 31'de sunulan ‘You Can’t Cheat Time’ araştırmasında benzer bir yaklaşım görmüştüm
    Sunum videosu
    Ping tabanlı konum tahmininin sınırları şunlar:
    IP'nin konumu zaten veritabanlarında bulunuyor, routing asimetrisi mesafe modelini bozuyor, Anycast/CDN nedeniyle tek bir IP birden çok bölgede var olabiliyor ve ICMP engellenebiliyor ya da düşük öncelikli olabiliyor
    Ben ping yerine HTTP(S) gecikmesi + ML(SVR) modeli kullanarak 39 bin veri noktasıyla eğitim yaptım
    CloudFront arkasındaki sunucularda hata payı yaklaşık 600km idi
    Burada hassasiyetten daha önemli olan şeyler sandbox tespiti, geofence kötü amaçlı yazılımlar ve IP DB başarısız olduğunda yardımcı konum sinyali sağlamak
    • İzlenmekten kaçınmak isterseniz tüm paketlere rastgele gecikme ekleyebilir veya ping kaynağına göre kasıtlı gecikme kuralları koyup istediğiniz konumdaymış gibi görünebilirsiniz
  • Gecikme çok oynak olmasına rağmen bu yöntemin işe yaraması şaşırtıcı
    Eskiden Hollandalı bir arkadaşla konuşurken, Birleşik Krallık'tan NL içeriğine daha düşük gecikmeyle erişebildiğim olmuştu
    Muhtemelen sebep peering kalitesi farkıydı
    • IPinfo'da çalışıyorum
      IXP'ler ve büyük internet kurumlarıyla birlikte routing ve peering veri paylaşım projeleri yürütüyoruz
      Bazı ülkeler başka kıtalardaki IXP'lerle doğrudan peering yapıyor; bu da gecikmede binlerce km'lik fark yaratabiliyor
      Hatta bir ülkenin iki operatörü arasındaki trafiğin yurtdışına çıkıp geri döndüğü durumlar bile var
      Bu tür olguları ölçüm tabanlı coğrafi konum algoritmalarıyla düzeltiyoruz
      Nihai hedefimiz IXP'lerin, operatörlerin ve internet yönetişimi kurumlarının bu sorunları çözmesine yardımcı olmak
    • Bu sadece yerel erişim hattı gecikmesi de olabilir
      VDSL veya DOCSIS'te sadece 1km'lik bölümde 5–15ms gecikme oluşabiliyor
      Londra–Amsterdam arası ise yaklaşık 7ms
    • Muhtemelen içerik size yakın bir PoP'tan cache'ten geliyordu
      Eskiden Hollanda'nın büyük şehirlerinde bile fiber eksikliği vardı
    • Benim şehrimden Fransa'daki bir sunucuya kuş uçuşu 250km var ama ping'e göre 2000km çıkıyor
      Yani mesafe gerçekte olduğundan 8 kattan fazla şişiyor
      Birleşik Krallık'taki sunucu daha uzakta olmasına rağmen ping'i daha düşük çıkıyor
      traceroute tabanlı yaklaşım ping'den daha gerçekçi
  • Dimitry'ye teşekkürler. IPinfo ekibinin tamamı bu anılmadan memnun
    Araştırmacı Calvin, NANOG96'da ölçüm tabanlı IP coğrafi konumu üzerine bir sunum yapacak
    Sunum bağlantısı
  • Gerçekten harika bir fikir ve çok iyi bir uygulama
    HN'de bunun gibi daha fazla proje görmek isterdim
  • Yazıdan anladığım kadarıyla sadece en kısa ping konum olarak seçiliyor gibi görünüyor
    Bu fazla basit bir yaklaşım; triangulation kullanılsa daha doğru olabilir
    • Yazıda da belirtildiği gibi amaç sadece basit bir proof of concept idi
      Yeterli probe ve biraz şansla şaşırtıcı derecede iyi çalışabiliyor
      Elbette çok daha akıllı yöntemler var
    • Ama paketler düz bir çizgide gitmez, dolayısıyla basit mesafe hesabı çok anlamlı değil
  • Bu tekniği gerçek servis ortamında kullanma deneyimini paylaşan biri şunları söylüyor
    1. İnternet routing'inde trilateration neredeyse hiç işe yaramıyor
      Bu yüzden pratikte en yakın tekil ölçümü kullanmak daha mantıklı
      Faydalı veri elde etmek için şehir ölçeğinde binlerce node gerekiyor
    2. Bu tür ölçümler, mevcut konum verisini doğrulamak için daha uygun
    3. traceroute hop'ları router konumunu bulmakta işe yarıyor
      RIPE IPmap zaten çoğu açık router'ı doğru şekilde haritalıyor
    4. Altyapı veya sunucu IP'lerinde iyi çalışıyor ama sıradan kullanıcı ağlarında sınırlı kalıyor
      Karşılaştırma aracı olarak ping.sx de öneriliyor
  • Ters yönlü yolun IP route bilgisine bakıldığında çoğu zaman ABD eyaleti düzeyine kadar oldukça isabetli sonuç alınabiliyor
    Son hop'un FQDN'inde sık sık havaalanı kodu veya şehir kodu yer alıyor; bu da yardımcı oluyor