WebRTC उम्मेदवार सूचीले तपाईंको VPN बारे के खुलासा गर्छ
होस्ट, सर्भर-रिफ्लेक्सिभ वा रिले उम्मेदवारले ठेगाना कहाँबाट आयो भन्छ। मिडियाले वास्तवमा कुन बाटो प्रयोग गर्यो भन्ने कुरा केवल छानिएको ICE जोडीले भन्छ।
जब WebRTC परीक्षण पृष्ठले 172.20.4.15 छाप्छ, तब उसले त्यो सञ्जालमा स्थानीय इन्टरफेस रहेको जानिसकेको हुन्छ। यो वास्तविक खुलासा हो, र यो «मिडिया VPN निकासबाट बाहिर गयो» भन्ने उही निष्कर्ष होइन। उम्मेदवार खोजी र प्याकेट रुटिङ अलग-अलग संयन्त्र हुन्, र अधिकांश लिक रिपोर्टले तिनलाई एउटै फैसलामा मिलाउँछन्। तपाईं कुन हेर्दै हुनुहुन्छ भन्नेले उपाय निर्धारण गर्छ।
केही पठाउनुअघि नै सङ्कलन हुन्छ
ब्राउजरले स्थानीय इन्टरफेसहरू सूचीबद्ध गर्छ, STUN सर्भरमा बाइन्डिङ अनुरोध पठाउँछ र TURN सर्भरसँग बाँडफाँट माग्छ, त्यसपछि नतिजा सत्र विवरणमा उम्मेदवार लाइनका रूपमा लेख्छ। यी सबै कुनै कल, मिडिया र विपक्षी पक्षबिना पूरा हुन्छ। त्यसैले उम्मेदवारको सूची खोजीको अभिलेख हो, ढुवानीको होइन।
आधुनिक ब्राउजरले होस्ट उम्मेदवारको शाब्दिक ठेगाना mDNS नाम .local ले बदल्न सक्छन्, जसले पृष्ठले निजी IP पढ्न सक्दैन। स्थानीय सञ्जालले त्यो नाम समाधान गर्ने मल्टिकास्ट प्रश्नहरू अझै देख्छ, अर्थात् ठेगाना अनुप्रयोगबाट लुकाइन्छ, तारबाट हटाइँदैन।
क्रम पनि महत्त्वपूर्ण छ: नयाँ पृष्ठ लोडले नयाँ समूह सङ्कलन गर्छ, फरक TURN बाँडफाँट र सम्भवतः फरक रिफ्लेक्सिभ म्यापिङसहित। नमिल्ने दुई रन अनिवार्यतः दुई फरक कन्फिगरेसन हुन् भन्ने छैन।
तीन प्रकारका उम्मेदवार, तीन प्रकारका प्रमाण
प्रत्येक लाइन फरक अवलोकनबाट आउँछ। प्रत्येक प्रकारले फरक प्रश्नको उत्तर दिन्छ, र तालिकाले तिनलाई के स्थापित गर्न सक्छन् र सक्दैनन् भन्ने आधारमा छुट्याउँछ।
| Candidate | Derived from | What it establishes | What it cannot establish |
|---|---|---|---|
| Host | An interface on the device | A local address exists in that network | That the peer can reach it |
| Server-reflexive | A STUN binding response | How a NAT mapped this source | Which exit the media will use |
| Peer-reflexive | A connectivity check that arrived | An address seen by the far side | That it was ever advertised |
| Relay | A TURN allocation | The relay server accepted the session | That the relay carries the call |
रिले उम्मेदवारलाई प्रायः प्रयोगकर्ताको इन्टरनेट ठेगाना ठानिन्छ। त्यो TURN सर्भरको हो, र त्यसको उपस्थितिले रिले उपलब्ध थियो भन्ने देखाउँछ, ब्राउजरले त्यो छान्यो भन्ने होइन। उही भ्रम होस्ट उम्मेदवारमा विपरीत दिशामा चल्छ, जहाँ mDNS नामले ठेगाना पृष्ठबाट लुकाउँछ जबकि सञ्जालले प्रश्नहरू अझै बोक्छ। मान पढ्नुअघि प्रकार पढ्नुहोस्।
छानिएको जोडीले रुटिङ प्रश्नको उत्तर दिन्छ
ICE ले प्रत्येक स्थानीय उम्मेदवारलाई प्रत्येक टाढाको उम्मेदवारसँग जोड्छ, प्रत्येक जोडीमा जडान परीक्षण चलाउँछ र विजेता मनोनयन गर्छ। त्यही मनोनीत जोडी, जो ब्राउजरको आफ्नै डायग्नोस्टिक्समा देखिन्छ, ले मिडिया बोक्छ। सूचीमा बाँकी सबै हारेको सम्भावना हो।
विजेताले तपाईंलाई बाटोको आकार बताउँछ। रिले-देखि-रिले TURN सर्भरबाट जान्छ, होस्ट जोडी स्थानीय सञ्जालमै रहन्छ, र सर्भर-रिफ्लेक्सिभ जोडी NAT बाट सिधै जान्छ। यही त्यो तथ्य हो जो VPN जाँचलाई चाहिन्छ, र यो ठेगाना सूचीभन्दा फरक तथ्य हो। एउटै उम्मेदवार सूची भएका दुई कलले फरक जोडी लिन सक्छन्।
नछानिएका उम्मेदवार पनि सङ्कलन भए, र सङ्कलन मेसिन छोड्ने सञ्जाल ट्राफिक हो। अन्ततः रिले प्रयोग गरेको कलको अर्थ सूची बन्दै गर्दा केही पनि खुलासा भएन भन्ने होइन।
नियन्त्रणहरू लक्ष्यसँग मिल्छन्, लिक स्कोरसँग होइन
WebRTC को IP ह्यान्डलिङ विनिर्देश ले धेरै नीतिहरू वर्णन गर्छ: पूर्वनिर्धारित रुट बोक्ने इन्टरफेस मात्र प्रयोग गर्ने, सबै इन्टरफेस प्रयोग गर्ने, र प्रोक्सी नभएको UDP बन्द गर्ने ताकि ट्राफिक रिले वा प्रोक्सीबाट जानुपर्छ। प्रत्येकले जडान र ढिलाइलाई फरक प्रकारको जोखिमसँग साट्छ। ब्राउजरले कुन लागू गर्छ र कुन नाममा, त्यो प्लेटफर्म र संस्करणअनुसार फरक पर्छ।
नीति लक्ष्यबाट छान्नुहोस्। पृष्ठबाट स्थानीय ठेगाना लुकाउनु एउटा लक्ष्य हो; सिधा पियर-देखि-पियर ट्राफिक रोक्नु अर्को हो; प्रत्येक प्याकेट सुरुङभित्र राख्नु तेस्रो हो। पहिलो मुख्यतः अनुप्रयोगले के सिक्छ भन्नेसँग सम्बन्धित छ, दोस्रो कुन बाटोलाई अनुमति छ भन्नेसँग, र तेस्रो प्लेटफर्म वा VPN को सीमामा पनि लागू गर्नुपर्छ।
तपाईं जुनसुकै नियन्त्रण छान्नुहोस्, दुवै आधा जाँच्नुहोस्: सङ्कलन परीक्षण चलाएर उम्मेदवार प्रकार रेकर्ड गर्नुहोस्, त्यसपछि वास्तविक सत्रमा छानिएको जोडी जाँच्नुहोस्। सिधा मिडिया बाटो भएको सफा ठेगाना सूची पनि तपाईंले चाहेको नभएको बाटो हो।