दोनों सिरों पर एक ही सबनेट: दूरस्थ LAN को मुक्त रेंज में मैप करें

घर और दफ़्तर दोनों 192.168.1.0/24 चलाते हैं, इसलिए 192.168.1.1 पर एक अनुरोध के दो संभावित जवाब हैं और क्लाइंट बिना पूछे एक चुन लेता है। चालू दफ़्तर नेटवर्क को फिर से क्रमांकित करना शायद ही कभी लोकप्रिय होता है, और राउटर के पते अक्सर प्रिंटर, कैमरों और दस्तावेज़ों में जड़ जाते हैं। क्लाइंट-साइड पता मैपिंग इसके बजाय दूरस्थ नेटवर्क को मुक्त रेंज के अंतर्गत प्रस्तुत कर सकती है, और होस्ट भाग वही रह सकता है ताकि 192.168.1.20 को 10.203.41.20 के रूप में देखा जाए। पेच यह है कि केवल कुछ क्लाइंट इसे लागू करते हैं, और यह वापसी मार्ग के लिए कुछ नहीं करता।

एक ही होस्ट के दो दृश्य

मैपिंग होस्ट भाग रखती है और केवल नेटवर्क भाग बदलती है। फिर वही मशीन आपके खड़े होने की जगह के अनुसार दो पतों पर जवाब देती है। कुछ भी कॉन्फ़िगर करने से पहले दोनों कॉलम लिख लेना बाद में लॉग और फ़ायरवॉल नियमों की गलत व्याख्या रोकता है।

घर के स्थानीय उपकरण अपने 192.168.1.x पते रखते हैं, और यही इस अभ्यास का उद्देश्य है। बगल के कमरे का प्रिंटर पहुँच में बना रहता है जबकि दफ़्तर ऐसी रेंज के अंतर्गत दिखता है जो टकराती नहीं।

आर्ग्युमेंट का क्रम ही पूरी चाल है

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

push "route 10.203.41.0 255.255.255.0"
push "client-nat dnat 10.203.41.0 255.255.255.0 192.168.1.0"

रूट वह है जो क्लाइंट के पैकेट नई रेंज के लिए टनल में भेजता है; अनुवाद रास्ते में गंतव्य फिर से लिखता है। 192.168.1.20 से जवाब 10.203.41.20 पर वापस लिखा जाता है ताकि क्लाइंट पर सॉकेट सुसंगत रहे। एक अकेला होस्ट पूरी लंबाई के मास्क के साथ उसी तरह काम करता है, जब तक रूट और मैपिंग एक ही पता बताते हैं।

यह पता मैपिंग है, पोर्ट मैपिंग नहीं। एक होस्ट पर दो सेवाएँ इससे अलग नहीं की जा सकतीं, और जो प्रोटोकॉल अपने पेलोड में IP पते जड़ता है वह अब भी असली पते ही देखेगा।

मैपिंग वापसी मार्ग नहीं बनाती

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

सर्वर-साइड नियमों को अनुवाद के बाद सर्वर पर मौजूद पतों का वर्णन करना चाहिए, क्लाइंट को दिखने वाली रेंज का नहीं। उपनाम को अनुमति नियम में कॉपी करना एक दोपहर बर्बाद करता है, क्योंकि उस तरफ़ का कोई पैकेट इसे नहीं ढोता।

ऐसी उपनाम रेंज चुनें जो क्लाइंट द्वारा रूट की जाने वाली किसी और चीज़ से न टकराए: दूसरा VPN, कंटेनर नेटवर्क, दूसरा दफ़्तर। यहाँ टकराव मूल अस्पष्टता को अलग संख्या के अंतर्गत वापस लाता है और देखना कठिन होता है क्योंकि पते अपरिचित लगते हैं।

नाम और पेलोड अनुवाद से बच निकलते हैं

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

रीडायरेक्ट, एम्बेडेड URL और ऐसी ऐप्लिकेशन जो अपना पता पेलोड में देती हैं, ऐसे तरीक़ों से टूट सकती हैं जिन्हें कोई पैकेट मैपिंग ठीक नहीं कर सकती। इन्हें ऐप्लिकेशन की समस्या मानें और फिर से क्रमांकन अनावश्यक होने का वादा करने से पहले प्रयास उसी हिसाब से आँकें।

प्रतिबद्ध होने से पहले तीन जाँचें

पहला, क्लाइंट कार्यान्वयन की पुष्टि करें। Community OpenVPN इस विकल्प का समर्थन करता है; OpenVPN 3 कोडबेस इसे असमर्थित सुविधाओं में सूचीबद्ध करता है, इसलिए Connect-शैली के क्लाइंट पर भेजी गई प्रोफ़ाइल इसे बस अनदेखा कर सकती है। जो निर्देश स्वीकार किया जाए और कभी लागू न हो वह त्रुटि से बुरा है, क्योंकि टनल स्वस्थ दिखता है।

दूसरा, ऊँची वर्बोसिटी पर छोटी डायग्नोस्टिक विंडो के साथ रूट और अनुवाद अलग-अलग जाँचें, फिर ping के बजाय वास्तविक सेवा का परीक्षण करें। तीसरा, पुष्टि करें कि स्थानीय राउटर और दूरस्थ संसाधन क्लाइंट से अलग पहचाने जा सकते रहें, क्योंकि यही मूल लक्ष्य था।

अगर क्लाइंट अनुवाद नहीं कर सकता, तो गेटवे पक्ष से मदद माँगें या फिर से क्रमांकन स्वीकार करें। एक ही पते के लिए और रूट जोड़ना कोई डिज़ाइन नहीं है।