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 आणि कार्यरत नाव राउटिंगकडे निर्देश करते; दोन्ही अयशस्वी झाल्यास सामान्यतः टनेल मार्गात नाही।
नंतर आत नाही, बाहेर पहा। टनेलच्या टोकाच्या स्वतःच्या मार्गाने बदल टिकून राहिला पाहिजे, आणि कोणताही अडवणारा बिघाड टोक पकडल्याशिवाय टनेलपर्यंत मर्यादित असला पाहिजे। टनेल पडल्यानंतरही ब्राउझिंग सुरू ठेवणारा क्लायंट राउटिंगची नाही, धोरणाची समस्या आहे, आणि तो वरील तीन चाचण्यांपैकी कोणत्याहीत दिसणार नाही।
अंतिम यादी प्रोफाइलच्या दस्तऐवजीकरणात लिहा: मार्ग, रिझॉल्व्हर, डोमेन आणि प्रत्येक का आहे याचे कारण। तोच तक्ता पुन्हा निर्माण करणारे पुनर्कनेक्शन हाच स्थानिक धोरण पूर्ण असल्याचा एकमेव पुरावा आहे। टनेल वर असताना आणि तीनही चाचण्या उत्तीर्ण होऊनही ॲप्स अयशस्वी होत असतील, तर पुढे पाहण्याची जागा आधीच सत्यापित प्रमाणपत्रे नाही, तर «जोडलेले पण ऑफलाइन» या वर्गातील समस्या आहे।