vpn.persistent कोशिश करता रहता है, पर आपको जुड़ा नहीं रखता

NetworkManager एक प्रॉपर्टी उजागर करता है, vpn.persistent, और लोग इससे एक साथ चार अलग-अलग सवालों का जवाब मांगते हैं। इसका अपस्ट्रीम दस्तावेज़ सावधान है: दृढ़ता तब लागू होती है जब VPN सेवा इसे समर्थन देती है और प्रोफ़ाइल इसे सक्षम करती है, और फिर कनेक्शन से स्पष्ट डिस्कनेक्ट तक लिंक बदलावों और व्यवधानों को झेलने को कहा जाता है। वही दस्तावेज़ यह भी दिखाता है कि प्रॉपर्टी का डिफ़ॉल्ट मान false है, जो अधिकांश बहाली योजनाएं नहीं मानतीं। इसे परिणाम के वादे के बजाय एक प्रयास के अनुरोध के रूप में पढ़ें।

सेटिंग वास्तव में किस बात का वादा करती है

प्रोफ़ाइल में संग्रहीत मान प्रबंधक के लिए एक निर्देश है, और प्रबंधक को वह निर्देश ऐसे VPN प्लगइन को देना होता है जो जानता हो कि उसका क्या करना है। यदि स्थापित प्लगइन प्रॉपर्टी को नज़रअंदाज़ करता है, तो प्रोफ़ाइल फिर भी सक्रिय हो जाती है और लॉग शांत रहता है, जो बाद में डिबग करने वाले किसी भी व्यक्ति के लिए दोनों दुनियाओं का सबसे बुरा हिस्सा है। प्रोफ़ाइल के भीतर कुछ भी प्लगइन को ऐसा व्यवहार लागू करने के लिए मजबूर नहीं कर सकता जो उसके पास नहीं है, इसलिए एकमात्र दिखने वाला परिणाम अनुपस्थिति है।

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

प्रॉपर्टी को प्रयास मानना परीक्षण के लिए सही अपेक्षा भी तय करता है। आप यह नहीं जांचते कि फ़्लैग सेट है या नहीं; आप यह जांचते हैं कि लिंक गिरने पर कुछ हुआ या नहीं। ये अलग प्रयोग हैं, और इनमें से केवल एक ही एक दोपहर के लायक है।

चार सवाल जो एक में मिला दिए जाते हैं

सक्रियण पूछता है कि VPN को सबसे पहले ऊपर क्या लाता है। NetworkManager प्रोफ़ाइल किसी आधार कनेक्शन से बंधी हो सकती है, अलग से प्रबंधित OpenVPN सेवा का अपना स्टार्टअप होता है, और उस व्यवस्था में तीसरा लॉन्चर जोड़ने से आपको दो मालिक मिलते हैं जिनके इस बारे में अलग विचार हैं कि कौन प्रभारी है। दूसरा ट्रिगर जोड़ने से पहले तय करें कि कौन-सा घटक स्टार्टअप का मालिक है।

बहाली पूछती है कि लिंक बदलने या गायब होने पर क्या होता है, और यही वह संकीर्ण सवाल है जिसे vpn.persistent संबोधित करता है। जीवंतता पूछती है कि क्या क्लाइंट समझ सकता है कि दूर का सिरा जवाब देना बंद कर चुका है, और उसके बजाय OpenVPN का keepalive या पुनःआरंभ व्यवहार उसका जवाब देता है; दोनों तंत्रों को अक्सर एक ही शब्द से वर्णित किया जाता है और अलग जगहों पर लागू किया जाता है। उन्हें अलग-अलग, अलग औज़ारों से परखें, वरना आप एक व्यवहार को दूसरे पर थोप देंगे।

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

एक चेकलिस्ट जो इन्हें अलग रखती है

कॉन्फ़िगरेशन पढ़कर उस पर सोचने के बजाय घटनाओं को क्रम में चलाएं, और रिकॉर्ड करें कि प्रत्येक क्या दिखाती है, समय-छाप के साथ।

