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 नाही; ती टनेलची मालकी विरुद्ध प्लॅटफॉर्मला ट्रॅफिक मार्गस्थ करण्यास सांगणे आहे, आणि फक्त पहिलेच तुम्हाला तयार करायचे आहे।