दुई iPhone एपले दुवैले सेटिङमा VPN प्रविष्टि राख्न सक्छन्, दुवैले आफूलाई VPN क्लाइन्ट भन्न सक्छन् र लगभग कुनै कार्यान्वयन साझा गर्दैनन्। Apple यी एकीकरणमध्ये एउटालाई व्यक्तिगत VPN भन्छ, र यही नामले धेरैजसो भ्रम सिर्जना गर्छ। व्यक्तिगत VPN भनेको अन्तर्निहित IPsec वा IKEv2 कार्यान्वयन प्रयोग गर्ने कन्फिगरेसनहरू सिर्जना र व्यवस्थापन गर्ने API हो। प्याकेट-टनेल प्रदायक अर्को मोडेल हो: एपले आफ्नै प्रोटोकलको क्लाइन्ट पक्ष लागू गर्ने एक्सटेन्सन दिन्छ। त्यसपछि मानिसहरूले यो लेबलबाट जे अनुमान गर्छन्, साइफरदेखि स्वामित्व र फोन व्यवस्थापन गर्नुपर्छ कि भन्नेसम्म, त्यो अनुमान हो, भनाइ होइन।

टनेल कसले लागू गर्छ

यो विभाजनले केही बिग्रँदा कसले जिम्मेवारी लिन्छ भन्ने निर्धारण गर्छ। अन्तर्निहित IPsec वा IKEv2 सँग, टनेलको स्टेट मेसिन iOS को हो र एपले कन्फिगरेसन र बटनको स्वामित्व राख्छ। प्रदायकसँग, एपले दुवैको स्वामित्व राख्छ, त्यसैले प्रोटोकल बग अपरेटिङ सिस्टम अपडेटको सट्टा एप अपडेट बन्छ।

कसले प्रोटोकल लागू गर्छ भनेर सोध्नुभयो भने तुलना छोटो हुन्छ।

IntegrationApple interfaceProtocol implementation
Personal VPNNEVPNManager with a Personal VPN configurationThe system IPsec or IKEv2 client
Packet tunnelNETunnelProviderManager plus the provider extensionWhatever the extension implements

व्यक्तिगत VPN कागजात ले एपले पहिलो पटक कन्फिगरेसन सुरक्षित गर्दा हुने स्पष्ट प्रयोगकर्ता अनुमति अनुरोधको पनि उल्लेख गर्छ, जुन सामान्यतया VPN एपको होइन, त्यो मोडेलको हो।

लेबलबारे छोड्न लायक दुई दाबी

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

त्यसैले एपको उपस्थिति वायर प्रोटोकलबारे प्रमाण होइन। WireGuard वा OpenVPN बोल्ने तेस्रो-पक्ष क्लाइन्ट रचनागत रूपमै प्रदायक एप हो, किनकि iOS ले ती प्रोटोकलहरू मूल रूपमा लागू गर्दैन।

किन उद्यम शब्दावली भ्रमित गर्छ

Apple को कागजातले NETunnelProviderManager कन्फिगरेसनहरूलाई सामान्य उद्यम VPN कन्फिगरेसनका रूपमा वर्गीकृत गर्छ। त्यो शब्दावली API कोटी हो, र यसले मानिसहरूलाई दुई विपरीत त्रुटितर्फ धकेल्छ: उपभोक्ता एपले प्रदायक मोडेल प्रयोग गर्न सक्दैन भन्ने मान्नु, र त्यसका लागि फोन निगरानीमा हुनुपर्छ भन्ने मान्नु। दुवैमध्ये केही पनि पछ्याउँदैन। उपभोक्ता एपहरूले नियमित रूपमा प्रदायक दिन्छन्, र निगरानी कसले नीति लागू गर्न सक्छ भन्ने छुट्टै प्रश्न हो।

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

स्क्रिनसटको सट्टा प्रमाण जाँच्नुहोस्

स्क्रिनसट उपलब्ध सबैभन्दा नराम्रो प्रमाण हो, किनकि सेटिङको समूहीकरण संस्करणहरूबीच बदलिन्छ। व्यवस्थापित प्रोफाइलले आफ्नै पेलोड प्रकार भन्छ: अन्तर्निहित प्रोफाइलले IKEv2 वा IPsec जस्ता VPN प्रकार घोषणा गर्छ, जबकि प्रदायक प्रोफाइलले प्रदायकको बन्डल पहिचानकर्ता भन्ने उपप्रकार बोक्छ। यो तपाईंको अगाडिको उपकरणमा जाँच्न सकिन्छ, र यसले अर्को पुनःडिजाइन पनि सहन्छ।

एपकै कुरा गर्दा, प्रयोग गरिएको क्लासले त्यही प्रश्नको उत्तर अर्को पक्षबाट दिन्छ: व्यक्तिगत VPN API बाट कन्फिगरेसन वस्तुहरू, वा प्रदायक म्यानेजर र त्यसको एक्सटेन्सन।

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

रेकर्डलाई जडानसँगै राख्नुहोस्

प्रमाणीकरण र स्रोत नीतिलाई एपसँग होइन, जडान रेकर्डसँग जोड्नुहोस्, ताकि पुनःस्थापनले अनुमति मोडेल सँगै नलैजाओस्। त्यो रेकर्ड नै टनेल उठेपछि र अरू केही नचलेपछि सहयोग इन्जिनियरलाई चाहिने कुरा हो।

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

सम्बन्धित लेखहरू