Mac VPN, डिस्कनेक्ट दबाने के तुरंत बाद खुद से फिर जुड़ जाता है
हर डिस्कनेक्टेड स्थिति को खराबी मानने वाला मॉनिटर डिस्कनेक्ट बटन से लड़ेगा। मंशा और देखी गई स्थिति को अलग रखें, फिर पुनःप्रयासों को सीमित करें।
डिस्कनेक्ट दबाना काम करता है, और दस सेकंड बाद टनल वैसे भी वापस आ जाती है। यह लूप शायद ही कभी VPN क्लाइंट का गलत व्यवहार होता है; यह एक रिकवरी स्क्रिप्ट है जो हमेशा सिर्फ़ एक सवाल पूछती थी, «क्या यह नीचे है?», और जुड़कर उसका जवाब देती थी। जब आप उपयोगकर्ता द्वारा दिए गए जवाब के सवाल को सिस्टम द्वारा बताए जाने वाले सवाल से अलग करते हैं, तो सुधार लंबी नींद के बजाय थोड़ी सी स्थिति बन जाता है।
दो सवाल, एक नहीं
क्या यह प्रोफ़ाइल अभी जुड़ी होनी चाहिए, और सिस्टम इस समय क्या बताता है? ये अलग-अलग मालिकों वाले अलग सवाल हैं, और रिकवरी नीति को काम करने से पहले दोनों चाहिए। मंशा वह है जो आपका टूल तय करता है और याद रखता है। देखी गई स्थिति वह है जो प्लेटफ़ॉर्म आपको बताता है।
| Intent | What you observe | What to do |
|---|---|---|
| Wanted | Dropped unexpectedly | Allow one supported recovery attempt |
| Paused by the user | Disconnected | Do nothing until intent changes |
| Wanted | Already connecting | Wait instead of starting a rival attempt |
| Wanted | Authentication needs a person | Prompt, then stop replaying credentials |
पंक्तियों को मामलों की सूची नहीं, नीति की तरह पढ़ें। दूसरी पंक्ति वही है जिसे ज़्यादातर स्क्रिप्ट छोड़ देती हैं, और यही एकमात्र पंक्ति है जो मॉनिटर को ऐसी मशीन से अलग करती है जो सही साबित होने की ज़िद करती है।
देखी गई स्थिति कोई पसंद नहीं है
Apple का Network Extension स्थिति मॉडल connecting, connected, disconnecting, disconnected और recovery स्थितियों की जानकारी देता है। पाँचों कनेक्शन का वर्णन करती हैं। इनमें से कोई यह नहीं कहती «उपयोगकर्ता ने इस प्रोफ़ाइल को रोका रहने के लिए कहा था», क्योंकि यह कनेक्शन की स्थिति ही नहीं है। जो क्लाइंट उस फ़्रेमवर्क पर नहीं बने हैं वे अपने समर्थित नियंत्रण और स्थिति कॉल बताते हैं, और वे अपनी शब्दावली में वही रेखा खींचते हैं।
नतीजा यह है कि डिस्कनेक्टेड स्थिति को कभी अकेले नहीं समझा जा सकता। इसका मतलब कम से कम तीन में से एक बात है: टनल गिर गई, उपयोगकर्ता ने उसे रोका, या सिस्टम प्रयासों के बीच है। सिर्फ़ आपका अपना मंशा-रिकॉर्ड ही इनमें फ़र्क कर सकता है। वह रिकॉर्ड लिखें, अगर उसे रीबूट में भी बचना है तो रीस्टार्ट के बीच उसे रखें, और उसे उसी पल अपडेट करें जब उपयोगकर्ता कार्य करता है, बजाय बाद में लॉग लाइन से अनुमान लगाने के।
scutil --nc list
scutil --nc status "Office VPN"इस प्रोफ़ाइल को शुरू करने की और किसे अनुमति है
आपके हेल्पर द्वारा वादा किया गया ठहराव उतना ही मज़बूत है जितने उसी प्रोफ़ाइल के दूसरे मालिक हैं। On Demand नियम, प्रबंधित कॉन्फ़िगरेशन या दूसरा क्लाइंट सभी कनेक्शन माँग सकते हैं, और आपका हेल्पर टूटा दिखेगा जबकि वह ठीक वैसे ही व्यवहार कर रहा होगा जैसे लिखा है।
प्रोफ़ाइल शुरू कर सकने वाला हर तंत्र खोजें ठहराव का सम्मान करने का वादा करने से पहले, और लिखें कि कौन जीतता है। जब कोई प्रबंधित सेवा जानबूझकर व्यक्तिगत ठहराव विकल्प नहीं देती, तो वह नीति के बारे में प्रशासक का फ़ैसला है, कोई ऐसा अंतराल नहीं जिसे स्क्रिप्ट प्रबंधन से लड़कर भरे।
पुनःप्रयासों को उबाऊ बनाएँ
प्रयासों की संख्या सीमित करें और हर एक को किसी बदली हुई चीज़ के प्रति संवेदनशील बनाएँ: नेटवर्क लौट आया, गेटवे ने जवाब दिया, क्रेडेंशियल प्रॉम्प्ट पूरा हुआ। अनुपलब्ध गेटवे, समाप्त पहचान और अस्वीकृत दूसरे कारक को तीन अलग जवाब चाहिए, और तंग लूप तीनों को एक ही देता है।
देखें कि तेज़ पुनःप्रयास वास्तव में स्क्रीन पर क्या पैदा करता है। उपयोगकर्ता द्वारा बंद किए जाने वाले बार-बार आने वाले डायलॉग एक स्पष्ट विफलता संदेश से बुरे हैं, और वे लोगों को प्रॉम्प्ट पढ़े बिना उन पर क्लिक करना सिखाते हैं।
ठहराव और ट्रैफ़िक नीति अलग-अलग वादे हैं
उपयोगकर्ता द्वारा रोकी गई टनल अक्सर ट्रैफ़िक को जानबूझकर अवरुद्ध छोड़ देती है, जो kill switch शैली की नीति का पूरा मक़सद है। इसका मतलब है कि ठहराव को ठीक एक बात का वादा करना चाहिए: रिकवरी रुक जाती है। उसे चुपचाप यह नहीं बदलना चाहिए कि नेटवर्क क्या अनुमति देता है।
ट्रैफ़िक व्यवहार अलग से तय करें, उसे ठहराव नियंत्रण के पास दस्तावेज़ करें, और टनल रुकी हो, विफल हो या अनुपस्थित हो, उसे एक-सा रखें। वरना उपयोगकर्ता सीख जाता है कि डिस्कनेक्ट दबाने से कुछ अनिश्चित होता है, और अगली सहायता टिकट ऐसे नेटवर्क के बारे में होगी जो «कभी-कभी बिना किसी दिखाई देने वाले कारण के काम करना बंद कर देता है»।