पहले, इच्छित आधार कनेक्शन सक्रिय करें और पुष्टि करें कि VPN उस ट्रिगर से ऊपर आया जिसकी आपको अपेक्षा थी, न कि किसी ऐसे तंत्र से जिसे स्थापित होना आप भूल गए थे। दूसरा, स्वीकृत व्यवधान के दौरान, प्रबंधक की VPN घटनाओं, मालिक क्लाइंट की बहाली स्थिति और किसी निजी संसाधन के लिए ताज़ा अनुरोध की तुलना करें। तीसरा, जानबूझकर डिस्कनेक्ट करें, प्रतीक्षा करें, और पुष्टि करें कि आपके पीछे कुछ भी प्रोफ़ाइल को पुनःआरंभ नहीं करता।

तीसरा चरण वही है जिसे लोग छोड़ देते हैं, और वही सबसे अधिक बार असली खराबी ढूंढता है। सक्रिय प्रोफ़ाइल की जांच करने वाला और उसके न होने पर पुनःकनेक्ट करने वाला वॉचडॉग उपयोगकर्ता के जानबूझकर किए गए डिस्कनेक्ट को खुशी-खुशी पूर्ववत कर देगा। उपयोगकर्ता की कुर्सी से यह लचीलापन नहीं है; यह ऐसी मशीन है जो आज्ञा नहीं मानेगी। एक जोड़ने से पहले उनसे पूछें।

परिणामों को कनेक्शन विवरण वाले उसी दस्तावेज़ में लिखें। बहाली नीति उतनी ही अच्छी होती है जितनी पिछली बार कोई उसे जानबूझकर विफल होते देखा था। समय-छाप अंतर को उस हर व्यक्ति के लिए दृश्यमान बनाती हैं जो आगे नोट्स पढ़ेगा।

प्रमाणीकरण बहाली का हिस्सा है

पुनःकनेक्ट होना केवल नेटवर्किंग कार्य नहीं है। यदि स्वीकृत प्रवाह को नई चुनौती, एक-बार का कोड, या ऐसा रहस्य चाहिए जिस तक सक्रियण संदर्भ पहुंच नहीं सकता, तो कोई भी दृढ़ता सेटिंग उसे शून्य से उत्पन्न नहीं कर सकती।

यह एक परिचित पैटर्न समझाता है: कनेक्शन ऐसी मशीन पर बहाल होता है जिसका कीरिंग अनलॉक है और रीबूट के बाद उसी मशीन पर विफल हो जाता है। नेटवर्किंग परत ने ठीक वही किया जो मांगा गया था और क्रेडेंशियल परत के पास देने के लिए कुछ नहीं था।

पुनःप्रयास अंतराल छोटा करने के बजाय क्रेडेंशियल कार्यप्रवाह ठीक करें। ऐसे प्रॉम्प्ट के सामने तेज़ पुनःप्रयास जिसका कोई जवाब नहीं दे सकता, लॉग में शोर और यह झूठी छाप पैदा करते हैं कि कुछ आज़माया जा रहा है।

दृढ़ता कोई kill switch नहीं है

प्रॉपर्टी VPN संबंध बनाए रखने या बहाल करने की कोशिश करती है। यह तय नहीं करती कि VPN बंद होने पर ऐप्लिकेशन क्या कर सकते हैं, और यह अपने आप कुछ भी अवरुद्ध नहीं करती।

यदि आवश्यकता यह है कि सुरंग के बाहर कोई ट्रैफ़िक न जाए, तो वह अपने स्वयं के तंत्र, अपने परीक्षण और अपने विफलता-तरीकों वाली अलग नीति है। यह मान लेना कि दृढ़ता इसे कवर करती है, सुरक्षा निर्णय को दुर्घटना में बदल देता है।

बहाली नोट्स में दोनों आधे लिखें: VPN ने क्या कोशिश की, और प्रयास के दौरान कौन-सा ऐप्लिकेशन ट्रैफ़िक अनुमत था।