OpenVPN का route-nopull वास्तव में सर्वर को क्या भेजने से रोकता है
route-nopull भेजे गए रूट और DHCP विकल्प गिराता है, हैंडशेक नहीं। इसके, pull-filter या कुछ नहीं के बीच चुनें, फिर रूट खुद जोड़ें।
आपने क्लाइंट प्रोफ़ाइल में route-nopull डाला ताकि टनल आपका डिफ़ॉल्ट रूट न निगले, और अब ऑफ़िस का सबनेट पहुँच से बाहर है जबकि क्लाइंट अब भी कहता है कि वह जुड़ा है। दोनों अवलोकन सही हैं, और कुछ भी विफल नहीं हुआ। यह फ़्लैग क्लाइंट से कहता है कि सर्वर जो रूट और DHCP प्रविष्टियाँ भेजता है उन्हें छोड़ दे, जो जोड़ते समय अधिकांश लोगों की अपेक्षा से संकरा निर्देश है। जो बचता है वह एक कार्यशील टनल है, बिना इस राय के कि कौन-से गंतव्य इसका इस्तेमाल करें।
यही अंतराल वह पूरा निर्णय है जिस पर यह लेख है। या तो सर्वर नेटवर्क का वर्णन करता है, या क्लाइंट करता है, और फ़्लैग वह काम क्लाइंट को सौंप देता है, आपके लिए उसमें से कुछ भी किए बिना।
कनेक्ट होते समय फ़्लैग क्या बंद करता है
खींचने वाला OpenVPN क्लाइंट सामान्यतः प्रमाणीकरण के बाद सर्वर से एक बंडल लेता है: रूट, डिफ़ॉल्ट गेटवे का पुनर्निर्देशन, DNS सर्वर और कुछ ट्यूनिंग निर्देश। route-nopull लागू होने पर क्लाइंट अब भी सत्र स्वीकार करता है, अब भी प्रमाणपत्र सत्यापित करता है, अब भी साइफ़र और keepalive पर बातचीत करता है, और अब भी इंटरफ़ेस ऊपर उठाता है। जो वह गिराता है वह भेजी गई route पंक्तियों और भेजी गई dhcp-option पंक्तियों का अनुप्रयोग है, DNS सहित।
भ्रम मृत ऐप के साथ लगे हरे संकेतक से आता है। टनल मौजूद है; गंतव्यों का उस टनल से मिलान नहीं। क्लाइंट के स्टेटस पैनल में कुछ भी «जुड़ा है और रूट कर रहा है» को «जुड़ा है और निष्क्रिय है» से अलग नहीं करता, क्योंकि टनल की दृष्टि से दोनों एक ही अवस्था हैं।
जीवित टनल फिर भी कुछ क्यों नहीं रूट कर सकती
इंटरफ़ेस अपने पते के साथ प्रकट होता है और पॉइंट-टू-पॉइंट लिंक पर अक्सर साथी तक के होस्ट रूट से ज़्यादा विशिष्ट कुछ नहीं होता। निजी सबनेट तभी पहुँच योग्य बनता है जब कोई रूट सही प्रीफ़िक्स के साथ उस इंटरफ़ेस की ओर इशारा करे, और भेजना बंद होने पर वह रूट कभी नहीं आता। डाउनलोड किया गया प्रोफ़ाइल भी सामान्यतः मदद नहीं कर सकता, क्योंकि वह इस मान्यता पर लिखा गया था कि सर्वर ठीक यही जानकारी देगा। इसीलिए इंटरफ़ेस स्वस्थ दिख सकता है जबकि सबनेट अंधेरा रहता है।
इसलिए प्रोफ़ाइल पढ़ना बहुत कम साबित करता है। इसके बजाय जुड़ी मशीन पर चल रही अवस्था पढ़ें:
ip addr show tun0
ip route show dev tun0
ip route get 10.20.5.10दूसरे कमांड में सबनेट रूट के बिना पता इस समस्या की पहचान है। तीसरा कमांड तब उस सवाल का जवाब देता है जो उपयोगकर्ताओं को वास्तव में मायने रखता है, क्योंकि वह उस इंटरफ़ेस की रिपोर्ट करता है जिसे कर्नेल किसी विशेष गंतव्य के लिए चुनेगा, न कि उस सूची की जिसके इस्तेमाल की आपको आशा थी। अगर यह आपके भौतिक लिंक से जवाब देता है, तो टनल रास्ते में ही नहीं है।
नाम हल करना किसी संबंधित कारण से विफल होता है, अलग कारण से नहीं। भेजी गई dhcp-option DNS प्रविष्टियाँ उसी फ़्लैग से छोड़ दी जाती हैं, इसलिए आंतरिक होस्ट के लिए क्वेरी उसी रिज़ॉल्वर के पास जाती हैं जो स्थानीय नेटवर्क ने दिया था। उस रिज़ॉल्वर के पास ऑफ़िस के लिए कोई ज़ोन नहीं है, इसलिए क्वेरी विफल होती है या सार्वजनिक उत्तर देती है, और विफलता सर्वर की समस्या जैसी दिखती है जबकि वह क्लाइंट कॉन्फ़िगरेशन की समस्या है। नाम से पहले पता जाँचना ही दोनों को अलग करता है।
फ़्लैग और प्रीफ़िक्स फ़िल्टर के बीच चुनाव
दोनों विकल्प एक ही शिकायत के अलग-अलग रूप हल करते हैं, और खराब चुनाव ही «जुड़ा पर बेकार» अवस्था पैदा करता है। एक भेजी गई नीति को पूरी तरह बदल देता है, दूसरा उसे प्रीफ़िक्स के अनुसार संपादित करता है। तालिका संक्षिप्त संस्करण देती है, और उसके बाद का अनुच्छेद वह हिस्सा समझाता है जो लोगों को चौंकाता है।
| Setting | What the client keeps | Reasonable when |
|---|---|---|
| no option | every pushed route and DHCP entry | the server's view of the network is correct |
route-nopull | the session, none of the pushed routing or DNS | you will write the full local policy yourself |
pull-filter | everything except lines matching your prefixes | the push is nearly right and one or two lines are wrong |
pull-filter तीन क्रियाओं वाला प्रीफ़िक्स मैचर है, इसलिए वह पंक्तियों के एक परिवार को स्वीकार कर सकता है, उन्हें चुपचाप अनदेखा कर सकता है, या प्रीफ़िक्स दिखने पर कनेक्शन सीधे अस्वीकार कर सकता है। वही अंतिम व्यवहार जानने योग्य है: अस्वीकार नियम नीति के मतभेद को चुपचाप छोड़ने के बजाय विफल हैंडशेक में बदल देता है। OpenVPN 2.6 मैनुअल स्वीकृत प्रीफ़िक्स और हर क्रिया का सटीक अर्थ सूचीबद्ध करता है।
एक आम मध्य मार्ग यह है कि केवल redirect-gateway अस्वीकार करें और ऑफ़िस के रूट और DNS को इरादे के अनुसार आने दें। यह उन हिस्सों के लिए भेजना काम करता रहता है जिन्हें सर्वर आपसे बेहतर समझता है, और साथ ही उस एक पंक्ति को रोकता है जो आपका डिफ़ॉल्ट रूट ले लेती।
हाथ से रूट और रिज़ॉल्वर जोड़ना
अगर आप फ़्लैग रखते हैं, तो प्रोफ़ाइल को वही कहना होगा जो सर्वर कहता। क्लाइंट-पक्ष के route निर्देश कनेक्शन स्थापित होने के बाद लागू होते हैं, इसलिए वे फ़्लैग के साथ काम करते हैं, उससे अवरुद्ध नहीं होते। उन्हें प्रोफ़ाइल में रखें, इंटरैक्टिव कमांड लाइन में नहीं, वरना अगला पुनःकनेक्शन काम करने वाली अवस्था नहीं दोहराएगा।
route-nopull
route 10.20.0.0 255.255.0.0
dhcp-option DNS 10.20.0.53DNS पंक्ति अटपटी स्थिति में है: यह क्लाइंट-पक्ष निर्देश है, लेकिन कुछ क्लाइंट इसे केवल प्लेटफ़ॉर्म के DNS एकीकरण से लागू करते हैं, जो लिंक बदलने पर इसके ऊपर लिख सकता है। systemd होस्ट पर रिज़ॉल्वर सीधे टनल इंटरफ़ेस पर सेट करना इस आशा से अधिक पूर्वानुमेय है कि क्लाइंट प्राथमिकता प्रतियोगिता जीत लेगा:
resolvectl dns tun0 10.20.0.53
resolvectl domain tun0 ~corp.example.comरूटिंग डोमेन पते जितना ही मायने रखता है। इसके बिना सार्वजनिक नामों की क्वेरी भी आंतरिक रिज़ॉल्वर को भेजी जा सकती हैं, और रिकर्शन से इनकार करने वाला कोई भी आंतरिक रिज़ॉल्वर निजी ज़ोन चालू रखते हुए ब्राउज़िंग तोड़ देगा। इसके साथ केवल उस प्रत्यय के अंतर्गत नाम टनल रिज़ॉल्वर की ओर रूट होते हैं और बाकी सब भौतिक लिंक का अनुसरण करता है।
परिणाम जाँचना: पता, नाम और बाहरी रास्ता
तीन परीक्षण संभावित विफलताओं को अलग करते हैं। पहले IP से निजी पता लें, फिर नाम से वही होस्ट, फिर एक सामान्य सार्वजनिक साइट। काम करता IP और विफल नाम रिज़ॉल्वर की ओर संकेत करता है; विफल IP और काम करता नाम रूटिंग की ओर संकेत करता है; दोनों विफल हों तो आम तौर पर टनल रास्ते में नहीं है।
फिर बाहर देखें, अंदर नहीं। टनल के अंतिम बिंदु का अपना रूट बदलाव से बचना चाहिए, और कोई भी अवरोधक विफलता अंतिम बिंदु को पकड़े बिना टनल तक सीमित होनी चाहिए। टनल गिरने के बाद भी ब्राउज़ करता रहने वाला क्लाइंट रूटिंग समस्या नहीं, नीति समस्या है, और वह ऊपर के तीन परीक्षणों में से किसी में नहीं दिखेगी।
अंतिम सूची प्रोफ़ाइल के दस्तावेज़ीकरण में लिखें: रूट, रिज़ॉल्वर, डोमेन और हर एक के होने का कारण। वही तालिका दोहराने वाला पुनःकनेक्शन ही इस बात का एकमात्र प्रमाण है कि स्थानीय नीति पूरी है। अगर टनल ऊपर होने और तीनों परीक्षण पास होने पर भी ऐप विफल रहते हैं, तो अगली जगह पहले से सत्यापित प्रमाणपत्र नहीं, बल्कि «जुड़ा पर ऑफ़लाइन» समस्याओं का वर्ग है।