STUN Server: यह क्या है, कैसे काम करता है और कहाँ उपयोग होता है

STUN Server क्या है

STUN Server (Session Traversal Utilities for NAT) एक नेटवर्क सेवा है जो RFC 5389 में परिभाषित और RFC 8489 में अद्यतन प्रोटोकॉल पर काम करती है। STUN सर्वर का मुख्य कार्य क्लाइंट को उसके स्वयं के सार्वजनिक IP पते और पोर्ट के बारे में जानकारी प्रदान करना है जैसा कि बाहरी नेटवर्क से देखा जाता है, साथ ही क्लाइंट और इंटरनेट के बीच NAT डिवाइस के प्रकार का निर्धारण करना है।

STUN आर्किटेक्चर में दो घटक शामिल हैं: एक STUN क्लाइंट जो एप्लिकेशन (जैसे ब्राउज़र या मूल WebRTC ऐप) में एम्बेडेड होता है, और एक STUN सर्वर जो सार्वजनिक नेटवर्क में तैनात होता है। क्लाइंट सर्वर को STUN बाइंडिंग रिक्वेस्ट भेजता है, जो अपने उत्तर में अनुरोध के स्रोत IP पते और पोर्ट को इंगित करता है — अर्थात् क्लाइंट के सार्वजनिक पते जैसा कि सर्वर देखता है। इस डेटा की अपने स्थानीय पतों से तुलना करके, क्लाइंट यह निर्धारित कर सकता है कि उसके नेटवर्क में किस प्रकार का NAT उपयोग हो रहा है।

STUN प्रोटोकॉल

STUN UDP (डिफ़ॉल्ट रूप से पोर्ट 3478) या TCP (पोर्ट 3478 या TLS के लिए 5349) पर काम करता है। STUN संदेश में 20-बाइट का हेडर और चर संख्या में विशेषताएँ होती हैं। हेडर में संदेश प्रकार (बाइंडिंग रिक्वेस्ट, बाइंडिंग रिस्पॉन्स, बाइंडिंग एरर रिस्पॉन्स), लंबाई और एक अद्वितीय लेन-देन पहचानकर्ता (96 बिट) होता है जो अनुरोधों और प्रतिक्रियाओं का मिलान करने की अनुमति देता है। प्रत्येक बाइंडिंग रिस्पॉन्स में XOR-MAPPED-ADDRESS विशेषता होती है — क्लाइंट का बाहरी पता, जो STUN ट्रैफ़िक इंटरसेप्शन पर आधारित हमलों से बचाने के लिए मास्किंग के साथ एन्कोडेड होता है।

STUN सर्वर कैसे काम करता है

STUN सर्वर एक सरल अनुरोध-प्रतिक्रिया प्रोटोकॉल पर काम करता है। NAT के पीछे का क्लाइंट बाइंडिंग रिक्वेस्ट बनाता है और इसे STUN सर्वर को भेजता है। सर्वर पैकेट प्राप्त करता है, UDP हेडर से स्रोत IP पता और भेजने वाले का पोर्ट निकालता है, फिर बाइंडिंग रिस्पॉन्स बनाता है, इस पते को XOR-MAPPED-ADDRESS विशेषता में पैकेज करता है। प्रतिक्रिया अनुरोध के स्रोत पते पर वापस भेजी जाती है।

क्लाइंट प्रतिक्रिया प्राप्त करता है और XOR-MAPPED-ADDRESS निकालता है, जिसमें NAT डिवाइस द्वारा निर्दिष्ट बाहरी IP पता और पोर्ट होता है। फिर क्लाइंट इस पते की अपने स्थानीय (RFC 1919 — निजी) पते से तुलना करता है। यदि पते मेल खाते हैं — क्लाइंट NAT के पीछे नहीं है। यदि वे भिन्न हैं — क्लाइंट NAT के पीछे है, और बाहरी पते का उपयोग WebRTC में ICE (इंटरैक्टिव कनेक्टिविटी एस्टेब्लिशमेंट) के लिए उम्मीदवार के रूप में किया जाता है।

NAT डिस्कवरी प्रक्रिया

