टनेल चलिरहँदा पनि तपाईंको iOS VPN एपले डिस्कनेक्ट देखाउने किन

तपाईंको एपले डिस्कनेक्ट भन्छ, मेनु बारले कनेक्ट भन्छ, र ट्राफिक स्पष्ट रूपमा बगिरहेको छ। त्यो खाडल पुनः प्रयासले सुधार्न सकिने दौड अवस्था होइन: एप र टनेल छुट्टाछुट्टै प्रक्रिया हुन्, र तपाईंको कोडले पढ्ने वस्तु सिस्टमले भण्डारण गर्ने कन्फिगरेसनको क्यास गरिएको दृश्य हो। Apple को Personal VPN सतह नियन्त्रण API हो, डेटा मार्ग होइन, र यसको अधिकांश अनौठो व्यवहार यही एउटा तथ्यबाट आउँछ। प्रत्येक कलमा वास्तवमा के हुन्छ, यहाँ छ।

म्यानेजर वस्तु क्यास गरिएको दृश्य हो, टनेल होइन

NETunnelProviderManager सिस्टमको स्वामित्वमा रहेको प्राथमिकता भण्डारबाट भरिन्छ, त्यसैले loadFromPreferences पूरा नभएसम्म यसका गुणहरूको कुनै अर्थ हुँदैन। त्योभन्दा अघि connection.status पढ्नुभयो भने तपाईंले पूर्वनिर्धारित मान पाउनुहुन्छ, र त्यसैले पुनः सुरु गरेपछिको पहिलो स्थिति अद्यावधिकले टनेल चलिरहँदा पनि डिस्कनेक्ट भनी रिपोर्ट गर्छ। पहिले लोड गर्नुहोस्, त्यसपछि त्यही पूर्णता ह्यान्डलरबाट स्थिति र प्रोटोकल कन्फिगरेसन पढ्नुहोस्। पछिका परिवर्तनहरू पोलिङको सट्टा NEVPNStatusDidChange मार्फत हेर्नुहोस्, र सूचना On Demand ले सुरु गरेका जडानहरूका लागि पनि आउँछ भन्ने कुरा विचार गर्नुहोस्, जहाँ केही फर्काउने कुनै एप कल नै हुँदैन। प्रोटोकल सेटिङमा पनि यही लागू हुन्छ: तिनीहरू लोड गरिएको कन्फिगरेसनबाट पढिन्छन्, एपले पठाएकोबाट होइन।

टनेल आफैं Network Extension प्रदायक प्रक्रियामा बस्छ, त्यसैले एपले जडान नगुमाई आफ्नो अवस्था गुमाउन सक्छ। इन्टरफेसले देखाउने सबै कुरा म्यानेजरबाट पुनः बनाउनुपर्छ, अघिल्लो सत्रबाट सम्झनु हुँदैन।

सुरु गर्ने क्रम: सुरक्षित गर्नुहोस्, लोड गर्नुहोस्, त्यसपछि सुरु गर्नुहोस्

प्रदायक-आधारित जडानलाई क्रममा तीन चरण चाहिन्छ। प्रदायक कन्फिगरेसन लेखेर saveToPreferences कल गर्नुहोस्, सुरक्षित कन्फिगरेसन तपाईंको हातमा भएको नै होस् भनेर म्यानेजर लोड गर्नुहोस्, त्यसपछि NETunnelProviderSession.startVPNTunnel() मार्फत सुरु गर्नुहोस्। सुरक्षित गर्न छोड्नुभयो भने सुरु गर्नेसँग सुरु गर्न केही छैन; सुरक्षित गर्नुअघि लोड गर्नुभयो भने म्यानेजरले अझै पुरानो कन्फिगरेसन देखाउँछ।

startVPNTunnel ले फर्काउने बुलियनले अनुरोध स्वीकारिएको मात्र भन्छ। प्रदायक स्तरका असफलताहरू पछि डिस्कनेक्ट स्थितिमा परिवर्तनको रूपमा आउँछन्, जुन तपाईंले NEVPNStatusDidChange सूचनामार्फत हेर्नुहुन्छ, र सूचना ह्यान्डलरले loadFromPreferences पछि connection.status फेरि पढ्नुपर्छ किनकि क्यास गरिएको मान अझै पुरानो हुन सक्छ। अनुरोध स्तरका असफलताहरू कलको अपवाद फाल्ने रूपबाट तुरुन्तै फर्किन्छन्, वा startVPNTunnelAndReturnError: को त्रुटि आउट-प्यारामिटरमार्फत। फर्काइएको मानलाई नतिजा मान्ने कोडले कहिल्यै स्थापित नभएको जडानको रिपोर्ट गर्छ। अर्को शान्त असफलता भनेको स्थापित एक्सटेन्सनसँग नमिल्ने प्रदायक बन्डल पहिचानकर्ता हो: अनुरोध अस्वीकार गरिन्छ, र सन्देशमा केही पनि पहिचानकर्तातर्फ संकेत गर्दैन। पहिचानकर्ता गलत भएमा अनुरोध सामान्यतया तुरुन्तै असफल हुन्छ, प्रदायकको एक लाइन लग पनि आउनुअघि।

