प्राथमिकताएँ लोड होने तक NEVPNManager की स्थिति अमान्य है

ऐप को फिर से शुरू करें, मैनेजर से कनेक्शन की स्थिति पूछें, और वह डिस्कनेक्टेड बताता है जबकि सिस्टम मेन्यू स्पष्ट रूप से एक सक्रिय टनल दिखा रहा है। या कोई सेव कॉल ऐसी त्रुटि लौटाता है जो कुछ भी स्पष्ट नहीं करती, या किसी साझा रहस्य को सौंपे जाने के कुछ सेकंड बाद ही उसे अनुपस्थित घोषित कर दिया जाता है। तीन लक्षण, एक तंत्र: मैनेजर सिस्टम स्टोर पर एक दृश्य है, और दृश्य तब तक खाली पढ़ा जाता है जब तक कोई उसे लोड न करे।

इनमें से कुछ भी डीबग करने से पहले तय करें कि आपको कौन सा API इस्तेमाल करना चाहिए। सिस्टम का IPsec या IKEv2 टनल अंतर्निहित मैनेजर के लिए उपयुक्त है; जिस प्रोटोकॉल को सिस्टम लागू नहीं करता उसके लिए अपने स्वयं के पैकेट हैंडलिंग वाला टनल प्रदाता चाहिए, और फ़ील्ड का कोई भी संयोजन इसे नहीं बदलता।

मैनेजर स्टोर पर एक दृश्य है

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

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

स्थिति में बदलाव तभी आते हैं जब आप देख रहे हों

प्राथमिकताएँ लोड होने के बाद स्थिति डिस्कनेक्टेड, कनेक्ट हो रहा है, कनेक्टेड, पुनः पुष्टि और डिस्कनेक्ट हो रहा है से गुजरती है। इंटरफ़ेस को एक पढ़ने से आरंभ करें, फिर टाइमर पर पोलिंग करने के बजाय बदलाव की सूचना सुनें। पोलिंग अग्रभूमि में काम करती है और पृष्ठभूमि में झूठ बोलती है, और इसी तरह ऐप्स में ऐसा स्पिनर रह जाता है जो कभी हल नहीं होता।

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

रहस्य संदर्भ हैं, स्ट्रिंग नहीं

साझा रहस्य अनुपस्थित होने की सूचना का अर्थ शायद ही कभी यह होता है कि किसी ने इसे सौंपा नहीं। प्रोटोकॉल ऑब्जेक्ट एक संदर्भ चाहता है: एक उपयोगकर्ता पासवर्ड के लिए और एक IPsec पूर्व-साझा कुंजी के लिए। nil देना, या गलत कीचेन प्रविष्टि से प्राप्त संदर्भ देना, खाली स्लॉट जैसी ही शिकायत देता है। त्रुटि लक्षण का नाम लेती है और कारण छिपाती है, इसीलिए लोग एक ही रहस्य कई बार दोबारा दर्ज करते हैं।

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

एक्सटेंशन का अपना कीचेन दृश्य है

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

यदि प्रदाता अपने प्रदाता कॉन्फ़िगरेशन ऑब्जेक्ट के ज़रिए कॉन्फ़िगर होता है, तो रहस्य को ऐप के भीतर भी न रखें। दो प्रतियाँ अलग-अलग हो जाती हैं, और यह अंतर दोहराव के बजाय खराब क्रेडेंशियल के रूप में दिखता है। दूसरी स्थिति बताने वाला विजेट या दूसरी प्रक्रिया का भी यही स्पष्टीकरण है: हर एक को समूह चाहिए, और हर एक को पढ़ने से पहले प्राथमिकताएँ लोड करनी होंगी।

API को प्रोटोकॉल से मिलाएँ

अंतर्निहित मैनेजर IPsec और IKEv2 प्रोटोकॉल ऑब्जेक्ट रखता है। अतिरिक्त फ़ील्ड से यह सामान्य SSL VPN क्लाइंट नहीं बन जाता, और बेमेल प्रोफ़ाइल बिना त्रुटि सहेजी जा सकती है और फिर भी कभी कनेक्ट नहीं होगी। स्थिति जाँचने से पहले तय करें कि आप किस श्रेणी में हैं, क्योंकि स्थिति बग और असमर्थित प्रोटोकॉल बाहर से एक जैसे दिखते हैं।

अगली बार फिर से शुरू करने के लिए चेकलिस्ट छोटी है: प्राथमिकताएँ लोड करें, स्थिति पढ़ें, बदलाव सदस्यताएँ अग्रभूमि में रखें, साझा समूह से संदर्भ फिर से बनाएँ, और पुष्टि करें कि प्रोटोकॉल ऑब्जेक्ट आपके लागू किए API से मेल खाता है। यह सूची चलाने में एक मिनट लगता है; इस पर अनुमान लगाने में पूरी दोपहर।