VPN प्रवाह में क्लाइंट का स्रोत पोर्ट बनाम सर्वर का लिसनर
एक ही सुरंग में दो पोर्ट संख्याओं की तुलना करें: सर्वर का स्थिर लिसनर और क्लाइंट का अल्पकालिक स्रोत, और बीच में राउटर का अनुवाद कैसे बैठता है।
एक ही बातचीत में दो संख्याएँ दिखती हैं, और उनमें से कोई गलत नहीं है। सर्वर का लॉग सेवा देने वाला लिसनर दिखाता है, लैपटॉप वह सॉकेट दिखाता है जिसने डेटाग्राम भेजा, और बीच का राउटर बाहर जाते समय दूसरे को फिर से लिख सकता है। अंकों की तुलना करने से ज़्यादा उपयोगी यह है कि बातचीत के दोनों सिरों की तुलना की जाए। नीचे की तुलना लिसनर, क्लाइंट सॉकेट और अनूदित स्रोत को अलग रखती है, क्योंकि वे अलग-अलग सवालों के जवाब देते हैं।
विपरीत सिरों को बताती दो संख्याएँ
सर्वर का कॉन्फ़िगर किया गया पोर्ट वह गंतव्य है जिस पर क्लाइंट डायल करता है। इसे नीति तय करती है, यह प्रोफ़ाइल में दिखता है और सर्वर की ओर खुला होना चाहिए। क्लाइंट का स्रोत पोर्ट स्थानीय रूप से चुना जाता है, आमतौर पर अल्पकालिक श्रेणी से, और इसलिए मौजूद है कि जवाब को उतरने की जगह मिले। यह हर पुनःकनेक्शन पर बदल सकता है, और डिज़ाइन में कुछ भी इसके स्थिर रहने पर निर्भर नहीं है।
बीच का राउटर उस स्रोत को अपने 'NAT' मैपिंग में फिर से लिख सकता है। इसीलिए सर्वर पर दिखने वाली संख्या का लैपटॉप द्वारा चुनी गई संख्या से अक्सर कोई संबंध नहीं होता।
बाहर जाते समय स्रोत संख्या कहाँ बदलती है
IPv4 का एक काल्पनिक उदाहरण लें: अनुवाद करने वाले राउटर के पीछे एक क्लाइंट, एक 'UDP' लिसनर वाला सर्वर, और दोनों को पार करता एक डेटाग्राम। तालिका तीन अवलोकन बिंदुओं पर पैकेट दोहराने के बजाय हर सिरे का नाम और उसके साथ क्या होता है बताती है।
| Endpoint | What stays fixed | What changes on reconnect | Who owns it |
|---|---|---|---|
| Server listener | The service port and the address the profile names | Nothing; the listener does not follow the client | The server operator |
| Client socket | The destination it dials | The local source port, chosen per socket | The client, or its operating system |
| Translated source | Usually the public address of the router | The port, and sometimes the address after a network switch | The NAT device or the upstream carrier |
गंतव्य हर पंक्ति में स्थिर है, और केवल स्रोत की पहचान बदलती है। UDP NAT की आवश्यकताएँ आंतरिक पता और पोर्ट को बाहरी मैपिंग से अलग करती हैं, और यही दूसरी और तीसरी पंक्ति के बीच का अंतर है। राउटर क्लाइंट का स्रोत पोर्ट बनाए रख सकता है या दूसरा चुन सकता है; बनाए रखना ऐसी बात नहीं जिसे कोई एप्लिकेशन मान ले।
तीनों सिरों को स्वयं होस्ट से पढ़ें
नीचे की सूचियाँ तीन अलग मशीनों से आती हैं और मिलकर पूरी बातचीत दिखाती हैं। पहली सर्वर पर, दूसरी क्लाइंट पर और तीसरी वहाँ चलाएँ जहाँ मैपिंग मौजूद है। एक लॉग पंक्ति कभी तीनों नहीं दिखाती।
ss -lunp 'sport = :1194'
ss -unp | grep 1194
conntrack -L -p udp | grep 1194पहली सूची साबित करती है कि सर्वर सेवा पोर्ट से बंधा है और दिखाती है कि कौन-सी प्रक्रिया उसका मालिक है। दूसरी क्लाइंट का स्थानीय सॉकेट और वह गंतव्य दिखाती है जिस पर उसने डायल किया। तीसरी राउटर द्वारा बनाई गई मैपिंग दिखाती है, और अनूदित स्रोत केवल वहीं दिखता है। इन्हें इसी क्रम में पढ़ें और दोनों संख्याएँ विरोधाभासी लगना बंद कर देती हैं।
पुनःकनेक्शन क्या बदलता है और क्या नहीं
कुछ राउटर क्लाइंट का स्रोत पोर्ट खाली होने पर बनाए रखते हैं, और कुछ हर बार अलग आवंटित करते हैं। दोनों व्यवहार सामान्य हैं, और पहला माँगने वाला एप्लिकेशन दूसरे पर टूट जाएगा। पुनःकनेक्शन या नेटवर्क बदलने के बाद मैपिंग का बदलना सर्वर की खराबी नहीं है: क्लाइंट नया सॉकेट खोलता है, राउटर जो उसके पास है आवंटित करता है, और सर्वर उसी लिसनर पर नया स्रोत देखता है। खराबी यह होगी कि सर्वर से किसी मनमाने क्लाइंट पोर्ट को संबोधित ट्रैफ़िक स्वीकार करने की अपेक्षा की जाए।
समुदाय के OpenVPN क्लाइंट यह व्यवहार nobind के ज़रिए पाते हैं, जो ऑपरेटिंग सिस्टम को स्थानीय पोर्ट चुनने देता है; दूरस्थ पोर्ट अब भी प्रोफ़ाइल से आता है। स्पष्ट रूप से बाइंड करना सोचा-समझा निर्णय है, प्रोटोकॉल की माँग नहीं। सर्वर एक सिरा देता रहता है जबकि क्लाइंट अपनी स्थानीय पहचान चुनते हैं।
रिकॉर्ड में परतों को अलग-अलग नाम दें
सुरंग के भीतर अपने पोर्ट वाली दूसरी बातचीत होती है। सुरंग द्वारा ले जाई गई HTTPS अनुरोध का गंतव्य TCP 443 है, जबकि बाहरी एन्क्रिप्टेड कनेक्शन UDP 1194 इस्तेमाल करता है, इसलिए बाहरी स्रोत पोर्ट बदलने से भीतरी सेवा में कुछ नहीं बदलता।
बाहरी परत पर भी प्रोटोकॉल मायने रखता है। UDP 1194 और TCP 1194 अलग सिरे हैं, और 'TCP' लिसनर कभी UDP डेटाग्राम नहीं पाएगा क्योंकि संख्या मेल खाती है। तैनाती का दस्तावेज़ बनाते समय सर्वर लिसनर, क्लाइंट सॉकेट और अनूदित स्रोत को तीन अलग चीज़ों के रूप में नाम दें, और हर एक में ट्रांसपोर्ट जोड़ें।
फिर नीति को भूमिकाओं का पालन करने दें। सर्वर अपने लिसनर पर इच्छित ट्रांसपोर्ट खोलता है और फिर भी साथी को प्रमाणित करता है; क्लाइंट का फ़ायरवॉल बिना कोई इनबाउंड सेवा प्रकाशित किए अपने आउटबाउंड आदान-प्रदान के जवाब स्वीकार करता है। स्टेटलेस फ़िल्टर को वापसी दिशा स्पष्ट रूप से लिखनी पड़ती है, और साफ़-सुथरे आरेखों से आगे यह अंतर मायने रखने की व्यावहारिक वजह यही है।