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 च्या सीमेवरही लागू करावे लागते.
तुम्ही कोणतेही नियंत्रण निवडा, दोन्ही अर्धे तपासा: संकलन चाचणी चालवा आणि उमेदवार प्रकार नोंदवा, नंतर खऱ्या सत्रादरम्यान निवडलेली जोडी तपासा. थेट मीडिया मार्ग असलेली स्वच्छ पत्ता यादीही तुम्ही हेतू न केलेला मार्ग आहे.