घर पर ipinfo इस्तेमाल करना: latency की मदद से CLI में IP की लोकेशन कैसे पता करें

• latency का उपयोग करके IP address की देश·राज्य·शहर स्तर पर पहचान की जा सकती है, इसके लिए एक CLI टूल बनाया गया है
• Globalping नेटवर्क के 3000 से अधिक probes का उपयोग कर, हर IP के लिए ping और traceroute मापन किया जाता है
• महाद्वीप → देश → राज्य → शहर के चरणों में latency की तुलना करके, सबसे कम मान वाले क्षेत्र को वास्तविक लोकेशन माना जाता है
• टेस्ट नतीजों में पोलैंड·Florida·Miami जैसे मामलों में ipinfo के परिणामों से मेल खाती सटीकता दिखाई गई
• यह एक open source CLI टूल है जिसे कोई भी चला सकता है, और यह latency-आधारित IP लोकेशन सत्यापन पद्धति की व्यावहारिकता साबित करता है

---

latency-आधारित IP लोकेशन अनुमान का अवलोकन

• IP address को देश, अमेरिकी राज्य, शहर स्तर तक पहचान सकने वाला एक CLI टूल बनाया गया है
  • GitHub repository: jimaek/geolocation-tool
• उस उदाहरण से प्रेरणा ली गई जिसमें ipinfo ने साबित किया था कि VPN providers फर्जी लोकेशन डेटा रजिस्टर करते हैं
  • ipinfo ने बड़े पैमाने का probe नेटवर्क बनाकर सभी IPs को track और ping test करके वास्तविक भौतिक लोकेशन सत्यापित की
• यह तरीका public data की त्रुटियों को हटाकर, latency और hop data के आधार पर अधिक भरोसेमंद लोकेशन निर्धारण संभव बनाता है

Globalping नेटवर्क का उपयोग

• Globalping एक open source community-आधारित प्रोजेक्ट है, जिसमें containerized probes को self-host किया जा सकता है
  • अभी दुनिया भर में 3000 से अधिक probes फैले हुए हैं
  • उपयोगकर्ता इस नेटवर्क के जरिए ping, traceroute जैसे network tests चला सकते हैं
• CLI टूल globalping-ts library का उपयोग करके automate किया गया है
  • दिए गए IP पर कई महाद्वीपों से ping test
  • सबसे कम latency वाले महाद्वीप का चयन
  • इसके बाद उसी महाद्वीप के कई probes से विस्तृत मापन

मापन के चरणबद्ध ढांचे

• चरण 1 (महाद्वीप पहचान) : हर महाद्वीप के 5 probes से ping test
  • उदाहरण परिणाम: Europe 32.39ms, North America 137.18ms → Europe चुना गया
• चरण 2 (देश पहचान) : चुने गए महाद्वीप के भीतर 50 probes से मापन
  • परिणाम: Poland 7.29ms, Germany 13.42ms, Lithuania 17.65ms → Poland निर्धारित
• चरण 3 (अमेरिकी राज्य पहचान) : अमेरिका के भीतर 50 probes से टेस्ट
  • NordVPN का ‘Bahamas’ IP वास्तव में Florida (0.45ms) निकला
• चरण 4 (शहर पहचान) : राज्य के भीतर 36 probes से मापन
  • परिणाम: Miami (0.00ms) , उसके बाद West Palm Beach, Tampa

सटीकता और सीमाएँ

• Globalping का ‘magic field’ महाद्वीप स्तर पर probes को random तरीके से चुनता है, इसलिए कुछ देश छूट सकते हैं
  • इसके कारण पड़ोसी देशों की गलत पहचान होने की संभावना है
• सटीकता बढ़ाने के लिए देश·राज्य के अनुसार probes को सीधे निर्दिष्ट करना होगा और probes की संख्या समायोजित करनी होगी
  • उदाहरण: North America के लिए US 200, Canada 20, Mexico 10 probes की सिफारिश
• मौजूदा version में unauthenticated users भी चला सकें इसलिए न्यूनतम probes इस्तेमाल किए गए हैं
  • authentication होने पर प्रति घंटा 500 tests संभव हैं, और अतिरिक्त credits probe hosting या GitHub sponsorship से मिल सकते हैं

open source टूल चलाना और उपयोग

• कमांड: geolocate $IP
  • –limit option से हर चरण में probes की संख्या समायोजित की जा सकती है
• पूरी उपयोग विधि GitHub docs में देखी जा सकती है
• Pull Request के जरिए सुधार सुझावों का स्वागत है
• free credits के अनुरोध और probe hosting में भागीदारी भी संभव है
  • probe hosting: jsdelivr/globalping-probe

