उस NAT के पीछे VPN जिसे आप कॉन्फ़िगर नहीं कर सकते: क्या अब भी काम करता है

हर टनल एंडपॉइंट को ऐसा पता और पोर्ट चाहिए जहाँ दूसरा पक्ष पहुँच सके, और जिस राउटर को आप प्रशासित नहीं करते वही इस आवश्यकता के विफल होने का सामान्य कारण है। दिलचस्प बात यह नहीं है कि तरकीबें मौजूद हैं, बल्कि यह है कि हर तरकीब मैपिंग तालिका की ऐसी विशेषता पर निर्भर करती है जिसे आप क्लाइंट से नहीं देख सकते। उनमें से दो विशेषताएँ लगभग सब कुछ तय करती हैं: मैपिंग कैसे बनती है, और क्या वह ऐसे पते से पैकेट स्वीकार करती है जिससे अंदर कभी संपर्क नहीं हुआ। वातावरण को उन विशेषताओं के अनुसार छाँटिए और उपाय लोककथा रहना बंद कर देते हैं।

मैपिंग तालिका ही सब कुछ तय करती है

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

राउटर की ओर से तालिका देखिए और उपाय स्पष्ट हो जाते हैं: या तो कुछ स्थायी प्रविष्टि बनाता है, या कुछ अस्थायी प्रविष्टि बनाकर उसे ताज़ा रखता है, या ट्रैफ़िक उस रास्ते पर कभी जाता ही नहीं। इस लेख का शेष भाग वही तीन स्थितियाँ क्रम में हैं। यहाँ कुछ भी तालिका जो दर्ज करती है उससे आगे किसी विक्रेता सुविधा पर निर्भर नहीं है।

रेनडेवू सेवा क्या कर सकती है और क्या नहीं

UDP होल पंचिंग फ़िल्टर को हराने के बजाय बहिर्गामी रिकॉर्ड को अस्थायी खोल के रूप में उपयोग करती है। दोनों साथी एक रेनडेवू सेवा से संपर्क करते हैं, जो हर सार्वजनिक एंडपॉइंट जान लेती है और दूसरे पक्ष को उसका एंडपॉइंट बता देती है। फिर दोनों एक-दूसरे की ओर भेजते हैं, और हर बहिर्गामी पैकेट वह रिकॉर्ड बनाता या ताज़ा करता है जो उत्तर को अंदर आने देता है। क्रम ही इसे काम कराता है, और क्रम ही इसे नाज़ुक बनाता है: जो साथी दूसरे पक्ष के रिकॉर्ड बनने से पहले भेजता है वह बस छोड़ दिया जाता है, जबकि एक पल बाद का पुनः प्रयास सफल होता है। सेवा स्वयं कोई VPN ट्रैफ़िक नहीं ले जाती, इसलिए उसका एकमात्र लाभ वह समय-संयोजन है जो वह करती है।

मैपिंग व्यवहार बाकी सब तय करता है, और RFC 4787 तीन आकार बताता है: एंडपॉइंट-स्वतंत्र, पता-निर्भर, और पता तथा पोर्ट-निर्भर। अंतिम में, जिस पोर्ट को साथी को लक्ष्य बनाना है वह हर गंतव्य के साथ बदलता है, इसलिए अनुमान विश्वसनीय नहीं रहता। वहीं यह तकनीक अपनी गतिरोध में पहुँचती है, क्योंकि कैरियर-ग्रेड NAT और कठोर कॉर्पोरेट फ़ायरवॉल दोनों उस पूर्वानुमान को हटा देते हैं जिसकी योजना को ज़रूरत है, और कितने भी पुनः प्रयास उसे वापस नहीं लाते।

कीपअलाइव, रीबूट और खिसकता एंडपॉइंट

छेद किया गया मार्ग श्रोता नहीं बल्कि प्रवाह है, इसलिए उसके ऊपर चलने वाली हर चीज़ को बदलाव झेलना होगा। उसे आवधिक ट्रैफ़िक से मैपिंग जीवित रखनी होगी, सार्वजनिक एंडपॉइंट कब खिसकता है यह नोटिस करना होगा, और राउटर रीबूट होने या पता फिर से सौंपे जाने के बाद फिर से स्थापित होना होगा। मेश VPN उत्पाद वह तर्क अपने नियंत्रण तल में रखते हैं, जबकि सादा सर्वर उसे आप पर छोड़ देता है। कीपअलाइव केवल तब तक मदद करते हैं जब तक वही मैपिंग बची रहती है, और मोबाइल क्लाइंट पर वे बैटरी खाते हैं, इसलिए आक्रामक अंतराल मुफ़्त नहीं है।

एक घंटा सोया लैपटॉप आमतौर पर किसी दूसरे सार्वजनिक एंडपॉइंट पर लौटता है। जो मार्ग को फिर से स्थापित करता है उसे फिर अंदर से चलना होगा, जो वही शर्त क्लाइंट पर वापस लाता है।

गायब फ़ॉरवर्ड के चारों ओर तीन रास्ते

पहला रास्ता राउटर से कहता है कि वह स्वयं प्रविष्टि बनाए, UPnP IGD, NAT-PMP या PCP के ज़रिए, जब सुविधा मौजूद हो और चालू हो। दूसरा ट्रैफ़िक को सार्वजनिक पते वाले रिले को सौंपता है, जो हमेशा काम करता है और हमेशा बैंडविड्थ के साथ एक अलग विश्वास-सीमा का खर्च लेता है। तीसरा दिशा उलट देता है: आंतरिक होस्ट सार्वजनिक सर्वर की ओर बहिर्गामी टनल खोलता है और बाकी सब उसके अंदर सवारी करता है।

[Peer]
PublicKey = 6yGj3kQ2wVb8sTn1pLx4dRc7hZa9mKf2uYe5oNq0iXw=
Endpoint = relay.corp.internal:51820
PersistentKeepalive = 25
AllowedIPs = 10.44.0.0/24

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

उपाय को राउटर के स्वामी के अनुसार मिलाइए

अगर आप राउटर प्रशासित करते हैं, तो स्थिर UDP फ़ॉरवर्ड किसी भी पंचिंग योजना से ज़्यादा आसानी से जाँचा जा सकता है और ऐसे तरीक़ों से विफल होता है जो आप देख सकते हैं। अगर नहीं, तो पता लगाइए कि विक्रेता रिले या होस्टेड नियंत्रण तल देता है या नहीं, और नीति उसके उपयोग की अनुमति देगी या नहीं। अगर इनमें से कोई नहीं है, तो बचे हुए विकल्प उलटी टनल या यह स्वीकार करना हैं कि एंडपॉइंट बाहर से पहुँच के बाहर है। आपने कौन सा इस्तेमाल किया यह दर्ज करना जितना सुनाई देता है उससे ज़्यादा मायने रखता है, क्योंकि विकल्प इस बात में भिन्न हैं कि कौन ट्रैफ़िक देख सकता है और जब कोई तीसरा पक्ष कुछ बदलता है तब क्या होता है।

ध्यान दीजिए कि जिस मार्ग पर आप पहुँचे वह सीधा था या रिले से, क्योंकि यही एक तथ्य विलंब और विफलता व्यवहार दोनों का अनुमान देता है। RFC 4787 इन सबके नीचे के मैपिंग व्यवहार का संदर्भ बना रहता है, और उसका मैपिंग खंड पढ़ना तीन उपायों को क्रम से जाँचने से तेज़ है। तालिका को इससे मतलब नहीं कि आपने कौन सा विकल्प चुना; वह केवल दर्ज करती है कि अगला पैकेट क्या कर सकता है।