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 ला दोष देण्यापासून रोखते।