LAN राउटर र VPN क्लाइन्ट: दुई उपकरण, दुई रुट तालिका

दुई उपकरणले प्याकेट अगाडि पठाउँछन् र प्रत्येकले आफ्नै तालिका राख्छ। LAN राउटरलाई थाहा छ कि टाढाको प्रिफिक्स VPN क्लाइन्टको हो, र VPN क्लाइन्टलाई थाहा छ कि त्यो प्रिफिक्समा आफ्नो टनेलबाट कसरी पुग्ने। पहिलो तालिका मात्र कन्फिगर गर्नुहोस् र प्याकेट मिल्ने रुट नभएको मेसिनमा पुग्छ, त्यसैले यो फेरि डिफल्टबाट बाहिर जान्छ। यो नै सम्पूर्ण खराबी हो, र LAN पक्षबाट यो रुटिङ लूप जस्तो देखिन्छ, किनकि लगभग त्यही हो।

कुनै रुट छुनुअघि दुई हप कोर्नुहोस्

एउटा उदाहरणीय लेआउट लिनुहोस्: LAN होस्टहरू 192.168.50.0/24 मा, सामान्य राउटर 192.168.50.1 मा, समर्पित क्लाइन्ट 192.168.50.15 मा, र टाढाको LAN 10.60.0.0/24 मा जुन त्यो क्लाइन्टसँग भएको टनेलबाट मात्र पुग्न सकिन्छ। दुई निजी दायरामध्ये कुनै पनि अर्कोसँग ओभरल्याप हुँदैन, र टनेलको आफ्नै ठेगाना योजना छ।

दुवै निजी दायरा महत्त्वपूर्ण छन् किनकि तिनले कुन उपकरणले जवाफ दिन सक्छ भनेर निर्धारण गर्छन्। टाढाको पक्षले प्याकेट क्लाइन्टको टनेल ठेगानाबाट आएको देख्नेछ, र त्यसको जवाफले 192.168.50.0/24 मा फर्कने बाटो खोज्नुपर्छ। यदि बाहिर जाने दिशा मात्र कन्फिगर गरिएको छ भने, अनुरोध काम गर्न सक्छ जबकि जवाफ हराउँछ।

चरण 1: राउटरलाई टनेलतिर होइन, क्लाइन्टतिर फर्काउनुहोस्

LAN राउटरमा, अर्को हप क्लाइन्टको LAN ठेगाना हुने गन्तव्य रुट थप्नुहोस्:

ip route add 10.60.0.0/24 via 192.168.50.15
ip route get 10.60.0.55

त्यो रेकर्डले “यसलाई टनेल गर्न सक्ने मेसिनमा पुर्याऊ” भन्छ। यसले टनेल कसरी बन्छ भन्ने बारे केही भन्दैन, र यो क्लाइन्टको आफ्नै रुटको विकल्प होइन। व्यवस्थापित राउटरमा समकक्ष उपकरणको स्थिर रुट पृष्ठमा रहन्छ; Linux राउटरमा यो LAN को मालिक इन्टरफेसको कन्फिगरेसनमा पर्छ, तपाईं बन्द गर्ने शेलमा होइन।

दोस्रो कमाण्डको जवाफ जाँच्नुहोस्। यदि यसले क्लाइन्टलाई gateway र LAN इन्टरफेसलाई device भनेर रिपोर्ट गर्छ भने, पहिलो हप सही छ र बाँकी काम अर्को मेसिनमा छ।

चरण 2: क्लाइन्टलाई टनेलको पट्टि आफ्नै रुट दिनुहोस्

क्लाइन्टले अब 10.60.0.0/24 का लागि प्याकेट प्राप्त गर्छ र आफ्नै तालिका हेर्छ। यदि यसको टनेल कन्फिगरेसनले त्यो प्रिफिक्सका लागि रुट स्थापना गरेको छ भने, प्याकेट इन्क्रिप्टेड रहन्छ। यदि गरेन भने, प्याकेट सामान्य डिफल्टसँग मिल्छ र 192.168.50.1 मा फर्कन्छ, जसले यसलाई फेरि क्लाइन्टमा पठाउँछ।

केही थप्नुअघि हेर्नुहोस्:

ip route show table all | grep -E "10\.60\.0\.0/24|default"
sysctl net.ipv4.ip_forward

हरेक तालिकामा प्रिफिक्स रुट नहुनु नै तपाईंले खोजिरहेको निष्कर्ष हो। यसलाई टनेलको आफ्नै कन्फिगरेसनमार्फत थप्नुहोस्, ताकि अर्को पुन: जडानले यसलाई फेरि स्थापना गरोस्; हातले गरिएको ip route add सत्रसँगै हराउँछ र सबैभन्दा असुविधाजनक समयमा खराबी फर्काउँछ। अर्को हप टनेल इन्टरफेस हो वा VPN ले आफ्नो पियरका रूपमा दिने ठेगाना हो, क्लाइन्टमा निर्भर, र पियर ठेगाना पुरानो नोटबाट होइन, हालको प्रोफाइलबाट आउनुपर्छ।

