जब कोई WebRTC परीक्षण पृष्ठ 172.20.4.15 छापता है, तब उसने जान लिया है कि उस नेटवर्क पर एक स्थानीय इंटरफ़ेस मौजूद है। यह वास्तविक खुलासा है, और यह «मीडिया VPN एग्ज़िट से बाहर गया» वाला वही निष्कर्ष नहीं है। उम्मीदवार खोज और पैकेट रूटिंग अलग-अलग तंत्र हैं, और अधिकांश लीक रिपोर्ट उन्हें एक ही फ़ैसले में मिला देती हैं। आप किनमें से कौन-सा देख रहे हैं, यही उपाय तय करता है।

कुछ भी भेजे जाने से पहले संग्रह होता है

ब्राउज़र स्थानीय इंटरफ़ेस की सूची बनाता है, STUN सर्वर को बाइंडिंग अनुरोध भेजता है और TURN सर्वर से आवंटन माँगता है, फिर परिणामों को सत्र विवरण में उम्मीदवार पंक्तियों के रूप में लिखता है। यह सब बिना किसी कॉल, बिना मीडिया और बिना किसी साथी के पूरा हो जाता है। इसलिए उम्मीदवारों की सूची खोज का अभिलेख है, परिवहन का नहीं।

आधुनिक ब्राउज़र होस्ट उम्मीदवार के शाब्दिक पते को mDNS नाम .local से बदल सकते हैं, ताकि पृष्ठ निजी IP न पढ़ सके। स्थानीय नेटवर्क अब भी उन मल्टीकास्ट क्वेरी को देखता है जो उस नाम को हल करती हैं, यानी पता एप्लिकेशन से छिपाया जाता है, तार से हटाया नहीं जाता।

क्रम भी मायने रखता है: नया पृष्ठ लोड नया समुच्चय एकत्र करता है, भिन्न TURN आवंटन और संभवतः भिन्न रिफ़्लेक्सिव मैपिंग के साथ। जो दो रन असहमत हों, ज़रूरी नहीं कि वे दो भिन्न कॉन्फ़िगरेशन हों।

तीन प्रकार के उम्मीदवार, तीन तरह के प्रमाण

हर पंक्ति किसी भिन्न अवलोकन से आती है। हर प्रकार भिन्न प्रश्न का उत्तर देता है, और तालिका उन्हें इस आधार पर अलग करती है कि वे क्या सिद्ध कर सकते हैं और क्या नहीं।

CandidateDerived fromWhat it establishesWhat it cannot establish
HostAn interface on the deviceA local address exists in that networkThat the peer can reach it
Server-reflexiveA STUN binding responseHow a NAT mapped this sourceWhich exit the media will use
Peer-reflexiveA connectivity check that arrivedAn address seen by the far sideThat it was ever advertised
RelayA TURN allocationThe relay server accepted the sessionThat the relay carries the call

रिले उम्मीदवार को अक्सर उपयोगकर्ता का इंटरनेट पता समझ लिया जाता है। यह TURN सर्वर का है, और इसकी उपस्थिति दिखाती है कि कोई रिले उपलब्ध था, यह नहीं कि ब्राउज़र ने उसे चुना। यही भ्रम होस्ट उम्मीदवारों के साथ उलटी दिशा में चलता है, जहाँ mDNS नाम पते को पृष्ठ से छिपाता है जबकि नेटवर्क अब भी क्वेरी ढोता है। मान पढ़ने से पहले प्रकार पढ़ें।

चुना गया युग्म रूटिंग प्रश्न का उत्तर देता है

ICE हर स्थानीय उम्मीदवार को हर दूरस्थ उम्मीदवार से जोड़ता है, हर युग्म पर कनेक्टिविटी जाँच चलाता है और एक विजेता नामित करता है। वही नामित युग्म, जो ब्राउज़र के अपने डायग्नोस्टिक्स में दिखता है, मीडिया ढोता है। सूची में बाकी सब एक ऐसी संभावना है जो हार गई।

विजेता आपको मार्ग का आकार बताता है। रिले-से-रिले TURN सर्वर से होकर जाता है, होस्ट युग्म स्थानीय नेटवर्क पर रहता है, और सर्वर-रिफ़्लेक्सिव युग्म NAT से सीधे जाता है। यही वह तथ्य है जो VPN जाँच को चाहिए, और यह पता सूची से भिन्न तथ्य है। एक जैसी उम्मीदवार सूचियों वाली दो कॉल भिन्न युग्म ले सकती हैं।

न चुने गए उम्मीदवार भी एकत्र हुए थे, और संग्रह वह नेटवर्क ट्रैफ़िक है जो मशीन से बाहर जाता है। जिस कॉल ने अंततः रिले इस्तेमाल किया, इसका अर्थ यह नहीं कि सूची बनते समय कुछ भी उजागर नहीं हुआ।

नियंत्रण लक्ष्यों से मेल खाते हैं, लीक स्कोर से नहीं

WebRTC IP-हैंडलिंग विनिर्देश कई नीतियाँ बताता है: केवल वही इंटरफ़ेस इस्तेमाल करना जो डिफ़ॉल्ट रूट ढोता है, सभी इंटरफ़ेस इस्तेमाल करना, और प्रॉक्सी-रहित UDP बंद करना ताकि ट्रैफ़िक को रिले या प्रॉक्सी से गुज़रना पड़े। हर एक कनेक्टिविटी और विलंब के बदले अलग तरह का जोखिम लेता है। ब्राउज़र कौन-सी लागू करता है और किस नाम से, यह प्लेटफ़ॉर्म और संस्करण के अनुसार बदलता है।

नीति लक्ष्य से चुनें। पृष्ठ से स्थानीय पते छिपाना एक लक्ष्य है; सीधा पीयर-टू-पीयर ट्रैफ़िक रोकना दूसरा है; हर पैकेट को टनल के भीतर रखना तीसरा है। पहला मुख्यतः इस बारे में है कि एप्लिकेशन क्या सीखता है, दूसरा इस बारे में कि कौन-सा मार्ग अनुमत है, और तीसरा प्लेटफ़ॉर्म या VPN की सीमा पर भी लागू करना होगा।

आप जो भी नियंत्रण चुनें, दोनों आधे जाँचें: संग्रह परीक्षण चलाएँ और उम्मीदवार प्रकार दर्ज करें, फिर वास्तविक सत्र के दौरान चुने गए युग्म का निरीक्षण करें। सीधे मीडिया मार्ग वाली स्वच्छ पता सूची भी एक ऐसा मार्ग है जिसकी आपने मंशा नहीं की थी।

संबंधित लेख