IP लीक केवल WebRTC से नहीं होता। DNS रिज़ॉल्यूशन, टाइम ज़ोन और भाषा, IPv6 तथा थर्ड-पार्टी स्क्रिप्ट भी वास्तविक नेटवर्क एग्ज़िट उजागर कर सकते हैं। यह गाइड हर रास्ते की जाँच और एग्ज़िट व ब्राउज़र वातावरण को संगत रखने के लाभ समझाती है।
IP पता नेटवर्क पर किसी डिवाइस की एक विशिष्ट पहचान है, जिससे डिवाइस एक-दूसरे को पहचानते और आपस में संचार करते हैं। यही विशिष्टता इसे संवेदनशील बनाती है: यदि कोई बाहरी पक्ष आपका IP पता प्राप्त कर ले, तो वह आपको आपकी गतिविधियों से जोड़ सकता है और ब्राउज़िंग आदतों, अनुमानित स्थान तथा इस्तेमाल किए जा रहे नेटवर्क सेवा प्रदाता जैसी जानकारी का अनुमान लगा सकता है। लीक का अर्थ यह नहीं कि डिवाइस में सेंध लग गई है; इसका अर्थ है कि जिस नेटवर्क एग्ज़िट को आप छिपाना चाहते थे, वह किसी दूसरे रास्ते से दिखाई देने लगा।
WebRTC इसका सबसे जाना-पहचाना उदाहरण है। लेकिन रोज़मर्रा के उपयोग में बार-बार समस्या देने वाले रास्ते अक्सर अधिक शांत होते हैं: DNS रिज़ॉल्यूशन, टाइम ज़ोन और भाषा जैसे सहायक संकेत, IPv6, और पेज पर मौजूद थर्ड-पार्टी स्क्रिप्ट। हर रास्ते का समाधान अलग है, लेकिन सभी को व्यवस्थित स्वयं-जाँच से पकड़ा जा सकता है।