सुरु गरेपछि प्राथमिकताहरू पुनः लोड गर्नु नै स्थिति स्क्रिनहरूलाई सही बनाउँछ। सिस्टमले कन्फिगरेसन बदल्दा म्यानेजरले तपाईंतर्फ नयाँ कन्फिगरेसन धकेल्दैन।

विश्वास सामग्री प्रोफाइलमार्फत आउँछ, एप कोडबाट कहिल्यै आउँदैन

iOS विश्वास भण्डारमा मूल प्रमाणपत्र थप्ने कुनै समर्थित तरिका एपसँग छैन, त्यसैले Personal VPN कन्फिगरेसनले यन्त्रले पहिले नै विश्वास गर्ने सामग्रीलाई मात्र सन्दर्भ गर्न सक्छ: स्थापित प्रोफाइल, यन्त्र व्यवस्थापन वा सिस्टमले अन्य कारणले विश्वास गर्ने CA ले स्थापित गरेको शृंखला। पहिलो सुरुवातमा आफ्नै CA बनाएर सिस्टमले त्यसलाई मान्ने अपेक्षा गर्ने एप प्रदायकभित्रको प्रमाणीकरणमा असफल हुन्छ, जहाँ एपको इन्टरफेसले कारण देख्न सक्दैन।

त्यो सीमालाई जस्तो छ त्यस्तै डिजाइन बाधाका रूपमा लिनुहोस् र भर्ना प्रोफाइलसँगै विश्वास एङ्कर पठाउनुहोस्। VPN प्रमाणीकरणलाई विश्वास निर्णयबाट अलग राख्नुहोस्, किनकि तिनीहरू फरक ठाउँमा असफल हुन्छन् र फरक मानिसहरूले डिबग गर्छन्।

काउन्टरहरू इन्टरफेसबाट आउँछन्, VPN API बाट होइन

म्यानेजरले स्थिति र कन्फिगरेसन देखाउँछ, र प्रत्येक टनेलको बाइट गणना गर्ने केही छैन। तपाईंलाई प्रयोगका अङ्क चाहिए getifaddrs() कल गर्नुहोस् र सम्बन्धित इन्टरफेसका लागि if_data पढ्नुहोस्: Wi-Fi का लागि en0, सेलुलरका लागि pdp_ip इन्टरफेसहरू, र टनेलका लागि नै utun यन्त्र। utun काउन्टरहरूले आन्तरिक ट्राफिक वर्णन गर्छन् र प्रोटोकल ओभरहेड समावेश गर्छन्।

यी अङ्क अनुमान हुन्, प्रति एप लेखा होइन, र इन्टरफेस पुनः बनाइँदा तिनीहरू रिसेट हुन्छन्। इन्टरफेसमा तिनीहरूलाई त्यसै गरी लेबल गर्नुहोस्, नत्र कसैले तिनलाई ग्राहकलाई बिल गर्न प्रयोग गर्नेछ। तपाईंलाई प्रति एप अङ्क चाहिए पूर्ण रूपमा फरक संयन्त्र चाहिन्छ, यी फिल्डहरूको राम्रो पठन होइन।

सफाइ stopVPNTunnel मा छ, समाप्तिमा होइन

applicationWillTerminate ले सिस्टमले प्रक्रिया मार्न सक्नुअघि तपाईंलाई केही सेकेन्ड दिन्छ, जुन जडान भत्काउन भरपर्दो ठाउँ होइन। रोक्ने कार्य stopVPNTunnel() मा पठाउनुहोस् वा प्रदायकको रोक्ने कलब्याकमा व्यवस्थापन गर्नुहोस्, र तपाईंले सुरु गर्नुभएको म्यानेजर वा कन्फिगरेसन पहिचानकर्ता राख्नुहोस् ताकि रोकाइले यन्त्रका हरेक कन्फिगरेसनलाई होइन, त्यही जडानलाई लक्षित गर्छ।

त्यो पहिचानकर्ता यो जुन प्रोफाइलको हो त्यसको छेउमा भण्डारण गर्नुहोस्, किनकि म्यानेजर वस्तुले प्रयोगकर्ताले कुन कन्फिगरेसन छान्यो भनी अभिलेख गर्दैन। र सम्झनुहोस्, On Demand ले उठाएको जडानको पछाडि कुनै एप कल नै हुँदैन, त्यसैले स्थिति स्क्रिनले केही कोर्नुअघि अझै प्राथमिकताहरू लोड गर्नुपर्छ।