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 को दोष देने से रोकता है जहाँ वह पहुँच ही नहीं सकता।