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 पडल्यावर स्वतः मागे घेतला जात नाही, त्यामुळे जुना पुढील हॉप बोगदा नाहीसा झाल्यावर बराच काळानंतरही तो प्रीफिक्स काळ्या खड्ड्यात बदलू शकतो.