जो VPN पूल आपके LAN से ओवरलैप होता है, उसे कोई रूट ठीक नहीं करता

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

एक अतिरिक्त रूट एक प्रीफ़िक्स को क्यों नहीं बाँट सकता

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

ip route get 192.168.1.50
route -n get 192.168.1.50
Find-NetRoute -RemoteIPAddress 192.168.1.50

सिस्टम से एक पते के बारे में पूछें और देखें कि वह कौन-सा इंटरफ़ेस बताता है। Linux, macOS और Windows हर एक केवल-पढ़ने वाली खोज से जवाब देते हैं, जो कुछ भी भेजे बिना चुना गया इंटरफ़ेस और अगला हॉप बताती है। जब टनल चालू होने पर जवाब भौतिक एडाप्टर की ओर इशारा करे, तो कर्नेल पते को लिंक पर मौजूद मानता है, न कि ऐसी चीज़ जिसे टनल ले जा सके।

प्रदाता ने जो प्रीफ़िक्स दिया है उसे घर के राउटर द्वारा दिए जाने वाले प्रीफ़िक्स के पास रखें और दोनों की स्ट्रिंग के रूप में तुलना करें। पूरा मेल स्पष्ट मामला है, और घर के सबनेट को समेटने वाला बड़ा प्रदाता पूल भी उसी तरह विफल होता है, बस उसे चूकना ज़्यादा आसान है। सिर्फ़ एक जैसे दिखने वाले दो प्रीफ़िक्स टकराव नहीं हैं, इसलिए कुछ भी बदलने से पहले दोनों लिख लें।

क्लाइंट को असल में जो पूल मिला, उसे पढ़ें

पढ़ें कि क्लाइंट को क्या मिला, प्रदाता का मार्केटिंग पेज नहीं। OpenVPN क्लाइंट के लॉग का विस्तार बढ़ाएँ तो सर्वर द्वारा भेजे गए रूट उसमें दिखेंगे, जो टनल प्रीफ़िक्स खोलते हैं; अन्य जगह पूल कनेक्शन विवरण में या खुद एडाप्टर पर दिखता है। प्रदाता से उसके इस्तेमाल किए गए सभी निजी रेंज की पूरी सूची माँगें, क्योंकि आज का एक /24 कल दो हो सकता है। आम RFC 1918 ब्लॉक से बचना उस आवंटन से बचने जैसा नहीं है जो असल में आपको दिया गया है।

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

फिर से नंबर देना ही वह सुधार है जो आप कर सकते हैं

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

1. पहले सूची बनाएँ: राउटर का अपना पता, DHCP सीमा, आरक्षण, पोर्ट फ़ॉरवर्डिंग, और वह हर उपकरण जिसका पता हाथ से लिखा गया है।
2. फिर रखरखाव विंडो के भीतर राउटर का LAN प्रीफ़िक्स और DHCP सीमा साथ बदलें, और वायर्ड लीज़ को वायरलेस से पहले नवीनीकृत करें।
3. इसके बाद स्थिर पतों को ठीक करें: प्रिंटर, नेटवर्क स्टोरेज, और हर वह चीज़ जिसका गेटवे कठोरता से लिखा है।
4. अंत में, VPN क्लाइंट फिर से जोड़ें और पुष्टि करें कि टनल का पता अब LAN से नहीं टकराता।

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

एक उपनाम क्या कर सकता है और क्या नहीं

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

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

जिन प्रीफ़िक्स पर आप तय हुए, उन्हें वहाँ लिखें जहाँ लोग सचमुच देखते हैं: नेटवर्क नोट्स, राउटर का अपना टिप्पणी फ़ील्ड, परिचय पेज। कोई फिर 192.168.1.0/24 चुनेगा, और टकराव उसके साथ लौट आएगा।