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 प्रोफाइल तोड्छ।

वर्ग बदलेपछि विद्यमान वस्तुका विशेषता सम्पादन गर्नुको सट्टा वस्तु फेरि बनाउनुहोस्, त्यसपछि नयाँ सन्दर्भसँग प्रोटोकल फेरि सङ्ग्रह गर्नुहोस्। विद्यमान वस्तुमा विशेषता परिवर्तनले सधैं कागजातले सङ्केत गरेको व्यवहार दिँदैन, र फेरि बनेको वस्तुले शङ्का हटाउँछ।

रोटेसन भनेको सङ्ग्रहित प्रोफाइल कुहिने ठाउँ हो

कीचेनमा पासवर्ड बदल्दा सङ्ग्रहित प्रोफाइलले केलाई सङ्केत गर्छ त्यो आफैं बदलिँदैन। वस्तु मेट्नु झन् नराम्रो हो: प्रोफाइलले अब नभएको कुराको सन्दर्भ राख्छ, र असफलता प्रमाणीकरणको अस्वीकृतिजस्तो देखिन्छ।

एउटै क्रममा रोटेट गर्नुहोस्। वस्तु अद्यावधिक गर्नुहोस्, नयाँ स्थायी सन्दर्भ क्वेरी गर्नुहोस्, प्रोटोकल फेरि सङ्ग्रह गर्नुहोस्, त्यसपछि एप बन्द राखेर जडान गरी डेमनले अझै समाधान गर्न सक्छ भनी प्रमाणित गर्नुहोस्। प्रयोगकर्ताको पासवर्ड र साझा रहस्य अलग अलग वस्तुमा राख्नुहोस् ताकि प्रत्येक आफ्नै तालिकाअनुसार घुमोस्, र क्वेरी शब्दकोश वा सन्दर्भ आफैं कहिल्यै लग नगर्नुहोस्। ह्यान्डल रहस्य होइन, तर त्यसतर्फको नक्सा हो।