निष्कर्ष

• latency-आधारित IP लोकेशन अनुमान पर्याप्त observation points होने पर सटीक और व्यावहारिक तरीका है
• Globalping नेटवर्क और open source CLI टूल के जरिए कोई भी आसानी से IP की वास्तविक लोकेशन सत्यापित कर सकता है
• VPN लोकेशन spoofing सत्यापन, network routing analysis, performance debugging जैसे कई उपयोग मामलों की संभावना दिखती है

[GN⁺]

Hacker News टिप्पणियाँ

• यह एक छोटा प्रोजेक्ट है जिसमें Globalping जैसी सेवा का उपयोग करके भौगोलिक स्थान का अनुमान लगाने की संभावना पर प्रयोग किया गया है
  यह सिर्फ़ डेमो स्तर का है, इसलिए वास्तविक प्रोडक्शन उपयोग के लिए पर्याप्त नहीं है
  इसे सही तरह से उपयोग करने के लिए हर चरण में कम से कम 500 probe चाहिए
  anonymous user limits को पार न करना पड़े, इसलिए optimization जानबूझकर नहीं किया गया
  • probe की संख्या घटाते हुए भी efficiency बढ़ाने के लिए gradient descent तरीका आज़माया जा सकता है
    शुरुआत में कई continents से 3-3 बार measurement किया जाए, फिर सबसे धीमे probe को हटाकर तेज़ वाले के पास नया probe जोड़ा जाए, और इस प्रक्रिया को दोहराया जाए
    इससे 5 चरणों में बाँटने के बजाय वास्तविक स्थान को रीयल-टाइम में ‘track’ करना संभव हो सकता है
    latency को एक scalar potential field की तरह देखकर उसके gradient का उपयोग करने का विचार है
  • सिद्धांततः 3 probe काफ़ी नहीं होने चाहिए?
• यह बात प्रभावशाली लगी कि इसे AI के बिना बनाया गया
  commit messages एक-शब्द वाले थे, जो मज़ेदार लगे, लेकिन उसी से मानवीय एहसास भी आता है
  • कोड में “══════” जैसी विभाजन रेखाएँ हैं, इसलिए लगा कि शायद कुछ हिस्से Claude ने जनरेट किए हों
• यह जिज्ञासा है कि क्या target server source IP के आधार पर कृत्रिम latency जोड़कर अपनी location के बारे में धोखा दे सकता है
  • पूरी तरह संभव है
    उदाहरण के लिए fakeroute जैसे टूल से इससे भी अधिक परिष्कृत धोखा संभव है
    व्यावहारिक उपयोगिता लगभग नहीं होगी, लेकिन विचार मज़ेदार है
  • असंभव तो नहीं, लेकिन ping का जवाब न देना उससे कहीं आसान है
  • traceroute अपने आप में ऐसा टूल है जिसे समझना मुश्किल होता है, इसलिए spoof करना बहुत आसान है
    जैसे पहले The Pirate Bay ने उत्तर कोरिया में शिफ्ट होने का दिखावा किया था, उसी तरह कोई AS, BGP route में नकली AS जोड़कर चीज़ों को और विश्वसनीय बना सकता है
    यह तकनीक VPN के साथ लुका-छिपी का खेल भी बन सकती है
    संबंधित संदर्भ: Reddit चर्चा, HN उदाहरण
  • अमेरिका के कुछ regional ISP (Xfinity, Charter आदि) में Bufferbloat के कारण पहले से ही कृत्रिम latency जैसी स्थिति बनती है
    1000/30Mbps लाइन पर भी latency 2500ms तक पहुँच सकती है
• DEFCON 31 में प्रस्तुत ‘You Can’t Cheat Time’ रिसर्च में इसी तरह का दृष्टिकोण देखा गया था
  प्रस्तुति वीडियो
  ping-आधारित geolocation की सीमाएँ इस प्रकार हैं:
  IP के location डेटा पहले से DB में मौजूद होते हैं, routing asymmetry दूरी मॉडल को बिगाड़ देती है, Anycast/CDN के कारण एक ही IP कई regions में मौजूद हो सकता है, और ICMP या तो block होता है या low priority पर रहता है
  मैंने ping की जगह HTTP(S) latency + ML(SVR) मॉडल का उपयोग किया और 39,000 डेटा पॉइंट्स पर ट्रेन किया
  CloudFront के पीछे के server के लिए लगभग 600km की error मिली
  precision से अधिक महत्वपूर्ण हैं sandbox detection, geofenced malware, और IP DB fail होने पर सहायक location signal देना
  • अगर tracking से बचना हो, तो हर packet में random delay जोड़ा जा सकता है, या ping source के हिसाब से जानबूझकर delay rules बनाकर किसी मनचाही location जैसा दिखाया जा सकता है
