कोई ऐप 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 नहीं है; यह एक टनल का मालिक होना बनाम प्लेटफ़ॉर्म से ट्रैफ़िक रूट करने को कहना है, और सिर्फ़ पहला ही आपका बनाने का है।