DHCP विकल्प 121 से LAN होस्ट को VPN रिटर्न रूट दें

दूरस्थ VPN क्लाइंट जुड़ते हैं, LAN सर्वर उत्तर देता है, और उत्तर सामान्य इंटरनेट राउटर से बाहर जाकर वहीं दम तोड़ देता है। एक सर्वर को स्थिर रूट से ठीक किया जा सकता है, पर उनका पूरा सबनेट उसी जगह संभालना बेहतर है जहाँ उन्हें पहले से नेटवर्क कॉन्फ़िगरेशन मिलता है। DHCPv4 विकल्प 121 ठीक इसी तरह का गंतव्य रूट बाँटता है, और यही वह हिस्सा है जिसमें लोग आमतौर पर डिफ़ॉल्ट भूलते ही गलती करते हैं। लक्षण एकतरफ़ा ट्रैफ़िक है: अनुरोध आते हैं और उत्तर गायब हो जाते हैं।

पहले तीन पते बताइए

एक ठोस LAN लें: 192.168.50.0/24, सामान्य डिफ़ॉल्ट राउटर 192.168.50.1 पर और अलग VPN गेटवे 192.168.50.2 पर। प्रमाणित दूरस्थ क्लाइंट 10.90.0.0/24 पर कब्ज़ा करते हैं।

हर भाग लेने वाले होस्ट को जो रूट चाहिए वह 10.90.0.0/24 via 192.168.50.2 है। गंतव्य क्लाइंट पूल है, और अगला हॉप गेटवे का LAN पता है, उसका टनल पता नहीं।

इसे वर्गहीन स्थिर रूट के रूप में एनकोड करें

विकल्प 121 प्रीफ़िक्स और अगले हॉप के जोड़े ढोता है, और RFC 3442 एनकोडिंग तथा उससे चलने वाले क्लाइंट व्यवहार दोनों को परिभाषित करता है। केवल इस उदाहरण LAN की सेवा करने वाले मौजूदा dnsmasq इंस्टेंस के लिए कॉन्फ़िगरेशन का रूप यह है:

dhcp-option=121,10.90.0.0/24,192.168.50.2,0.0.0.0/0,192.168.50.1

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

डिफ़ॉल्ट रूट न खोएँ

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

ऊपर का टुकड़ा जैसा करता है, वैसे ही इच्छित डिफ़ॉल्ट उसी सूची में शामिल करें। सामान्य Router विकल्प भी अपनी जगह रखें, उन क्लाइंट के लिए जो वर्गहीन रूट लागू नहीं करते; सर्वर का अपना विकल्प-प्रबंधन तय करता है कि किसे क्या भेजा जाए।

जाँचें कि क्लाइंट क्या स्वीकार करेगा

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

प्रबंधित DHCP सेवाएँ दूसरी सीमा हैं। कुछ क्लाउड नेटवर्क प्रशासकों को मनमाने विकल्प प्रकाशित करने नहीं देते, और उसी सेगमेंट पर प्रतिस्पर्धी DHCP सर्वर किसी विकल्प के न होने से भी बुरा है।

लीज़ जाँचें, फिर लुकअप

DHCP के मालिक से बदलाव लागू कराएँ, फिर किसी क्लाइंट पर लीज़ नवीनीकृत करें। मौजूदा लीज़ नवीनीकरण तक पुराना कॉन्फ़िगरेशन रखती हैं, इसलिए तुरंत परिणाम की गारंटी नहीं है।

Linux क्लाइंट पर वास्तविक रूट पढ़ें और दोनों प्रविष्टियाँ पुष्टि करें:

ip -4 route
ip -4 route get 10.90.0.23

प्रासंगिक लुकअप को पूल का रूट 192.168.50.2 से और डिफ़ॉल्ट 192.168.50.1 से दिखाना चाहिए। यदि डिफ़ॉल्ट गायब है, तो आपने ऊपर का जाल दोहरा दिया है।

फिर असली अदला-बदली परखें

रूट वितरण पूरा रास्ता नहीं है। अलग गेटवे को अब भी फ़ॉरवर्डिंग, दूरस्थ पीयरों का स्वामित्व और सर्वर की अनुमति देने वाली एक्सेस नीति चाहिए, और DHCP किसी को प्रमाणित नहीं करता।

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