प्रॉक्सी HTTP ट्रैफ़िक को संभाल सकता है, जबकि WebRTC STUN/ICE के जरिए UDP पर candidate addresses का आदान-प्रदान करता है। यह लेख बताता है कि local और private-network addresses कब उजागर हो सकते हैं और network exit व browser environment को एक-दूसरे के अनुरूप कैसे रखा जाए।
प्रॉक्सी सेट हो चुका है और IP जाँच पेज पर अपेक्षित क्षेत्र व इंटरनेट सेवा प्रदाता दिखाई दे रहे हैं। नेटवर्क पहचान सही लगती है। लेकिन leak test खोलते ही WebRTC वाला भाग लाल हो जाता है और आपके वास्तविक इंटरनेट कनेक्शन का पता दिखा सकता है।
तुरंत प्रॉक्सी बदलने की ज़रूरत नहीं है। अधिकतर मामलों में समस्या प्रॉक्सी की गुणवत्ता में नहीं, बल्कि उस ट्रैफ़िक में होती है जिसे वह नियंत्रित नहीं करता।
प्रॉक्सी HTTP संभालता है, जबकि WebRTC दूसरा रास्ता लेता है
प्रॉक्सी नेटवर्क लेयर पर काम करता है। चाहे वह ब्राउज़र एक्सटेंशन हो या सिस्टम-लेवल टनल, वह HTTP/HTTPS requests को संभालता है और उस ट्रैफ़िक को प्रॉक्सी exit से भेजता है।
WebRTC अलग तरह से काम करता है। यह ब्राउज़र में बनी real-time communication क्षमता है। ऑडियो/वीडियो कॉल और P2P ट्रांसफ़र के लिए उपयुक्त रास्ता खोजने हेतु ब्राउज़र बाहरी सर्वरों को सक्रिय रूप से STUN queries भेज सकता है — मूल रूप से यह पूछते हुए, “आपको मेरा कौन-सा पता दिखाई देता है?” — और फिर जवाबों को ICE candidates के रूप में व्यवस्थित करके वेबपेज को दे सकता है। ये queries UDP का उपयोग करती हैं, जो HTTP टनल से स्वतंत्र चैनल है।
इससे असंगति पैदा होती है: वेब requests प्रॉक्सी से बाहर जाती हैं, जबकि ब्राउज़र उसी समय local address भी बता सकता है। यह मान लेना कि प्रॉक्सी कॉन्फ़िगर होते ही पूरी network identity अपने-आप साफ हो जाती है, इस समस्या का सबसे सामान्य शुरुआती बिंदु है।
केवल public IP ही उजागर नहीं हो सकता
ICE candidates में आम तौर पर दो प्रकार के address होते हैं। पहला public address है, यानी आपके वास्तविक इंटरनेट प्रदाता का exit। दूसरा local address है, जैसे 192.168 से शुरू होने वाला private address; कभी-कभी virtual network adapter का address भी दिखाई दे सकता है।
केवल private-network address अपने आप में बहुत कुछ साबित नहीं करता, क्योंकि लगभग हर कंप्यूटर में ऐसा address होता है। लेकिन यह इतना स्थिर हो सकता है कि कई accounts में candidate addresses बार-बार एक जैसे मिलने पर platform को उन्हें एक ही device से जोड़ने के लिए एक अतिरिक्त signal मिल जाए। Public address अधिक सीधा संकेत है: यह वास्तविक provider और लगभग भौगोलिक क्षेत्र की ओर इशारा करता है। कितनी बारीकी तक जानकारी मिलेगी, यह platform के implementation पर निर्भर है, लेकिन दिशा स्पष्ट है: address जितना वास्तविक होगा, संबंध बनाना उतना आसान होगा।
वेबसाइट इसे वास्तव में कब पढ़ सकती है?
हर वेबसाइट ऐसा करने की कोशिश नहीं करती। Address exchange के लिए page को सक्रिय रूप से RTCPeerConnection object बनाना पड़ता है, जिसकी सामान्य content pages को आम तौर पर ज़रूरत नहीं होती।
यह काम प्रायः कुछ प्रकार की sites करती हैं: real-time communication वाली services, जैसे video meetings, online customer support और कुछ live-streaming pages; वे sites जो advertising या anti-fraud पर बहुत निर्भर हैं; और वे platforms जिनके risk-control systems अधिक विकसित हैं। यह पढ़ना interface के दिखाई न देने वाले हिस्से में होता है, और data इकट्ठा होने के बाद उसका उपयोग कैसे होगा, इसकी अलग सूचना आम तौर पर नहीं मिलती।
एक स्थिति वेबसाइट से स्वतंत्र भी होती है। प्रॉक्सी के दोबारा जुड़ने या node बदलने के छोटे से अंतराल में ब्राउज़र की STUN request local network से निकल सकती है। समय बहुत कम होता है, लेकिन एक बार रिकॉर्ड होने के लिए पर्याप्त है।
असफल होने की तीन सामान्य स्थितियाँ
Browser-extension प्रकार के proxies आम तौर पर केवल HTTP/HTTPS requests को अपने नियंत्रण में लेते हैं। UDP उनकी सीमा से बाहर रहता है, और interface में “global” विकल्प चुनने से यह नहीं बदलता।
System-level global proxy अधिक पूर्ण दिखाई देता है क्योंकि वह पूरे device का traffic कवर करता है। लेकिन candidate addresses का संग्रह सीधे local network interface से bind हो सकता है और system routing table को bypass कर सकता है, जिससे इस चरण में tunnel में कमी रह जाती है।
तीसरी समस्या केवल तकनीकी नहीं है; risk controls भी समय के साथ बदलते हैं। Risk-control systems WebRTC addresses को accounts को जोड़ने वाले कई signals में से एक के रूप में अधिक इस्तेमाल कर रहे हैं। जो data पहले मापा नहीं जाता था या अनदेखा किया जाता था, वह अब निर्णय में शामिल हो सकता है।
लक्ष्य एकसमान exit है, केवल एक switch बंद करना नहीं
कुछ सामान्य तरीके हैं। यदि किसी workflow को real-time communication की बिल्कुल आवश्यकता नहीं है, तो WebRTC को disable करना सबसे सरल विकल्प है। इसकी कीमत यह है कि video calls और online customer support जैसी सुविधाएँ भी काम नहीं करेंगी।
यदि ये सुविधाएँ बनाए रखनी हों, तो सामान्य तरीका यह है कि WebRTC layer से लौटने वाला address proxy exit के अनुरूप हो। अधिक मजबूत तरीका STUN requests को भी proxy channel से forward करना है ताकि interface local address को उजागर न करे। यदि P2P या video calls चाहिए, तो केवल HTTP layer ही नहीं, पूरा UDP traffic proxy से गुजरना चाहिए।
एक सामान्य गलती यह मानना है कि सिर्फ WebRTC बंद करने से पूरा environment साफ हो जाता है। वास्तव में network exit, DNS resolution, IP ownership और ASN, time zone व भाषा, और device characteristics का आपस में संगत होना ज़रूरी है। इनमें से किसी एक में भी mismatch हो तो anomalous signal बन सकता है; WebRTC केवल उन चीज़ों में से एक है जिन्हें सबसे आसानी से नज़रअंदाज़ किया जाता है।
जाँच सरल है। Node बदलने के बाद एक बार और environment का सामान्य उपयोग शुरू करने से पहले एक बार leak test खोलें। देखें कि WebRTC section proxy exit, local address या वास्तविक public address में से क्या दिखा रहा है। सामान्य IP lookup इस जानकारी को नहीं दिखाता।
Browser-engine-level environment isolation हर environment के लिए अलग WebRTC address policy तय कर सकता है और उसे उसी environment के network exit से जोड़ सकता है। PurpleMark इसी प्रकार की क्षमता देता है। यदि कई environments एक ही exit साझा करते हैं, या उनकी address policies आपस में संगत नहीं हैं, तो isolation का लाभ बहुत कम हो जाता है।
यह केवल तकनीकी सिद्धांत की व्याख्या है। संबंधित tools का उपयोग platform rules और स्थानीय कानूनों का पालन करते हुए करें।
