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 सब एक सही उम्मीदवार जोड़ी के नीचे की ओर हैं, और टूटती हुई कॉल को कनेक्टिविटी विफलता मानना आपको बिना कारण उम्मीदवार सूची की ओर लौटा देता है।