OpenVPN मार्ग योजनामा bypass-dhcp ले वास्तवमा के थप्छ

redirect-gateway def1 bypass-dhcp भएको प्रोफाइलले IPv4 पूर्वनिर्धारित मार्गको प्रतिस्थापनलाई एउटा साँघुरो अपवादसँग जोड्छ। मानिसहरू अन्तिम शब्द पढ्छन् र मोबाइल जडानका लागि सामान्य समाधान आशा गर्छन्, त्यसपछि यो फ्ल्यागले कहिल्यै समर्थन नगरेको DHCP सिद्धान्तमा दिउँसो बिताउँछन्। प्रत्येक भागले एउटा काम गर्छ, र अपवाद यसको प्रतिष्ठाभन्दा धेरै सानो छ।

मोबाइल सञ्जालमा मात्र हुने असफलतालाई ठेगाना बाँडफाँटमा थोप्नुअघि फ्ल्यागहरू अलग गर्नुहोस्। त्यो स्ट्रिङका दुई आधा भागको एकअर्कासँग कुनै सम्बन्ध छैन।

दुई फ्ल्याग, दुई असम्बन्धित काम

def1 सँग, क्लाइन्टले पहिल्यै भएको पूर्वनिर्धारित मार्ग बदल्नुको सट्टा दुई IPv4 आधा-पूर्वनिर्धारित मार्ग थप्छ। 0.0.0.0/1 ले ठेगाना क्षेत्रको तल्लो आधा र 128.0.0.0/1 ले माथिल्लो आधा ढाक्छ, त्यसैले सँगै ती हरेक गन्तव्यमा पुग्छन्, जबकि प्रत्येक 0.0.0.0/0 भन्दा बढी विशिष्ट रहन्छ। त्यसैले मूल पूर्वनिर्धारित मार्ग ती खोजी नजित्दै तालिकामा रहन्छ, जसले पुरानो गेटवेलाई क्लाइन्टले स्पष्ट रूपमा रुट गर्ने सबैका लागि पहुँचयोग्य राख्छ। यसले तालिकामा दुई ओभरल्याप हुने पूर्वनिर्धारित मार्ग पनि छोड्छ, र त्यसैले मार्ग डम्प प्रोफाइलले संकेत गरेभन्दा अनौठो देखिन सक्छ।

bypass-dhcp छुट्टै छ, र यसले पूर्वनिर्धारित मार्गलाई अलिकति पनि छुँदैन। OpenVPN 2.6 पुस्तिका यसलाई स्थानीय सबनेटमा नभएको DHCP सर्भरतर्फ सिधा मार्ग थप्ने रूपमा वर्णन गर्छ, जसले लिज ट्राफिक सुरुङबाहिर जान्छ, र यो व्यवहार Windows क्लाइन्टहरूमा लागू गरिएको र अन्यत्र उपलब्ध नहुन सक्ने उल्लेख गर्छ।

यसको अस्तित्वको कारण यान्त्रिक छ। आधा-पूर्वनिर्धारित मार्गहरूले बाहिर जाने ट्राफिक समातेपछि, भौतिक सञ्जालको सर्भरतर्फ लक्षित DHCP नवीकरण, कुनै कुराले त्यो ठेगानालाई वास्तविक इन्टरफेसमा पिन नगरेसम्म, सुरुङभित्र रुट हुनेछ। फ्ल्यागले त्यसलाई पिन गर्छ।

अपवाद वास्तवमा केमा सीमित छ

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

0.0.0.0/1        via 10.8.0.1      dev tun0
128.0.0.0/1      via 10.8.0.1      dev tun0
192.168.1.1/32   via 192.168.1.254 dev wlan0

त्यो तेस्रो लाइनले एउटा गन्तव्यको नाम दिन्छ। यो रिजोल्भर सेटिङ होइन, स्थानीय सञ्जालका लागि सामान्य अनुमति होइन र सर्भरमा एग्रेस नियम होइन। सेलुलर बियररमा रहेको फोनसँग क्लाइन्टले यसरी पहिचान गर्न सक्ने DHCP सर्भर नहुन सक्छ, र त्यसैले फ्ल्यागले त्यहाँ केही बदल्दैन।

क्लाइन्टले वास्तवमा के स्थापना गर्‍यो जाँच्नुहोस्

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

VPN अन्त्य बिन्दुसम्मको मार्गलाई पनि उही समयमा उपयोगी राख्नुहोस्। त्यो अन्त्य बिन्दु अपवाद DHCP अपवादभन्दा फरक आवश्यकता हो, र त्यो बिना सुरुङले आफूलाई टिकाउने यातायात नै समात्न सक्छ।

कुनै अनुप्रयोग गन्तव्यका लागि, जहाँ असफल हुन्छ त्यही सन्दर्भमा प्रभावकारी खोजी जाँच्नुहोस्। बढी विशिष्ट स्थानीय मार्ग, नीति-आधारित रुटिङ र प्रति-अनुप्रयोग बहिष्कारले उत्तर बदल्छन्, त्यसैले दुई आधा-पूर्वनिर्धारित मार्ग हुनु भनेको हरेक प्रवाहको सूची होइन।

बाँकी मार्ग यो फ्ल्यागमा छैन

सर्भरलाई अझै क्लाइन्टको इन्टरनेट ट्राफिक फर्वार्ड गर्ने अनुमति र त्यसलाई फर्काउन सक्ने एग्रेस व्यवस्था चाहिन्छ। क्लाइन्ट-पक्षको कुनै मार्गले सर्भरमा छुटेको फर्वार्डिङ वा स्रोत-अनुवाद सिर्जना गर्दैन, र कुनै फ्ल्यागले काम गर्ने फर्कने मार्गको विकल्प हुँदैन।

नाम समाधान र IPv6 दुवैलाई आफ्नै नीति चाहिन्छ। IPv4 प्रतिस्थापनले न रिजोल्भरलाई सुरुङ-पक्षको सर्भरतर्फ फर्काउँछ न IPv6 कभरेज स्थापना गर्छ, र केवल v4 मात्र रिडाइरेक्ट गर्ने क्लाइन्टले v6 मार्गलाई अछुतो राख्छ।

प्रोफाइल र गन्तव्य स्थिर राखेर एउटा स्वीकृत हानिरहित अनुरोधलाई काम गर्ने र असफल हुने पहुँच मार्गमा तुलना गर्नुहोस्। भिन्नता नाम समाधान, सुरुङ स्थापना, मार्ग छनोट वा फर्वार्ड गरिएको ट्राफिकमा छ कि भनी अभिलेख गर्नुहोस्, र उत्तर प्रोफाइलसँगै राख्नुहोस्। त्यही अभिलेखले अर्को व्यक्तिलाई पुग्नै नसक्ने समस्यामा DHCP लाई दोष दिनबाट रोक्छ।