पहले IP पते को ही समझें
IP पता नेटवर्क से जुड़े डिवाइस को दिया गया एक संख्यात्मक लेबल है। इसके दो काम हैं: किसी होस्ट या नेटवर्क इंटरफ़ेस की पहचान करना और नेटवर्क में उसकी स्थिति बताना। अभी दो संस्करण उपयोग में हैं। IPv4 एक 32-बिट बाइनरी संख्या है, जिसे 192.168.1.1 जैसे डॉटेड डेसिमल रूप में लिखा जाता है। सिद्धांततः लगभग 4.3 अरब पते उपलब्ध हैं, लेकिन असमान आवंटन और निजी पता-रेंज के कारण व्यवहार में उपलब्ध संख्या काफी कम है। IPv6 128-बिट का है और कोलन से अलग किए गए हेक्साडेसिमल रूप में लिखा जाता है; इसका पता-स्थान लगभग 3.4×10³⁸ है, जो व्यवहार में हर डिवाइस को एक विशिष्ट पता देने के लिए पर्याप्त है।
पते का संस्करण आगे फिर महत्वपूर्ण होगा, क्योंकि वही तय करता है कि ट्रैफ़िक IPv6 के ज़रिए तय मार्ग को बायपास कर सकता है या नहीं।
क्या DNS रिज़ॉल्यूशन उसी रास्ते से जा रहा है?
DNS डोमेन नाम को पते में बदलता है। एक आम चूक यह है कि ट्रैफ़िक तो टनल से गुजरता है, लेकिन DNS अनुरोध स्थानीय ISP के रिज़ॉल्वर को भेजे जाते रहते हैं। ऐसी स्थिति में पेज पर दिखाई देने वाला एग्ज़िट सही लग सकता है, पर DNS रिकॉर्ड स्रोत बता देते हैं।
स्वयं-जाँच: किसी DNS लीक टेस्ट पेज को खोलें और देखें कि सूचीबद्ध रिज़ॉल्वर किन नेटवर्कों से संबंधित हैं। यदि स्थानीय ISP दिखता है, या रिज़ॉल्वर सेवा इच्छित एग्ज़िट क्षेत्र से स्पष्ट रूप से मेल नहीं खाती, तो DNS टनल का अनुसरण नहीं कर रहा। आप डेवलपर टूल्स के Network पैनल को खुला रखकर पेज कई बार रीफ़्रेश कर सकते हैं और सीधे स्थानीय रिज़ॉल्यूशन के संकेत देख सकते हैं।
टाइम ज़ोन और भाषा जैसे सहायक संकेत
यह बिंदु आसानी से छूट जाता है, क्योंकि यह नेटवर्क सेटिंग नहीं बल्कि स्वयं वातावरण से जुड़ा है। यदि एग्ज़िट स्थान एक देश की ओर इशारा करता है, लेकिन सिस्टम टाइम ज़ोन, ब्राउज़र इंटरफ़ेस भाषा और तारीख़ का फ़ॉर्मेट किसी दूसरे स्थान को दर्शाते हैं, तो लगातार बनी यह असंगति एक कमजोर संकेत बन जाती है। अकेला संकेत निर्णायक न हो, लेकिन कई संकेत मिलकर वातावरण को जोड़ने के लिए पर्याप्त हो सकते हैं।
स्वयं-जाँच: एग्ज़िट IP की लोकेशन की तुलना डिवाइस के टाइम ज़ोन, भाषा, तारीख़ के फ़ॉर्मेट और पसंदीदा कीबोर्ड लेआउट से करें। कई क्षेत्रों में काम करते समय हर वातावरण को एक संगत कॉन्फ़िगरेशन सेट होना चाहिए, न कि एक ही मशीन पर बार-बार टाइम ज़ोन बदलना चाहिए।
IPv6 सबसे आसानी से छूटने वाले रास्तों में से एक है
IPv6 से होने वाला लीक काफी छिपा हो सकता है। यदि टनल या प्रॉक्सी केवल IPv4 संभालता है, तो डिवाइस फिर भी IPv6 के माध्यम से सीधे बाहर जा सकता है, और टेस्ट पेज पर IPv6 पते की सिर्फ एक पंक्ति वास्तविक स्थान उजागर कर सकती है। कई वातावरणों में IPv6 डिफ़ॉल्ट रूप से चालू रहता है और उसकी प्राथमिकता अधिक होती है, इसलिए उपलब्ध होने पर ट्रैफ़िक स्वाभाविक रूप से उसी रास्ते को चुन सकता है।
स्वयं-जाँच: टेस्ट पेज पर IPv4 और IPv6 दोनों सेक्शन एक साथ देखें। यदि IPv6 आपके स्थानीय ISP का पता दिखाता है, जबकि IPv4 प्रॉक्सी एग्ज़िट दिखाता है, तो यह रास्ता खुला है। या तो IPv6 को भी उसी टनल से भेजें, या ऐसे वातावरण में इसे बंद करें जहाँ इसकी आवश्यकता नहीं है।
थर्ड-पार्टी स्क्रिप्ट और एक्सटेंशन
एनालिटिक्स कोड, विज्ञापन स्क्रिप्ट, ग्राहक-सहायता कॉम्पोनेंट, फ़ॉन्ट और CDN संसाधन वेबसाइट के मुख्य नेटवर्क मार्ग से बाहर भी अनुरोध भेज सकते हैं। ये अनुरोध हमेशा आपकी तय की हुई प्रॉक्सी नीतियों का पालन नहीं करते, और कुछ ऐसे डेटा के साथ जा सकते हैं जिन तक फ़्रंटएंड की पहुँच है। ब्राउज़र एक्सटेंशन भी इसी तरह काम करते हैं: जितने अधिक एक्सटेंशन, उतने अधिक कॉम्पोनेंट अनुरोध भेज सकते हैं; अस्पष्ट स्रोत वाले एक्सटेंशन विशेष सावधानी मांगते हैं।
स्वयं-जाँच: उसी पेज को प्राइवेट विंडो में खोलें, पहले एक्सटेंशन बंद रखकर और फिर चालू करके, और टेस्ट पेज के परिणामों की तुलना करें। डेवलपर टूल्स के Network पैनल में डोमेन के आधार पर फ़िल्टर करके सीधे स्थानीय कनेक्शन या ऐसे थर्ड-पार्टी डोमेन भी खोजे जा सकते हैं जो पेज से संबंधित नहीं हैं।
WebRTC को भी अलग से जाँचें
WebRTC रियल-टाइम ऑडियो और वीडियो संचार के लिए बनाया गया है और स्थानीय नेटवर्क जानकारी इकट्ठी कर सकता है। यदि प्रतिबंध पर्याप्त कड़े नहीं हैं, तो वेब पेज इसके माध्यम से स्थानीय या वास्तविक पते पढ़ सकता है। WebRTC को अक्सर IP लीक का पर्याय मान लिया जाता है, जबकि यह केवल एक रास्ता है। टेस्ट पेज आमतौर पर सार्वजनिक IP और WebRTC से उजागर IP दोनों दिखाते हैं; दोनों में अंतर जाँच का संकेत है।
सेटिंग एक-एक करके बंद करने से बेहतर है एग्ज़िट और वातावरण का मेल
ऊपर दिए गए कई रास्तों को अलग-अलग सेटिंग बंद करके रोका जा सकता है, लेकिन इस तरह मिला साफ़ कॉन्फ़िगरेशन नाज़ुक होता है। नेटवर्क बदलने, ब्राउज़र अपडेट करने या नया एक्सटेंशन लगाने पर कोई सेटिंग बिना सूचना के फिर डिफ़ॉल्ट पर लौट सकती है।
अधिक स्थिर तरीका उलटे क्रम में काम करना है: पहले तय करें कि वातावरण किस स्थान के उपयोगकर्ता को दर्शाएगा, फिर एग्ज़िट, DNS, टाइम ज़ोन, भाषा, IPv6 स्थिति और फिंगरप्रिंट पैरामीटर को एक ही संगत सेट के रूप में कॉन्फ़िगर करें। टेस्ट का उद्देश्य केवल यह पता लगाना नहीं कि कौन-सा स्विच खुला रह गया, बल्कि यह सत्यापित करना है कि पूरे वातावरण के सभी हिस्से एक-दूसरे से मेल खाते हैं।
जैसे-जैसे खातों की संख्या बढ़ती है, इस संगति को हाथ से बनाए रखना लगभग असंभव हो जाता है। PurpleMark जैसे मल्टी-अकाउंट वातावरण टूल प्रॉक्सी सेटिंग, Cookie, लोकल स्टोरेज और फिंगरप्रिंट पैरामीटर को एक ही ब्राउज़र वातावरण से बाँधते हैं। वातावरण खोलते ही वही सेटिंग लागू होती हैं, जिससे एक खाता, एक वातावरण और एक एग्ज़िट का संबंध स्थिर रखने और कॉन्फ़िगरेशन त्रुटियों से होने वाले अनचाहे खुलासे को कम करने में मदद मिलती है।
एक शर्त फिर भी महत्वपूर्ण है: नेटवर्क एग्ज़िट को छिपाना किसी प्लेटफ़ॉर्म के खाता पहचान या खातों की संख्या से जुड़े नियम नहीं बदलता। वातावरण अलग करने से खातों को एक-दूसरे को प्रभावित करने से रोका जा सकता है, लेकिन खाता संरचना को फिर भी प्लेटफ़ॉर्म के नियमों का पालन करना होगा।
अक्सर पूछे जाने वाले सवाल
वेबसाइट किसी व्यक्ति को कैसे पहचानती है? अनुरोधों का स्रोत IP दर्ज करने के अलावा वेबसाइटें Cookie, ब्राउज़र फिंगरप्रिंट, WebRTC और DNS रिज़ॉल्यूशन मार्गों को मिलाकर देख सकती हैं, इसलिए सिर्फ IP बदलना अक्सर पर्याप्त नहीं होता।
क्या IP बदलने से वातावरण सुरक्षित हो जाता है? ज़रूरी नहीं। यदि कई खातों में फिंगरप्रिंट, टाइम ज़ोन, भाषा और फ़ॉन्ट बहुत समान हैं, तो प्लेटफ़ॉर्म उन्हें फिर भी जोड़ सकता है।
कितनी बार जाँच करनी चाहिए? नेटवर्क या प्रॉक्सी बदलने पर, नया खाता वातावरण जोड़ने पर, और रोज़मर्रा के संचालन के दौरान समय-समय पर जाँच करें।
सभी बिंदुओं को साथ देखें
IP लीक बहुत कम मामलों में किसी के डिवाइस में घुसने से होता है। अधिकतर कारण कॉन्फ़िगरेशन की खामियाँ होती हैं: टनल पूरे ट्रैफ़िक को कवर नहीं करता, DNS अलग रास्ते से जाता है, IPv6 सीधे जुड़ता है, टाइम ज़ोन और भाषा एग्ज़िट से मेल नहीं खाते, या थर्ड-पार्टी स्क्रिप्ट संकेत उजागर करती हैं। कौन-सा रास्ता लीक कर रहा है, यह जानना स्विचों की सूची याद रखने से अधिक उपयोगी है; और संगत एग्ज़िट व वातावरण का संयोजन किसी एक सुविधा को बंद करने से अधिक मज़बूत है.


