नेटवर्क तैयार होने से पहले OpenVPN का शुरू होना विफलता नहीं है

आप बूट के समय क्लाइंट शुरू करते हैं, यूनिट सक्रिय बताती है, और टनल नहीं है। स्वाभाविक निष्कर्ष यह है कि सेवा शुरू नहीं हो सकी, और स्वाभाविक उपाय यह है कि उसे फिर से शुरू करें। दोनों इतने अक्सर गलत होते हैं कि एक नियम बनना चाहिए: फिर से प्रयास करता चलता क्लाइंट बाहर से बिल्कुल टूटे क्लाइंट जैसा दिखता है। अंतर इसमें है कि प्रक्रिया क्या कर रही है, यूनिट की स्थिति में नहीं।

मिथक: शुरू हुई सेवा का अर्थ है काम करता टनल

सक्रिय यूनिट सिद्ध करती है कि प्रक्रिया शुरू की गई और बंद नहीं हुई। यह सिद्ध नहीं करती कि प्रोफ़ाइल लोड हुआ, प्रमाणपत्र स्वीकार हुआ, या दूसरे सिरे ने उत्तर दिया। पैकेज्ड क्लाइंट मिनटों तक पुनःप्रयास लूप में बैठ सकता है, जबकि systemd केवल सफलता की सूचना देता है। स्थिति और व्यवहार के बीच यही अंतर पूरा विषय है।

उल्टा मामला भी उतना ही सामान्य है। प्रक्रिया कुंजी न पढ़ पाने के बाद बंद हो सकती है, और फिर यूनिट एक असफल स्थिति बताती है जो कारण के बारे में कुछ नहीं कहती। दोनों स्थितियों को अलग करने के लिए लॉग चाहिए।

यूनिट की स्थिति के बजाय इंस्टेंस के लिए जर्नल पढ़ें। कारण की पंक्ति लॉग में है, स्थिति लेबल में नहीं।

मिथक: पुनःप्रयास सेटिंग्स हर विफलता को कवर करती हैं

नाम रिज़ॉल्यूशन और ट्रांसपोर्ट पुनःप्रयास अलग-अलग डिफ़ॉल्ट वाले अलग नियंत्रण हैं। resolv-retry दूरस्थ होस्टनाम की बार-बार खोज को नियंत्रित करता है, और प्रलेखित डिफ़ॉल्ट अनंत काल तक प्रयास करता रहता है। connect-retry प्रयासों के बीच का अंतराल तय करता है, जबकि connect-retry-max सीमित कर सकता है कि प्रत्येक दूरस्थ प्रविष्टि कितनी बार आज़माई जाए। इनमें से कोई भी बदलने से पहले देखें कि लॉग किस चरण का नाम लेता है।

इनमें से कुछ भी विकृत प्रोफ़ाइल, अपठनीय निजी कुंजी या अस्वीकृत खाते पर लागू नहीं होता। इन्हें सुधार चाहिए, और जो क्लाइंट इन्हें बार-बार आज़माता है वह आगे नहीं बढ़ता।

अस्वीकृत प्रमाणपत्र को हमेशा के लिए फिर से आज़माना सत्यापन हटाने का कारण नहीं है। यह त्रुटि पढ़ने का कारण है।

मिथक: एक लॉन्चर पर्याप्त है, इसलिए दूसरा जोड़ें

NetworkManager या पैकेज्ड यूनिट द्वारा पहले से प्रबंधित कनेक्शन को दूसरे लॉन्चर की ज़रूरत नहीं है। एक ही रूट के लिए प्रतिस्पर्धा करती दो प्रक्रियाएँ दोहरे इंटरफ़ेस, भ्रमित करने वाले लॉग और ऐसी टनल बनाती हैं जो ऐसे कारणों से लड़खड़ाती है जो कोई नहीं देखता। दूसरी प्रति आमतौर पर पहली के धीमा होने का उपाय बनकर आती है।

तय करें कि टनल का स्वामी कौन-सा घटक है कुछ भी जोड़ने से पहले। फिर दूसरे लॉन्चर को निष्क्रिय करके आशा रखने के बजाय हटा दें।

स्वामी यह भी तय करता है कि पुनःप्रयास और क्रेडेंशियल कहाँ से आते हैं, इसलिए यह निर्णय किसी भी ट्यूनिंग से पहले आता है। स्वामित्व पहले आने का कारण ठीक यही है।

वास्तव में किसे क्रम चाहिए

क्रम किसी कॉन्फ़िगर किए गए पते का इंतज़ार कर सकता है, और यही उसकी पूरी गारंटी है। network-online.target सक्रियण को तब तक टालता है जब तक प्रबंधक नेटवर्क को ऊपर न माने, और ऊपर होने की परिभाषा प्रबंधक पर निर्भर है। यह नहीं बताता कि VPN होस्टनाम हल होता है, श्रोता उत्तर देता है, या कैप्टिव पोर्टल ने डिवाइस को अंदर आने दिया।

निर्भरताएँ जोड़ने से पहले इंस्टॉल की गई यूनिट और कोई भी drop-in पढ़ें। हर नेटवर्क सेवा पर विस्तृत After= बूट को टालता है, वह कनेक्शन बनाए बिना जो वास्तव में आपको चाहिए।

जिस निर्भरता को आप जाँच सकते हैं उसे क्रम में रखें, और बाकी सब कुछ तैयारी-जाँच से जाँचें। टनल खोलने वाली जाँच अनुमान लगाने वाले टाइमर से बेहतर है।

टनल के पहली बार ऊपर आने के बाद क्या होता है

बूट कई घटनाओं में से एक है। एक्सेस लिंक बदलता है, पोर्टल सत्र समाप्त होता है, पीयर फिर से शुरू होता है। आंतरिक पुनःकनेक्शन को उस प्रक्रिया-निकास से अलग पहचानें जिसे सेवा प्रबंधक संभालता है, क्योंकि दोनों के स्वामी अलग हैं और अलग सबूत छोड़ते हैं।

इंटरैक्टिव प्रमाणीकरण बिना निगरानी वाली पुनर्प्राप्ति को सीमित करता है। पृष्ठभूमि यूनिट डेस्कटॉप कीरिंग नहीं खोलती और MFA अनुरोध का उत्तर नहीं देती, इसलिए सेवा संदर्भ के लिए अनुमोदित क्रेडेंशियल व्यवस्था का पालन करें।

टनल बंद रहने के दौरान ऐप्लिकेशन क्या कर सकते हैं, यह अलग से तय करें। पुनःप्रयास कनेक्शन बहाल करता है, जबकि ब्लॉकिंग नीति तय करती है कि उस अंतराल में सीधा ट्रैफ़िक अनुमत है या नहीं।