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 या इंस्टेंस का नाम, और वह क्लाइंट पहचान जिससे आपने परीक्षण किया।

ये तीन अगली घटना को दोबारा जाँच के बजाय पाँच मिनट की जाँच बना देते हैं, और जब टनल किसी और की समस्या बन जाए तो सहकर्मी को इन्हीं की ज़रूरत होती है।

रीस्टार्ट के बाद भी बनी रहने वाली रूट समस्या अक्सर राउटिंग समस्या ही नहीं होती; ख़राबी उस तालिका से ऊपर होती है जिसे आप बार-बार पढ़ते रहते हैं।