पूर्ण-टनल VPN आपके राउटेड स्थानीय VLAN क्यों छिपाता है

VPN क्लाइंट में “allow local network” स्विच ऐसा लगता है जैसे वह इमारत की हर चीज़ को कवर करता हो। व्यवहार में यह आमतौर पर टनल के डिफ़ॉल्ट रूट में निजी पतों के कुछ अपवाद जोड़ता है और वहीं रुक जाता है। आपका स्टोरेज VLAN तभी पहुँच में रहता है जब उस विशिष्ट प्रीफ़िक्स के लिए रूट टनल के आने तक टिका रहे, और कई क्लाइंट में ऐसा नहीं होता।

यह VPN सेटिंग नहीं बल्कि रूटिंग का सवाल है, जो अच्छी ख़बर है: इसका एक ठोस जवाब है।

allow-local-network वास्तव में क्या कवर करता है

क्लाइंट इस विकल्प को अलग-अलग तरह से लागू करते हैं। कुछ उस सबनेट के लिए रूट जोड़ते हैं जिससे मशीन जुड़ी है, कुछ RFC 1918 रेंज जोड़ते हैं, और कुछ ही केवल डिफ़ॉल्ट गेटवे को बाहर रखते हैं। इनमें से कोई नहीं जानता कि आपका ऑफ़िस राउटर स्टोरेज VLAN, लैब सेगमेंट या प्रिंटर सबनेट भी परोसता है, क्योंकि वे प्रीफ़िक्स उस तार पर नहीं हैं जो क्लाइंट देख सकता है। लेबल को अपनी टोपोलॉजी का वर्णन मान लेने के बजाय सटीक व्यवहार के लिए क्लाइंट के अपने दस्तावेज़ पढ़ें।

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

कनेक्टेड रूट पहले राउटर पर रुक जाते हैं

192.168.10.20/24 पर स्थित वर्कस्टेशन, जिसका गेटवे 192.168.10.1 है, को 192.168.10.0/24 के लिए स्वतः कनेक्टेड रूट मिल जाता है। 192.168.20.0/24 पर स्टोरेज VLAN एक अलग प्रीफ़िक्स है, केवल उसी गेटवे से पहुँचा जा सकता है, और वर्कस्टेशन के पास डिफ़ॉल्ट के अलावा उसके लिए कोई रूट नहीं है। टनल उठने से पहले साधारण डिफ़ॉल्ट संयोगवश स्टोरेज ट्रैफ़िक 192.168.10.1 पर भेज देता है और सब कुछ काम करता है।

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

ललच यह है कि /1 रूट की जोड़ी या दूसरा डिफ़ॉल्ट जैसा चौड़ा अपवाद पकड़ लिया जाए। इसका विरोध करें। अपवाद जितना सँकरा होगा, नेटवर्क बदलने पर उसे समझाना, जाँचना और हटाना उतना ही आसान होगा।

अपवाद को उसी टेबल में रखें जो जीतती है

एक ही रूटिंग टेबल के भीतर /24 सबसे लंबे प्रीफ़िक्स मिलान से /0 या /1 को हरा देता है, इसलिए स्थानीय गेटवे से स्टोरेज VLAN तक एक विशिष्ट रूट पर्याप्त है, बशर्ते टेबल को देखा ही जाए। Linux में सामान्य रूप छोटा है:

ip route add 192.168.20.0/24 via 192.168.10.1 dev eth0

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

फिर प्रविष्टि को क्लाइंट के समर्थित तंत्र या इंटरफ़ेस का मालिक नेटवर्क मैनेजर के ज़रिए स्थायी बनाएँ। प्रॉम्प्ट पर टाइप किया गया रूट अगले पुनःकनेक्शन पर गायब हो जाता है, और एक Wi-Fi गेटवे से बँधा रूट लैपटॉप के अगले नेटवर्क तक नहीं ले जाया जा सकता।

नाम और नीति रूट का अनुसरण नहीं करते

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

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

एक अनुबंध जो आप सौंप सकते हैं

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

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

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