iOS VPN प्रोफाइल: पासवर्ड नाही, passwordReference

तुम्ही प्रोफाइल इन्स्टॉल करता, टनेल वर येते, आणि सर्व काही पूर्ण झाल्यासारखे वाटते. मग फोन रीबूट होतो, on-demand समोर कोणतेही ॲप नसताना कनेक्शन जागवते, आणि टनेल सुरू होण्यास नकार देते. प्रोफाइल अजूनही तिथे आहे आणि पासवर्ड अजूनही बरोबर आहे, म्हणूनच हे अपयश लोकांना चुकीच्या ठिकाणी शोधायला पाठवते. Network Extension तुमचे रहस्य प्रोफाइलमधून वाचू शकत नाही: त्याला कीचेनचा असा संदर्भ हवा जो तो स्वतः सोडवू शकेल.

खालील मार्गदर्शन संदर्भ तयार करणाऱ्या क्वेरीपासून तो तपासणाऱ्या रीबूटपर्यंत, या सुपूर्दगीतून एका कनेक्शन प्रयत्नाचा मागोवा घेते.

प्रोफाइल हँडल ठेवते, रहस्य नाही

NEVPNProtocol काही कारणास्तव passwordReference आणि sharedSecretReference उघड करते. जेव्हा डेमन टनेल सुरू करतो तेव्हा तो तुमच्या प्रक्रियेत चालत नसेल, त्यामुळे तो तुमचा कोड बोलावून पासवर्ड मागू शकत नाही. तो कीचेनचा कायमचा संदर्भ वाचतो, तो स्वतःच्या संदर्भात सोडवतो आणि वस्तू स्वतः आणतो.

तुम्ही तो संदर्भ कीचेनला विचारून तयार करता, जी डेटा मागण्यापेक्षा वेगळी विनंती आहे:

let query: [String: Any] = [
  kSecClass as String: kSecClassGenericPassword,
  kSecAttrService as String: "vpn-credentials",
  kSecAttrAccount as String: "user",
  kSecReturnPersistentRef as String: true,
  kSecMatchLimit as String: kSecMatchLimitOne
]

परत मिळालेली वस्तू प्रोटोकॉलला द्या, वस्तूचा डेटा नाही. प्रत्यक्षात प्रोफाइल नोंदवते की रहस्य कुठे राहते, म्हणूनच कॉन्फिगरेशनचा बॅकअप पासवर्ड plist मध्ये गुपचूप नकलत नाही.

API -50 का उत्तर देते

errSecParam म्हणजे विनंती किंवा मूल्य त्या क्रियेसाठी चुकीच्या स्वरूपात होते, आणि संदर्भ व डेटाच्या विनंत्या गोंधळल्या की ही त्रुटी सर्वाधिक दिसते. स्वीकारणारा कोड संदर्भाची अपेक्षा करत असताना डेटा मागणे, passwordReference मध्ये कच्चे बाइट ठेवणे, किंवा ॲप वापरू शकत नाही अशा प्रवेश गटासह क्वेरी करणे, हे सर्व ती निर्माण करतात.

रॅपर लाइब्ररी यास आमंत्रण देतात. बाइट परत देणारा सहायक संदर्भ परत देणाऱ्याशी बदलता येत नाही, त्यामुळे दुरुस्ती सहसा दुसरा पासवर्ड नसून दुसरी क्वेरी असते.

तेच विसंगती अशा प्रोफाइलचे स्पष्टीकरण देते जे तक्रार न करता जतन होते आणि नंतर कनेक्ट होत नाही: जतन झालेले ब्लॉब आहे, हँडल नाही, आणि डेमनकडे सोडवायला काही नाही.

चांगले जतन होते, कनेक्ट होताना अयशस्वी

जतन तुमच्या ॲपचा संदर्भ वापरते. कनेक्ट होणे डेमनचा, आणि दोघांचा प्रवेश सारखा नाही. त्यामुळे प्रोफाइल सिम्युलेटरमधील सर्व चाचण्या उत्तीर्ण होऊन पहिल्या on-demand सुरुवातीला अयशस्वी होऊ शकते.

रीबूटच्या लक्षणाचाही आकार हाच आहे: ॲप उघडे असेपर्यंत काम करते आणि सिस्टम स्वतः टनेल सुरू करते तेव्हा मरते.

पाठवण्यापूर्वी बॅकग्राउंड मार्ग जाणूनबुजून तपासा. ॲप बंद असताना on-demand कनेक्शन घडवा, मग ॲपचा लॉग नाही तर डिव्हाइस कन्सोल वाचा, कारण अपयश संदर्भ सोडवण्याचा प्रयत्न करणाऱ्या प्रक्रियेने नोंदवले जाते. कन्सोलने दाखवले की डेमन वस्तू नाकारत आहे, तर संदर्भ ठीक आहे आणि समस्या वस्तूच्या प्रवेशयोग्यतेत आहे.

रीबूट चालेल की नाही हे प्रवेशयोग्यता ठरवते

टनेल सुरू करणाऱ्या कोणत्याही सिस्टम प्रक्रियेसाठी वस्तू वाचनीय असावी, आणि ॲप समोर असतानाच्या प्रेक्षकांपेक्षा हा मोठा वर्ग आहे. ती मर्यादा तुमच्यासाठी प्रवेशयोग्यता गुणधर्म निवडते. पहिल्या अनलॉकपर्यंत संरक्षित वस्तू डिव्हाइस एकदा अनलॉक झाल्यानंतर बॅकग्राउंड सुरुवातीसाठी उपलब्ध असते; डिव्हाइस आत्ताच अनलॉक असावे अशी मागणी करणारी वस्तू उपलब्ध नसते.

अधिक कडक वर्ग निवडणे मोहक आहे आणि तेच लॉक केलेल्या फोनवर on-demand प्रोफाइल तोडते.

वर्ग बदलल्यानंतर विद्यमान वस्तूचे गुणधर्म संपादित करण्याऐवजी वस्तू पुन्हा तयार करा, मग नव्या संदर्भासह प्रोटोकॉल पुन्हा जतन करा. विद्यमान वस्तूवरील गुणधर्म बदल नेहमी दस्तऐवज सूचित करतो ते वर्तन देत नाहीत, आणि पुन्हा बांधलेली वस्तू शंका दूर करते.

रोटेशन म्हणजे जतन केलेली प्रोफाइल सडतात ती जागा

कीचेनमधील पासवर्ड बदलल्याने जतन केलेले प्रोफाइल कशाकडे निर्देश करते ते आपोआप बदलत नाही. वस्तू हटवणे अधिक वाईट: प्रोफाइल आता नसलेल्या गोष्टीचा संदर्भ ठेवते, आणि अपयश प्रमाणीकरणाच्या नकारासारखे दिसते.

एका क्रमाने रोटेट करा. वस्तू अद्ययावत करा, नवीन कायमचा संदर्भ क्वेरी करा, प्रोटोकॉल पुन्हा जतन करा, मग ॲप बंद असताना कनेक्ट होऊन डेमन अजूनही तो सोडवू शकतो हे सिद्ध करा. वापरकर्त्याचा पासवर्ड आणि सामायिक रहस्य वेगळ्या वस्तूंमध्ये ठेवा जेणेकरून प्रत्येक स्वतःच्या वेळापत्रकाने फिरेल, आणि क्वेरी शब्दकोश किंवा संदर्भ स्वतः कधीही लॉग करू नका. हँडल रहस्य नाही, पण ते त्याकडे जाणारा नकाशा आहे.