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 खस्दा आफै फिर्ता हुँदैन, त्यसैले पुरानो अर्को हपले सुरुङ हराएको धेरैपछि पनि त्यो प्रिफिक्सलाई कालो खाल्डो बनाउन सक्छ।