OpenVPN अजूनही जुने मार्ग ढकलत आहे? त्याने काय लोड केले ते तपासा

तुम्ही मार्ग जोडता, सेवा पुन्हा सुरू करता, पुन्हा जोडता, आणि क्लायंटचे तक्ते अगदी पूर्वीप्रमाणेच दिसते. दोन वेगळ्या गोष्टी खऱ्या असू शकतात: सर्व्हरने तुमचा बदल लोड केला नाही, किंवा क्लायंटने मिळालेले इन्स्टॉल केले नाही. लक्षणाशिवाय दोन्हींत काहीही साम्य नाही, म्हणून पहिली पायरी म्हणजे तुमच्याकडे कोणती स्थिती आहे हे शोधणे.

खालील तुलना प्रक्रियेपासून बाहेरच्या दिशेने जाते, कारण कोणती फाइल अमलात आहे हे फक्त प्रक्रियेलाच माहीत असते.

तुम्ही संपादित केलेली फाइल आणि प्रक्रिया वाचत असलेली फाइल

unit आणि त्याने तयार केलेल्या कमांड लाइनपासून सुरुवात करा. systemd होस्टवर systemctl cat openvpn@server ExecStart ओळ छापते, आणि इन्स्टन्स unit सहसा आपला कॉन्फिगरेशन मार्ग इन्स्टन्सच्या नावावरून काढते, म्हणून openvpn@office म्हणून सुरू केलेला डीमन openvpn@server म्हणून सुरू केलेल्यापेक्षा वेगळी फाइल वाचतो. हे चालू प्रक्रियेच्या argv शी तुलना करा. कॉन्फिगरेशन व्यवस्थापन साधन बदल गमावण्याचा आणखी एक मार्ग जोडते: ते योग्य फाइल unit कधीच नमूद न करणाऱ्या ठिकाणी लिहू शकते, आणि मग यशस्वी डिप्लॉय काहीच न केल्यासारखे दिसते.

टाइमस्टॅम्प हे लवकर ठरवतात: फाइल प्रक्रियेच्या सुरुवातीच्या वेळेपेक्षा नवीन असेल, तर प्रक्रियेने ती वाचलेली असू शकत नाही. राउटरचे फर्मवेअर तिसरी स्थिती जोडते, कारण अनेक मॉडेल त्यांची सेटिंग्ज flash मध्ये ठेवतात आणि बूट होताना कॉन्फिगरेशन पुन्हा तयार करतात, ज्यामुळे डिस्कवरील फाइल संपादन पूर्ण चुकीचा स्तर ठरतो.

सर्व्हर काय ढकलतो आणि क्लायंट काय इन्स्टॉल करतो

ढकललेल्या मार्गाला दोन फिल्टर पार करावे लागतात. सर्व्हरवर तो लोड केलेल्या कॉन्फिगरेशनमध्ये असावा, कमेंट केलेल्या ब्लॉकमध्ये किंवा नाव जुळत नाही अशा क्लायंट-विशिष्ट फाइलमध्ये नाही. क्लायंटवर pull सक्षम असावे आणि कोणतेही pull-filter तो पर्याय टाकून देऊ नये. verbosity 4 ने कनेक्ट करा आणि क्लायंट ज्या ढकललेल्या पर्यायांची नोंद करतो त्या वाचा: मार्ग त्या यादीत असेल, तर सर्व्हरने आपले काम केले आहे आणि तो इन्स्टॉल न करण्याचा निर्णय क्लायंट घेत आहे.

क्लायंट-विशिष्ट फाइल्स गोंधळाचे नेहमीचे कारण असतात. प्रमाणपत्राच्या common name वरून नाव दिलेली फाइल फक्त त्या क्लायंटलाच पर्याय ढकलते, आणि एका अक्षराचा फरक ढकलणे शांतपणे थांबवतो, दोन्ही बाजूंना त्रुटी दिसत नाही. सर्व्हर कनेक्ट होताना पाहिलेले common name नोंदवतो, म्हणून ते मूल्य फाइलच्या नावाशी तुलना करा, क्लायंटचे नाव असे तुम्हाला वाटते त्याच्याशी नाही.

ढकललेला उपसर्ग आणि परतीचा मार्ग वेगळ्या समस्या आहेत

आपला स्थानिक इंटरनेट मार्ग राखण्यासाठी redirect-gateway जाणूनबुजून दुर्लक्षणारा क्लायंट दुसरी, असंबंधित तफावत निर्माण करतो. सर्व्हरच्या प्रोब टनेलच्या पत्त्यापर्यंत पोहोचतात, पण उत्तरे कधीच येत नाहीत, कारण सर्व्हरच्या टनेल IP ला पाठवलेले उत्तर क्लायंटच्या नेहमीच्या डीफॉल्ट गेटवेमधून मार्गस्थ होते. इथे ढकललेला सबनेट मार्ग दोषी नाही; जे नाही ते म्हणजे सर्व्हरच्या टनेल नेटवर्कचा रहदारी टनेल उपकरणातून परत पाठवणारा मार्ग.

क्लायंटवर तो मार्ग जोडल्याने सर्व्हरने सुरू केलेल्या प्रोबना उत्तरे सुधारतात. तो ढकललेल्या सबनेट मार्गाचा पर्याय नाही, आणि उलटेही तसेच आहे, कारण दोन्ही विरुद्ध दिशा दर्शवतात.

दोन्ही टोकांवरील तक्ते तुलना करा

कोणताही बदल केल्यानंतर पुन्हा कनेक्ट करा आणि ढकललेल्या उपसर्गासाठी व टनेल उपकरणासाठी क्लायंटचे तक्ते वाचा. नंतर दोन्ही दिशांनी चाचणी करा: क्लायंटपासून ढकललेल्या सबनेटमधील होस्टपर्यंत, आणि त्या होस्टपासून परत क्लायंटपर्यंत. मार्ग अस्तित्वात असूनही रहदारी वाहत नसेल, तर तीनपैकी एक गोष्ट आहे: पलीकडची बाजू पुढे पाठवत नाही, फायरवॉल प्रवाह टाकून देत आहे, किंवा उत्तराला परतीचा रस्ता नाही.

तीन ओळखी एकत्र ठेवा: कॉन्फिगरेशन मार्ग, unit किंवा इन्स्टन्सचे नाव, आणि तुम्ही चाचणी केलेली क्लायंट ओळख.

हे तीन पुढील घटनेला पुन्हा तपासणीऐवजी पाच मिनिटांची तपासणी बनवतात, आणि टनेल दुसऱ्याची समस्या झाल्यावर सहकाऱ्याला याचीच गरज असते.

रीस्टार्टनंतरही टिकणारी मार्ग समस्या बऱ्याचदा राउटिंग समस्या नसतेच; बिघाड तुम्ही सतत वाचत असलेल्या तक्त्याच्या वरच्या स्तरावर असतो.