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