लूप, जब हुन्छ, व्यवहारमा अनन्त हुँदैन: हरेक पासमा TTL घट्छ र प्याकेट समय नाघ्यो भन्ने सन्देशसँग मर्छ। त्यसैले बारम्बार गरिएको traceroute ले चक्र संकेत गर्न सक्छ, जबकि फर्वार्ड नगर्ने क्लाइन्टले त्यही प्याकेट चुपचाप खसाल्छ।

चरण 3: फर्वार्डिङलाई अनुमति दिनुहोस् र फर्कने बाटो छान्नुहोस्

प्राप्त गर्नु र फर्वार्ड गर्नु फरक अनुमति हुन्। क्लाइन्टमा net.ipv4.ip_forward=1 ले कर्नेल स्तरमा ट्रान्जिटलाई अनुमति दिन्छ, र फायरवाल नियमले यसलाई LAN इन्टरफेस र टनेलबीच अझै अनुमति दिनुपर्छ। क्लाइन्टको आफ्नै व्यवस्थापन पृष्ठमा पहुँच अनुमति दिने नियमले टाढाको LAN मा ट्रान्जिट अनुमति दिँदैन, र त्यही होस्टले स्थानीय रूपमा ping को जवाफ दिँदा यो भिन्नता छुट्न सजिलो छ।

टाढाको पक्षसँग ऐनाजस्तो समस्या छ। यसलाई थाहा हुनुपर्छ कि 192.168.50.0/24 यो प्रमाणित क्लाइन्टमार्फत पुग्न सकिन्छ। OpenVPN सँग यो सामान्यतया सर्भर कन्फिगरेसनले धकेल्ने प्रति-क्लाइन्ट रुट, वा सर्भरमा क्लाइन्टको पछाडिको LAN घोषणा गर्ने क्लाइन्ट-विशिष्ट फाइललाई जनाउँछ। त्यो नभए, टाढाको LAN ले या जवाफ खसाल्छ या आफ्नै डिफल्ट गेटवेमा, अर्थात् इन्टरनेटमा पठाउँछ।

LAN प्रिफिक्स घोषणा गर्न नसकिँदा स्रोत अनुवाद विकल्प हो। क्लाइन्टमा सीमित masquerade नियमले स्रोतलाई टनेल ठेगानामा पुनः लेख्छ, र जवाफहरू त्यसपछि स्वाभाविक रूपमा फर्कन्छन्। यसले कुन LAN होस्टले अनुरोध गर्यो भन्ने पनि लुकाउँछ, र आफैंले टाढाको पक्षलाई भित्रतिर जडान सुरु गर्न दिँदैन। सर्वव्यापी masquerade थपेर पछि साइड इफेक्ट पत्ता लगाउनुभन्दा यो सम्झौता जानाजान छान्नुहोस्।

चरण 4: दुवै निर्णय टिकाउ बनाउनुहोस्, त्यसपछि वास्तविक बाटो परीक्षण गर्नुहोस्

हरेक रुटको एक मालिक हुन्छ, र मालिक भनेको बुटमा वा पुन: जडानमा फेरि बन्ने कन्फिगरेसन हो। राउटरमा यो स्थिर रुट प्रविष्टि हुन सक्छ; क्लाइन्टमा यो VPN प्रोफाइल, NetworkManager वा systemd-networkd हुन सक्छ। टनेल फेरि जोडेर र क्लाइन्ट रिबुट गरेर प्रमाणित गर्नुहोस्, त्यसपछि परिवर्तनमा भरोसा गर्नुभन्दा तालिका फेरि पढ्नुहोस्।

टनेलको बाहिरी जडान बोक्ने डिफल्ट रुट अक्षुण्ण राख्नुहोस्। सेटअप “सरल” बनाउन यसलाई बदल्नाले कुनै पनि आन्तरिक ट्राफिकले प्रयोग गर्नुअघि नै इन्क्रिप्टेड बाटो तोडिन्छ, र लक्षण भनेको परिवर्तनपछि फेरि कहिल्यै स्थापित नहुने टनेल हो।

सामान्य LAN होस्टबाट परीक्षण गर्नुहोस्, क्लाइन्टबाट होइन, किनकि क्लाइन्टमा सुरु भएको अनुरोधले कहिल्यै राउटरको पहिलो हप प्रयोग गर्दैन। टाढाको LAN मा मात्र रहेको सेवा ल्याउनुहोस् र जवाफको मुख्य भाग पुष्टि गर्नुहोस्, त्यसपछि ट्रान्जिट भइरहेको देख्न क्लाइन्टका काउन्टर वा लगहरू हेर्नुहोस्। निजी हप देखाउने आन्तरिक traceroute ले फर्वार्डिङ प्रमाणित गर्छ, इन्क्रिप्सन होइन: बाहिरी बाटो छुट्टै अवलोकन हो, र टनेलको आफ्नै इन्टरफेस काउन्टरले मात्र यसबाट के बाहिर गयो देखाउँछ।