VPN विरुद्ध TURN रिले: WebRTC कॉल प्रत्यक्षात कोण वाहून नेते?
बोगदा ICE जो मार्ग पाहतो तो बदलतो; तो कधीही रिले वाटप करत नाही किंवा सिग्नलिंग देत नाही. VPN एग्रेस आणि TURN सर्व्हर प्रत्येकी काय देतात याची तुलना करा.
पृष्ठ VPN द्वारे लोड होते, पण कॉल कधीही जोडली जात नाही: एकाच पत्ता-पट्टीत दोन वेगवेगळ्या बिघाड्या. बोगद्याने ब्राउझर वापरतो तो मार्ग बदलला; तो सिग्नलिंग सेवा, STUN सर्व्हर किंवा रिले झाला नाही, आणि ICE कोणती उमेदवार जोडी निवडेल हेही तो ठरवत नाही. प्रत्येक घटक जे काम करतो ते वेगळे करणे हेच अस्पष्ट “WebRTC अडवले आहे” याला नेमक्या बिघाडात बदलते.
चार कामे, त्यातील बोगदा फक्त एकाला स्पर्श करतो
अ‍ॅप्लिकेशन कोणत्या तरी सिग्नलिंग व्यवस्थेमार्फत सत्र-माहितीची देवाणघेवाण करते, आणि हे पहिले काम. ICE उमेदवार पत्ते गोळा करते आणि एक काम करेपर्यंत जोड्या तपासते, हे दुसरे. STUN साथीदाराला त्याचा रहदारी बाहेरून कसा दिसतो हे कळू देते, आणि TURN जिथे थेट मार्ग नाही अशा प्रकरणांसाठी रिले वाटप करते. त्या चार भूमिका वेगवेगळ्या आहेत, आणि VPN त्यांना भेटणाऱ्या पत्त्यांवर व गाळणीवर परिणाम करतो, त्यातली कोणतीही स्वतः पुरवत नाही.
म्हणून यशस्वी लॉगिन मीडिया-मार्गाबद्दल काहीही सांगत नाही. सिग्नलिंग सहसा पृष्ठ आधीच वापरत असलेल्या त्याच HTTPS वर, पोर्ट 443 वर जाते, तर मीडिया UDP ने पूर्णपणे वेगळ्या गंतव्याकडे जाऊ शकतो.
खाजगी पत्ता-रचना गोंधळ वाढवते. बोगदा-पत्ता साथीदाराला तेव्हाच उपयुक्त असतो जेव्हा त्याला तिकडे परत जाण्याचा हेतू केलेला मार्ग असतो; खाजगी असणे परस्पर पोहोचीचा पुरावा नाही, आणि तपासता येऊ न शकणारे उमेदवार बाजूला काढताना ब्राउझर ते तसे गृहीत धरत नाहीत. तुम्हाला स्थानिक वाटणारा उमेदवार दुसऱ्या बाजूने तपासण्यायोग्य नसू शकतो. बोगदा मीडिया टाकून देत आहे असा निष्कर्ष काढण्यापूर्वी ती तफावत बाजूला काढण्यासारखी आहे.
VPN एग्रेसची TURN रिलेशी तुलना करा
दोन्ही पॅकेट पुढे पाठवतात, म्हणून त्यांची गल्लत होते, आणि वरचा तुलना-तक्ता वैशिष्ट्यांची यादी म्हणून नव्हे तर स्तंभ-दर-स्तंभ वाचण्यासारखा आहे. रिले वाटप ही प्रमाणित विनंतीने तयार होणारी प्रति-सत्र वस्तू आहे; बोगदा हा मार्ग आहे. एकाकडे संपणारी ओळख आहे, दुसऱ्याकडे पोहोचण्यायोग्य किंवा नसणारा साथीदार-पत्ता आहे.
| Component | What it contributes | What it needs to work | What it cannot do |
|---|---|---|---|
| VPN exit | Changes the observed mapping and the route packets take | A working tunnel and a policy that permits the media transport | Allocate a relay or supply signaling |
| STUN server | Reports the mapped address a peer appears to use | Reachability from the client, on its configured transport | Carry media when a direct path fails |
| TURN server | Relays media through an authenticated allocation | Valid credentials, an allowed transport and sufficient capacity | Fix a missing ICE policy or an unauthorized client |
| Signaling channel | Carries offers, answers and candidate lists | Both peers reaching the same application endpoint | Establish connectivity by itself |
पोर्ट क्रमांक फरकाला ठोस बनवतात. TURN डीफॉल्टने UDP व TCP साठी 3478 वर आणि TLS साठी 5349 वर ऐकते, आणि जे नेटवर्क 443 ला परवानगी देते पण ते पोर्ट वगळते, तिथे ब्राउझिंग सामान्य चालू असतानाही रिले केलेले कॉल अयशस्वी होतील. VPN चा पोर्ट बदलल्याने त्यातले काहीही कॉन्फिगर होत नाही, कारण महत्त्वाचे पोर्ट बोगद्याचे नाहीत, रिले सेवेचे आहेत.
निदान वाचा, मग कॉल तपासा
ब्राउझर पॅकेट कॅप्चरशिवाय आवश्यक माहिती दाखवतात. तुमच्या ब्राउझरसाठी WebRTC निदान पृष्ठ उघडा, कॉल करा, आणि गोळा केलेल्या यादीऐवजी निवडलेली उमेदवार-जोडी वाचा: कोणते स्थानिक व दूरस्थ उमेदवार प्रकार निवडले, कोणत्या ट्रान्सपोर्ट व पत्ता-कुटुंबावर, आणि मार्ग थेट आहे की रिले केलेला.
दोन वाचन आधीच जाणून घेण्यासारखी आहेत. निवडलेली जोडी खाजगी पत्त्यांवर होस्ट-ते-होस्ट असेल, तर मीडिया तर्क करता येईल अशा मार्गावर राहतो; रिले-ते-रिले असेल, तर कॉल रिले क्षमता खर्च करतो आणि त्या सेवेच्या उपलब्धतेवर अवलंबून असतो. निवडलेल्या जोडीशिवाय “तपासत आहे” वर थांबणाऱ्या बिघाडाचा अर्थ उमेदवार गोळा झाले, पण एकही जोडणी-तपासणीत उत्तीर्ण झाला नाही.
मग त्याच कॉलमधील तेच दोन टोक फक्त एक मंजूर अट बदलून तुलना करा, आणि निकाल “जोडले” निर्देशकावर नव्हे तर दुहेरी मीडिया किंवा डेटावर स्वीकारा. उमेदवार संग्रह अनेक अशा प्रकरणांत यशस्वी होतो ज्यात एकही ऑडिओ फ्रेम वाहत नाही. बदलाच्या दुसऱ्या बाजूला कॉल पुन्हा करा आणि दोन्ही निदान कॅप्चर ठेवा, कारण दोन फेऱ्यांची तुलना कोणतीही एकटी वाचण्यापेक्षा अधिक माहिती देते. तीच टोके, तोच कोडेक, एक बदललेला चल.
जे अ‍ॅप्लिकेशन जाणीवपूर्वक आपले ICE ट्रान्सपोर्ट धोरण relay वर ठेवते, ते फक्त रिले उमेदवार मागते. ते सेटिंग रिले तयार करत नाही आणि गहाळ ओळख दुरुस्त करत नाही; ते आवश्यकता स्पष्ट करते, जे साइटने निवडलेल्या धोरणासाठी कोणी VPN ला दोष देतो तेव्हा उपयुक्त ठरते.
गोपनीयतेचा दावा पुराव्यांइतकाच मर्यादित ठेवा
उमेदवारांचे उघड होणे ब्राउझर व अ‍ॅप्लिकेशन धोरणांवर अवलंबून आहे, फक्त बोगद्याच्या स्थितीवर नाही, आणि W3C चे साथीदार-जोडणी तपशील IP हाताळणीला स्वतंत्र बाब मानते. म्हणून जोडलेला VPN कॉल फक्त एक निवडलेला पत्ता उघड करतो असे वचन देण्यासाठी दुर्बल आधार आहे. एकाच बोगद्यामागील दोन साथीदार होस्ट कधीही न सोडणारा मार्गही निवडू शकतात, जे एकाच वेळी गोपनीयतेची सुधारणा आणि जोडणीची मर्यादा आहे.
तुम्ही नेमके जे सांगू शकता ते अधिक मर्यादित आणि अधिक उपयुक्त आहे: कोणती उमेदवार-जोडी निवडली गेली, कोणत्या ट्रान्सपोर्टने ती वाहून नेली, आणि तो मार्ग बोगद्याच्या आत राहिला का. चालणाऱ्या आणि अयशस्वी कॉलसाठी या तीन तथ्यांची नोंद ठेवा, आणि फरक सहसा दुरुस्त करावयाच्या घटकाचे नाव सांगतो.
जोडणी काम करू लागल्यावर कार्यक्षमता पोहोचीपासून वेगळी करा. हानी, विलंब, रांग आणि MTU सर्व योग्य उमेदवार-जोडीच्या खालच्या बाजूला असतात, आणि तुटक्या कॉलला जोडणी-बिघाड मानणे तुम्हाला कारणाशिवाय उमेदवार-यादीकडे परत पाठवते.