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 शैलीच्या धोरणाचा संपूर्ण उद्देश आहे। याचा अर्थ थांबवण्याने नक्की एकच गोष्ट वचन द्यावे: रिकव्हरी थांबते। नेटवर्क काय परवानगी देते ते त्याने गुपचूप बदलू नये।
रहदारीचे वर्तन वेगळे ठरवा, ते थांबवणे नियंत्रणाजवळ दस्तऐवजीकृत करा, आणि टनेल थांबवलेली, अयशस्वी किंवा अनुपस्थित असली तरी ते सुसंगत ठेवा। नाहीतर वापरकर्ता शिकतो की डिस्कनेक्ट दाबल्याने काहीतरी अनपेक्षित घडते, आणि पुढील सहाय्य तिकीट «कधीकधी कोणत्याही दिसणाऱ्या कारणाशिवाय काम करणे थांबवणाऱ्या» नेटवर्कबद्दल असेल।