पोर्ट फ़ॉरवर्डिंग के बिना NAT के पीछे वर्कस्टेशन तक पहुँचें
इनबाउंड पोर्ट न होने पर भी वर्कस्टेशन तक हब, रिले या ऐप ब्रोकर के ज़रिए पहुँचा जा सकता है। एक चुनने से पहले तुलना करें कि हर डिज़ाइन क्या गारंटी देता है।
कैरियर NAT और बंद कार्यालय राउटर के पीछे दो एंडपॉइंट फ़ॉरवर्ड करने के लिए कोई इनबाउंड पोर्ट नहीं छोड़ते, और प्रतिक्रिया यही होती है कि फिर भी एक माँगा जाए। बेहतर सवाल यह है कि कौन-सा पक्ष बाहर डायल कर सकता है और किस पहुँच-योग्य सेवा को ट्रैफ़िक ढोने की अनुमति है। चार डिज़ाइन इस सवाल का अलग-अलग जवाब देते हैं, और मार्ग अवरुद्ध होने पर वे अलग-अलग तरह से विफल होते हैं। इनके बीच चुनाव प्रोटोकॉल नामों की नहीं, गारंटियों की तुलना है।
चार डिज़ाइन, चार अलग वादे
नीचे दी गई तालिका संक्षिप्त संस्करण है। बीच के कॉलम को उस वादे की तरह पढ़ें जिसे आप जाँच सकते हैं, और दाएँ कॉलम को उस वादे की तरह जो किसी ने नहीं दिया।
| Design | Who initiates | Promise you get | Promise you do not get |
|---|---|---|---|
| Routed VPN hub | Both ends, outbound to the hub | A routed path to permitted prefixes | Access to services no policy allows |
| Peer traversal with ICE | Both peers to a rendezvous service | A path tested between the two peers | A direct path through every NAT |
| TURN relay | Client outbound to a relay | Transport that survives symmetric NAT | Peer discovery or a usable directory |
| Application broker | Workstation outbound to a broker | One audited application session | Subnet-wide reachability |
कौन-सी पंक्ति लागू होती है, यह पसंद पर नहीं बल्कि कार्य पर निर्भर करता है। एक रिमोट डेस्कटॉप सत्र, एक प्रशासनिक शेल और पूरे निजी सबनेट तक पहुँच — ये तीन आवश्यकताएँ हैं जिन्हें एक ही प्रवेश-बिंदु की ज़रूरत नहीं होती, भले ही वे संयोग से एक ही मशीन से जुड़ी हों।
हब बदलता है कि कौन बाहर डायल करता है, यह नहीं कि क्या अनुमत है
राउटेड हब डिज़ाइन में दूर का लैपटॉप और वर्कस्टेशन, या उसके सामने का साइट गेटवे, दोनों में से प्रत्येक ऐसी सेवा तक बाहर जाने वाली सुरंग खोलता है जहाँ दोनों पहुँच सकते हैं। वर्कस्टेशन के राउटर पर कोई भी बिन-माँगे कनेक्शन स्वीकार नहीं करता, और ठीक इसी कारण यह डिज़ाइन NAT में टिकता है और तब भी काम करता है जब साइट के पास स्थिर पता न हो। फिर हब अपनी नीति के अनुसार दो आंतरिक पतों के बीच ट्रैफ़िक राउट करता है।
कीमत यह है कि हब को होना चाहिए, दोनों ओर से पहुँच-योग्य होना चाहिए और किसी को उसे चलाना चाहिए। आउटबाउंड फ़िल्टरिंग को ट्रांसपोर्ट की अनुमति देनी होगी, और जो नेटवर्क उसे ब्लॉक करता है वह पोर्ट फ़ॉरवर्डिंग की ज़रूरत न होने पर भी डिज़ाइन को विफल कर देगा।
सूक्ष्म बात यह है कि पहुँच और प्राधिकरण अलग-अलग जगहों पर लिए गए अलग निर्णय हैं। किसी प्रीफ़िक्स तक का मार्ग यह नहीं बताता कि वर्कस्टेशन पर कौन-सी सेवा पहचान इस्तेमाल कर सकती है, और सुरंग की अनुमति देने वाला फ़ायरवॉल नियम यह नहीं बताता कि खाता लॉग इन कर सकता है या नहीं। दोनों को कॉन्फ़िगर करें, दोनों को जाँचें, और प्राधिकरण का निर्णय राउटिंग तालिका के बजाय उस सिस्टम के पास रखें जो संसाधन का मालिक है।
ट्रैवर्सल तभी काम करता है जब दोनों स्टैक इसे लागू करें
पीयर ट्रैवर्सल किसी विशिष्ट सिस्टम की क्षमता है, VPN सुधारने वाली कोई सेटिंग नहीं। Interactive Connectivity Establishment कई उम्मीदवार पते इकट्ठा करता है और जोड़ियाँ तब तक जाँचता है जब तक एक काम न करे: स्थानीय इंटरफ़ेस पर होस्ट उम्मीदवार, NAT जो प्रकट करता है उससे बने सर्वर-रिफ़्लेक्सिव उम्मीदवार, और रिले पर आवंटित रिले उम्मीदवार। अकेला निजी पता मार्ग नहीं है, क्योंकि दूसरा पक्ष वहाँ राउट नहीं कर सकता।
रिले वाले मामले को ख़ारिज करने से पहले समझना उचित है। RFC 8656 TURN को ऐसे प्रोटोकॉल के रूप में बताता है जिसमें क्लाइंट सर्वर से रिले किया गया ट्रांसपोर्ट पता माँगता है और सर्वर उस क्लाइंट और उसके पीयर के बीच ट्रैफ़िक अग्रेषित करता है। इसलिए रिले डेटा ढोता है, जो केवल एंडपॉइंट को मिलने में मदद करने वाली निर्देशिका से मूल रूप से अलग है। पीयर के साथ रिले पता बदलना एक समन्वय कदम है जो एप्लिकेशन को करना होता है।
जिसका वादा आप नहीं कर सकते वह सीधा मार्ग है। सममित NAT और कुछ एंटरप्राइज़ फ़ायरवॉल होल-पंचिंग को विफल करते हैं, और जब ऐसा होता है तो सिस्टम या तो रिले पर लौट जाता है या विफल हो जाता है। आप यह भी नहीं निष्कर्ष निकाल सकते कि दो अनूदित एंडपॉइंट कभी बात नहीं कर सकते; रिले फ़ॉलबैक वाला समर्थित स्टैक ठीक इसलिए मौजूद है क्योंकि वे अक्सर कर सकते हैं। तय करें कि उपलब्धता ज़्यादा मायने रखती है या सीधापन, फिर सुखद स्थिति मान लेने के बजाय जाँचें कि परिनियोजन ने वास्तव में कौन-सा मार्ग चुना।
ब्रोकर नेटवर्क से संकरा है
जब आवश्यकता एक एप्लिकेशन की हो, तो ऐप ब्रोकर या वर्कस्टेशन द्वारा शुरू किया गया रिवर्स कनेक्शन सबसे छोटा उत्तर हो सकता है। वर्कस्टेशन बाहर ब्रोकर तक डायल करता है, ब्रोकर दूर के उपयोगकर्ता को प्रमाणित करता है, और केवल वही एप्लिकेशन सत्र ढोया जाता है। वर्कस्टेशन के सबनेट तक कोई मार्ग नहीं बनता, इसलिए दूर के सत्र के समझौते को बगल के हर उपकरण तक मार्ग विरासत में नहीं मिलता।
इस संकीर्णता की कीमत है: हर अतिरिक्त एप्लिकेशन को अपना एकीकरण चाहिए, और एप्लिकेशन स्थानीय नेटवर्क के बारे में जो मानता है, जैसे किसी पास के सर्वर पर खोला जाने वाला फ़ाइल शेयर, वह पहुँच-योग्य न भी हो। ब्रोकर नीति और लॉगिंग को एक जगह केंद्रित करते हैं, जो तब तक उपयोगी है जब तक वही जगह व्यवधान न बन जाए।
विश्वास की सीमाओं की तुलना करें, फिर मार्ग जाँचें
सुरंगें समाप्त करने वाला हब जिस ट्रैफ़िक को राउट करता है उसे पढ़ सकता है। जब एप्लिकेशन एंड-टू-एंड एन्क्रिप्ट करता है तो रिले स्वतंत्र रूप से सुरक्षित आदान-प्रदान ढो सकता है, और ब्रोकर आमतौर पर वही सत्र समाप्त करता है जो वह प्रस्तुत करता है। यह तय करने से पहले कि दो डिज़ाइन समतुल्य हैं क्योंकि दोनों एन्क्रिप्टेड हैं, यह स्थापित करें कि सुरक्षा वास्तव में कहाँ समाप्त होती है।
फिर जाँचें कि वर्कस्टेशन बाहर की ओर वास्तव में कहाँ पहुँचता है, क्योंकि ऊपर का हर डिज़ाइन इसी पर निर्भर है। इसे वर्कस्टेशन पर चलाएँ, और उस होस्टनाम को बदलें जिसे आप इस्तेमाल करने की सोच रहे हैं।
ss -lntup
nc -vz hub.example.com 443
curl -sS -o /dev/null -w "%{http_code}\n" https://hub.example.comडिज़ाइन को तभी स्वीकार करें जब अनुमत पहचान के अंतर्गत इच्छित दूर की कार्रवाई सफल हो, अनुमति-रहित पहचान अस्वीकार हो, और सीधा या रिले मार्ग उपलब्ध न होने पर व्यवहार ज्ञात और प्रलेखित हो। पुनः कनेक्ट और वर्कस्टेशन के सामान्य स्टार्टअप संदर्भ को शामिल करें, क्योंकि कार्यालय में LAN से शुरू हुआ सत्र उनमें से कुछ भी नहीं जाँचता जिन पर दूर की पहुँच निर्भर है।