STUN सर्वर परीक्षण अनुरोधों के अनुक्रम के माध्यम से NAT प्रकार निर्धारित करने की अनुमति देता है। क्लाइंट विभिन्न फ़्लैग (CHANGE-REQUEST) के साथ अनुरोध भेजता है और प्रतिक्रियाओं का विश्लेषण करता है। पूर्ण डिस्कवरी चक्र में STUN सर्वर के विभिन्न IP पतों और पोर्टों पर अनुरोध भेजना शामिल है। यदि सर्वर बदले हुए पोर्ट के साथ अनुरोध का उत्तर देता है — NAT रेस्ट्रिक्टेड कोन प्रकार का है। यदि यह बदले हुए पोर्ट और IP वाले अनुरोध का उत्तर नहीं देता — NAT सिमेट्रिक प्रकार का है। यह जानकारी WebRTC में ICE रणनीति चुनने के लिए महत्वपूर्ण है।

STUN सर्वर और NAT प्रकार

STUN सर्वर चार मुख्य प्रकार के NAT का पता लगा सकता है, जिनमें से प्रत्येक P2P कनेक्शन स्थापित करने की क्षमता को अलग-अलग तरीके से प्रभावित करता है। NAT प्रकार यह निर्धारित करता है कि STUN दो क्लाइंट के बीच सीधा कनेक्शन सक्षम कर सकता है या नहीं। यह भी निर्धारित करता है कि कनेक्शन के लिए कौन सा ICE उम्मीदवार — host, server reflexive या relay — उपयोग किया जाएगा।

Symmetric NAT एकमात्र प्रकार है जिससे STUN निपट नहीं सकता। Symmetric NAT के साथ, एक नए गंतव्य होस्ट के लिए प्रत्येक नया अनुरोध एक अलग बाहरी पता (IP और/या पोर्ट) प्राप्त करता है। चूंकि STUN सर्वर स्वयं STUN सर्वर से कनेक्शन के लिए पते की रिपोर्ट करता है, यह पता किसी अन्य क्लाइंट से कनेक्ट करने के लिए अनुपयुक्त है। ऐसे मामलों में, WebRTC ट्रैफ़िक को रीले करने के लिए TURN सर्वर का उपयोग करता है। शोध के अनुसार (Ford et al., RFC 3489, 2003), इंटरनेट पर लगभग 8-10% NAT डिवाइस सममित हैं।

WebRTC में STUN सर्वर का उपयोग

STUN सर्वर RTCPeerConnection कॉन्फ़िगरेशन के माध्यम से WebRTC में एकीकृत होता है। ब्राउज़र या मूल एप्लिकेशन ICE उम्मीदवारों को एकत्र करने के लिए STUN का उपयोग करता है, जिन्हें बाद में सिग्नलिंग सर्वर के माध्यम से आदान-प्रदान किया जाता है। WebRTC कॉन्फ़िगरेशन में, STUN सर्वर को iceServers ऐरे में UDP के लिए stun: उपसर्ग या TLS कनेक्शन के लिए stuns: के साथ निर्दिष्ट किया जाता है।

आइए WebRTC एप्लिकेशन के लिए RTCPeerConnection बनाते समय JavaScript में STUN सर्वर सेटअप का एक उदाहरण देखें।

const config = {
    iceServers: [
        {
            urls: "stun:stun.l.google.com:19302"
        },
        {
            urls: "stun:stun1.l.google.com:19302"
        }
    ]
};

const pc = new RTCPeerConnection(config);

pc.onicecandidate = (event) => {
    if (event.candidate) {
        console.log("ICE उम्मीदवार:", event.candidate.candidate);
    }
};

const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

इस उदाहरण में Google के सार्वजनिक STUN सर्वर (stun.l.google.com:19302) का उपयोग किया गया है। offer या answer बनाते समय, ब्राउज़र स्वचालित रूप से निर्दिष्ट सर्वरों पर STUN बाइंडिंग रिक्वेस्ट भेजता है, बाहरी पता (server reflexive उम्मीदवार) प्राप्त करता है और इसे ICE उम्मीदवारों की सूची में जोड़ता है। सभी उम्मीदवारों के एकत्र होने के बाद, वे सीधा P2P कनेक्शन स्थापित करने के प्रयास के लिए सिग्नलिंग सर्वर के माध्यम से दूरस्थ पीयर को भेजे जाते हैं।

ICE उम्मीदवार प्रकार और STUN

