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 र काम गर्ने नामले रुटिङतर्फ संकेत गर्छ; दुवै असफल भए सामान्यतया टनेल बाटोमा छैन।
त्यसपछि भित्रतर्फ होइन, बाहिरतर्फ हेर्नुहोस्। टनेलको अन्तिम बिन्दुको आफ्नै रुटले परिवर्तन सहनुपर्छ, र कुनै पनि अवरोधक असफलता अन्तिम बिन्दु नसमाती टनेलभित्र सीमित हुनुपर्छ। टनेल खसिसकेपछि पनि ब्राउजिङ जारी राख्ने क्लाइन्ट रुटिङको होइन, नीतिको समस्या हो, र त्यो माथिका तीन परीक्षणमध्ये कुनैमा देखिनेछैन।
अन्तिम सूची प्रोफाइलको कागजातमा लेख्नुहोस्: रुट, रिजोल्भर, डोमेन र प्रत्येक किन छ भन्ने कारण। त्यही तालिका पुनः उत्पादन गर्ने पुनःजडान नै स्थानीय नीति पूर्ण भएको एकमात्र प्रमाण हो। टनेल माथि हुँदा र तीनै परीक्षण उत्तीर्ण हुँदा पनि एपहरू असफल भइरहे भने अर्को हेर्ने ठाउँ पहिले नै प्रमाणित प्रमाणपत्र होइन, «जोडिएको तर अफलाइन» वर्गका समस्या हुन्।