• यह हैरानी की बात है कि latency में इतना उतार-चढ़ाव होने पर भी यह तरीका काम करता है
  पहले एक डच दोस्त से बात करते समय मैंने UK से NL content को उससे कम latency पर एक्सेस किया था
  शायद इसकी वजह peering quality में अंतर रहा होगा
  • मैं IPinfo में काम करता हूँ
    हम IXPs और प्रमुख इंटरनेट संस्थानों के साथ मिलकर routing और peering data sharing project चला रहे हैं
    कुछ देशों में दूसरे continents के IXP से direct peering होती है, जिससे latency में हज़ारों km के बराबर अंतर आ जाता है
    वास्तविक मामलों में एक ही देश के दो telecom operators के बीच traffic देश से बाहर घूमकर वापस आता है
    हम ऐसे प्रभावों को measurement-based geolocation algorithms से ठीक कर रहे हैं
    अंतिम लक्ष्य IXPs, telecom operators और internet governance bodies को ऐसी समस्याएँ सुलझाने में मदद करना है
  • यह सिर्फ़ local access link latency की वजह से भी हो सकता है
    VDSL या DOCSIS में केवल 1km के खंड पर ही 5–15ms latency जुड़ सकती है
    London–Amsterdam के बीच यह लगभग 7ms है
  • शायद ऐसा इसलिए भी हुआ कि content किसी पास के PoP से cached होकर मिला
    पहले नीदरलैंड के बड़े शहरी इलाकों में भी fiber connectivity कम थी
  • मेरे शहर से फ़्रांस के server की सीधी दूरी 250km है, लेकिन ping के हिसाब से वह 2000km दिखता है
    यानी वास्तविक दूरी से 8 गुना से भी अधिक बढ़ा-चढ़ाकर
    UK का server ज़्यादा दूर है, फिर भी उसका ping कम आता है
    traceroute-आधारित तरीका ping से अधिक यथार्थवादी लगता है
• Dimitry का धन्यवाद। IPinfo की पूरी टीम ने इस उल्लेख के लिए आभार जताया
  researcher Calvin, NANOG96 में measurement-based IP geolocation पर प्रस्तुति देने वाले हैं
  प्रस्तुति लिंक
• यह सचमुच शानदार idea और execution है
  काश HN पर ऐसे projects और ज़्यादा दिखें
• लेख पढ़कर लगा कि यह बस सबसे कम ping को location चुनने के लिए उपयोग कर रहा है
  यह बहुत सरल तरीका है, इसलिए triangulation इस्तेमाल करने पर शायद अधिक accuracy मिले
  • जैसा लेख में भी कहा गया है, लक्ष्य सिर्फ़ एक सरल proof of concept था
    पर्याप्त probe और थोड़ी किस्मत हो तो यह उम्मीद से बेहतर काम करता है
    बेशक इससे अधिक स्मार्ट तरीके मौजूद हैं
  • लेकिन packets सीधी रेखा में यात्रा नहीं करते, इसलिए साधारण distance calculation का कोई ख़ास मतलब नहीं है
• वास्तविक service environment में इस तरह की तकनीक उपयोग करने का अनुभव साझा किया गया
  1. इंटरनेट routing में trilateration लगभग काम नहीं करती
     इसलिए सबसे नज़दीकी एकल measurement का उपयोग करना अधिक व्यावहारिक है
     उपयोगी डेटा पाने के लिए city level पर हज़ारों nodes चाहिए
  2. इस तरह के measurement मौजूदा location data को validate करने के लिए अधिक उपयुक्त हैं
  3. traceroute hop, router location खोजने में उपयोगी होता है
     RIPE IPmap पहले से अधिकांश public routers को काफ़ी सटीकता से map करता है
  4. यह infrastructure या server IP पर अच्छी तरह काम करता है, लेकिन सामान्य user networks पर इसकी सीमाएँ हैं
     तुलना के लिए ping.sx भी सुझाया गया है
  • DEFCON प्रस्तुति वीडियो भी देखने लायक है: https://youtu.be/_iAffzWxexA
• reverse path के IP route को देखने पर कई बार state स्तर तक काफ़ी सही अनुमान मिल जाता है
  आख़िरी hop के FQDN में अक्सर airport code या city code शामिल होता है, जो मददगार होता है