Android वा iOS मा एपले सुरक्षित VPN प्रोफाइल किन सक्रिय गर्न सक्दैन

दुई धेरै फरक काम प्रोग्रामेटिक VPN नाममुनि राखिन्छन्, र तीमध्ये एउटा मात्र दुवै मोबाइल प्लेटफर्ममा साधारण एपका लागि उपलब्ध छ। पहिलो प्रयोगकर्ताले पहिल्यै सुरक्षित गरेको प्रोफाइल सक्रिय गर्नु हो; दोस्रो आफ्नै प्रक्रियाभित्र सुरुङ बनाउनु हो। Android दोस्रो VpnService मार्फत दिन्छ र iOS दोस्रो Network Extension अधिकारमार्फत दिन्छ, जबकि पहिलो प्रणाली, यन्त्रको मालिक वा MDM सर्भरसँग रहन्छ। तपाईंलाई वास्तवमा कुन चाहिन्छ भनी पत्ता लगाउनुले सामान्यतया परियोजना सानो बनाउँछ।

एउटै नाम भएका दुई काम

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

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

Android: सहमतिको ढोका, र कुनै प्रोफाइल API छैन

VpnService Android 4.0 देखि छ र एपलाई tun इन्टरफेस बनाउन दिन्छ, त्यसपछि प्याकेट पढ्छ र लेख्छ। सेवा BIND_VPN_SERVICE सँग घोषणा गर्नुपर्छ, र VpnService.prepare() प्रयोगकर्तासँग अनुमति माग्ने प्रणाली संवाद उत्पन्न गर्छ। प्लेटफर्मको नमुना ToyVpn अभिप्रेत आकारको सबैभन्दा स्पष्ट अभिव्यक्ति हो: तपाईंको कोड इन्टरफेस र त्यसबाट बहने सबैको मालिक हो।

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

व्यवस्थित मार्ग छुट्टै छ। यन्त्र मालिक वा प्रोफाइल मालिकले यन्त्र नीति API मार्फत सधैं सक्रिय VPN प्याकेज तोक्न सक्छ, र उद्यम उपकरणले प्रयोगकर्ताले पछि स्वीकृत गर्ने प्रोफाइल पठाउन सक्छ। यो यन्त्र-व्यवस्थापन अधिकार हो, स्थापनाको समयमा एपले माग्ने अनुमति होइन। यदि तपाईंको ग्राहक संस्था हो भने, योजना बनाउनुपर्ने मार्ग यही हो; यदि ग्राहक पसलबाट स्थापना गर्ने व्यक्ति हो भने, यो बिल्कुल उपलब्ध छैन।

iOS: अधिकार नै सीमा हो

iOS ले त्यही काम फरक तरिकाले विभाजन गर्छ। VPN क्लाइन्टले Network Extension ढाँचाअन्तर्गत प्याकेट सुरुङ प्रदायक वा एप प्रोक्सी लागू गर्छ, र सम्बन्धित अधिकार विकासकर्ता खातालाई दिनुपर्छ। सरल अवस्थाका लागि NEVPNManager मार्फत व्यक्तिगत VPN कन्फिगरेसन छ, र यो अझै त्यही अनुमति मोडेलभित्र चल्छ। Apple ले सम्पूर्ण सतह Network Extension सन्दर्भमा अभिलेख गर्छ, कामको दायरा तोक्नुअघि त्यो पढ्न लायक छ।

VPN सेटिङ स्क्रिन खोल्न, प्रयोगकर्ताको सुरक्षित कन्फिगरेसन पढ्न वा तीमध्ये एउटा सुरु गर्न कुनै समर्थित तरिका छैन। क्लाइन्टले गर्न सक्ने भनेको स्थापनाका लागि कन्फिगरेसन प्रोफाइल पठाउनु, त्यसपछि बनेको सुरुङ साधारण नेटवर्किङ कलमार्फत प्रयोग गर्नु हो। प्रति-एप सुरुङ MDM सर्भरले मागअनुसार नियमद्वारा तोक्छ, रनटाइममा एपले छान्दैन।

ठूलो विक्रेताको VPN क्लाइन्ट तपाईंको खाताले त्यही पठाउन सक्छ भन्ने प्रमाण होइन। ती अधिकार प्रति विकासकर्ता खाता मागिन्छन् र समीक्षा गरिन्छन्, त्यसैले समयतालिकाको जोखिम Apple मा छ, तपाईंको स्प्रिन्ट योजनामा होइन।

डेस्कटप अझ टाढा पुग्छ, तर स्वामित्व बदलिँदैन

Windows अनुमतिप्रद अवस्था हो। Add-VpnConnection उन्नत PowerShell सत्रबाट फोनबुक प्रविष्टि बनाउँछ, र rasdial स्क्रिप्टबाट त्यसलाई जोड्छ वा टुटाउँछ। एपले विक्रेताको क्लाइन्टलाई यसको अभिलेखित कमाण्ड लाइनमार्फत पनि चलाउन सक्छ। प्रोफाइल बनाउनु अझै प्रशासनिक कार्य हो, किनकि प्रविष्टि सम्पूर्ण मेसिनको भण्डारमा बस्छ।

macOS अन्य उपकरणसँग त्यसै गरी व्यवहार गर्छ। scutil --nc start र stop पहिल्यै अस्तित्वमा रहेका सेवाहरूमा काम गर्छन्, जबकि एउटा बनाउनु प्रणाली प्रशासनको काम हो। ल्यापटपमा प्रक्रियाको स्वामित्व लिनुले तपाईंलाई कन्फिगरेसनको मालिक बनाउँदैन।

यसको सट्टा के बनाउने

यदि वास्तविक आवश्यकता तपाईंको एप आन्तरिक API सम्म पुग्नु हो भने, प्रयोगकर्ताले पहिल्यै चलाइरहेको सुरुङ पर्याप्त छ। साधारण HTTPS अनुरोध पठाउनुहोस्, बाटो प्रणालीलाई छान्न दिनुहोस्, र सुरुङ नियन्त्रण गर्ने प्रयास रोक्नुहोस्। यदि आवश्यकता तपाईंको एपको ट्राफिक मात्र सुरुङ प्रयोग गर्नु हो भने, व्यवस्थापन च्यानलमार्फत प्रति-एप VPN माग्नुहोस्, वा एपभित्र त्यसबिना पुग्न सकिने सेवाविरुद्ध TLS अन्त्य गर्नुहोस्।

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