ICE प्रक्रिया में तीन प्रकार के उम्मीदवार होते हैं: host (स्थानीय पता), srflx (server reflexive — STUN से प्राप्त) और relay (TURN के माध्यम से रीले किया गया)। STUN सर्वर srflx उम्मीदवारों के निर्माण को सक्षम बनाता है, जिनकी प्राथमिकता relay उम्मीदवारों से अधिक होती है क्योंकि STUN-आधारित कनेक्शन प्रत्यक्ष होता है और इसमें रीले की आवश्यकता नहीं होती। ICE प्रक्रिया दोनों पीयर के सभी उम्मीदवार संयोजनों (स्थानीय और STUN से प्राप्त) की जाँच करती है, उच्चतम प्राथमिकताओं से शुरू करते हुए।

STUN प्रोटोकॉल की सीमाएँ

STUN सर्वर में प्रोटोकॉल आर्किटेक्चर से संबंधित मूलभूत सीमाएँ हैं। मुख्य सीमा Symmetric NAT के साथ काम करने में असमर्थता है, जहाँ प्रत्येक बाहरी होस्ट को नया अनुरोध एक अद्वितीय बाहरी पोर्ट प्राप्त करता है। इस मामले में, STUN सर्वर से प्राप्त पते का उपयोग किसी अन्य पीयर से कनेक्ट करने के लिए नहीं किया जा सकता क्योंकि NAT ने केवल STUN सर्वर के साथ संचार के लिए बाइंडिंग बनाई है।

दूसरी सीमा यह है कि STUN डेटा रीले प्रदान नहीं करता। यदि सीधा P2P कनेक्शन असंभव है (दोनों पीयर Symmetric NAT के पीछे), तो STUN डेटा ट्रांसमिशन के लिए कोई वैकल्पिक पथ प्रदान नहीं करता। इस मामले में, TURN सर्वर की आवश्यकता होती है, जो पीयर के बीच मीडिया ट्रैफ़िक रीले के रूप में कार्य करता है, एक प्रतिभागी से डेटा प्राप्त करता है और इसे अपने सार्वजनिक IP पते के माध्यम से दूसरे को भेजता है।

• Symmetric NAT — STUN सममित NAT के साथ काम नहीं करता क्योंकि बाहरी पता प्रत्येक गंतव्य होस्ट के लिए अद्वितीय है और P2P के लिए पुन: उपयोग नहीं किया जा सकता।
• फायरवॉल डीप पैकेट इंस्पेक्शन — कुछ फायरवॉल पोर्ट 3478 पर UDP पैकेट में प्रोटोकॉल हस्ताक्षर का पता लगाकर STUN ट्रैफ़िक को ब्लॉक करते हैं।
• IPv6 — IPv6 नेटवर्क में, NAT का आमतौर पर उपयोग नहीं किया जाता, इसलिए STUN की आवश्यकता नहीं है, लेकिन IPv6 पर WebRTC STUN या TURN की आवश्यकता के बिना host उम्मीदवारों का उपयोग कर सकता है।
• उपलब्धता पर निर्भरता — STUN सर्वर कनेक्शन स्थापना चरण के दौरान क्लाइंट के लिए सुलभ होना चाहिए, अन्यथा srflx उम्मीदवार एकत्र नहीं होंगे।
• सुरक्षा — STUN प्रोटोकॉल एम्प्लीफिकेशन हमलों के प्रति संवेदनशील है यदि सर्वर गलत तरीके से कॉन्फ़िगर किया गया है और नकली स्रोत पते वाले अनुरोधों का उत्तर देता है।

सीमाओं के बावजूद, STUN सर्वर WebRTC बुनियादी ढांचे का एक महत्वपूर्ण घटक बना हुआ है। अधिकांश मामलों (80-90%) में, STUN का उपयोग करके सीधा P2P कनेक्शन स्थापित किया जा सकता है, जो TURN रीले की लागत से बचाता है और मीडिया डेटा ट्रांसमिशन विलंबता को कम करता है। सार्वजनिक WebRTC एप्लिकेशन के लिए, किसी भी नेटवर्क स्थितियों में कनेक्शन की गारंटी के लिए स्वचालित फ़ॉलबैक के साथ STUN और TURN सर्वर के संयोजन का उपयोग करने की अनुशंसा की जाती है।