Android पर chroot VPN: सुरंग क्यों काम करती है और ऐप्स इसे क्यों नज़रअंदाज़ करते हैं

आप फ़ोन पर chroot के अंदर Linux वितरण चलाते हैं, उसमें VPN क्लाइंट डालते हैं, और शेल घोषणा करता है कि सुरंग पूरी हो गई। फिर ब्राउज़र पर जाते हैं और ट्रैफ़िक मोबाइल डेटा से बाहर जाता है, जैसे कुछ हुआ ही न हो। या उलटा: फ़ोन का हर ऐप कनेक्टिविटी खो देता है क्योंकि क्लाइंट ने उसी नेमस्पेस में डिफ़ॉल्ट रूट डाल दिया जिसे Android वास्तव में इस्तेमाल करता है। ये दोनों लक्षण एक ही गायब हिस्से से आते हैं और कोई भी VPN क्लाइंट की गलती नहीं है।

शेल कहता है जुड़ा है, ऐप्स सहमत नहीं

पहला नतीजा आम है। chroot से खोली गई यूज़रस्पेस सुरंग अपना हैंडशेक पूरा कर सकती है, आँकड़े छाप सकती है और वही ट्रैफ़िक ढो सकती है जो यही शेल बनाता है, जबकि Android के ऐप्स फ़ोन का डिफ़ॉल्ट नेटवर्क इस्तेमाल करते रहते हैं। कोई उन्हें रोकता नहीं, क्योंकि किसी ने Android को नहीं बताया कि VPN मौजूद है।

दूसरा नतीजा ख़तरनाक है। अगर chroot, Android का नेटवर्क नेमस्पेस साझा करता है, जो डिफ़ॉल्ट है, तो पर्याप्त विशेषाधिकार वाली प्रक्रिया रूट और TUN इंटरफ़ेस जोड़ सकती है जो पूरे फ़ोन पर असर डालते हैं। तब सुरंग हर ऐप के लिए काम करती है, उन ऐप्स सहित जिन्हें आप रूट नहीं करना चाहते थे, और फ़ोन की कनेक्टिविटी अब ऐसे डेमन पर निर्भर है जिसके पास जीवनचक्र प्रबंधन, कनेक्शन संकेतक और हमेशा-चालू नीति नहीं है।

दोनों में से कौन-सा नतीजा मिला, एक ही कमांड से पता चलता है। chroot के अंदर ip route की तुलना बाहर के Android शेल से उसी कमांड से करें। एक जैसा आउटपुट मतलब chroot होस्ट नेमस्पेस में है: उसका हर नेटवर्क बदलाव पूरे फ़ोन पर लागू होता है। अलग आउटपुट मतलब लॉन्चर ने उसके लिए नेमस्पेस बनाया है, और उसकी सुरंग रचना से ही Android के लिए अदृश्य है।

chroot ने क्या बदला और क्या नहीं

chroot सिस्टम कॉल एक काम करता है: पथ-हल के लिए इस्तेमाल होने वाली डायरेक्टरी बदलता है। man पृष्ठ स्पष्ट कहता है कि यह सुरक्षा सीमा नहीं है, और इंटरफ़ेस, रूट या VPN स्थिति के बारे में कुछ नहीं कहता। लोग Linux कंटेनर से जो उम्मीद करते हैं — निजी नेटवर्क स्टैक, फ़िल्टर की गई फ़ाइलसिस्टम, संसाधन सीमाएँ — वह दूसरी व्यवस्थाओं से आता है जिन्हें लॉन्चर ने इस्तेमाल किया हो या नहीं।

इसलिए यह दावा कि chroot VPN को अलग करता है, आम तौर पर गलत सवाल का जवाब देता है। असली सवाल यह है कि प्रक्रिया किस नेमस्पेस में चलती है और किस SELinux डोमेन में सीमित है, और दोनों इस बात के गुण हैं कि उसे कैसे शुरू किया गया, chroot शब्द के नहीं।

TUN को तीन चीज़ें चाहिए, और डिवाइस नोड उनमें से एक है

पारंपरिक यूज़रस्पेस सुरंग को ऐसा TUN डिवाइस चाहिए जिसे वह खोल सके, उस डिवाइस के लिए कर्नेल समर्थन, और इंटरफ़ेस तथा रूट कॉन्फ़िगर करने की अनुमति। ये अलग-अलग शर्तें हैं, और /dev के नीचे पथ नाम बनाना अपने आप इनमें से कोई नहीं पूरा करता:

ls -l /dev/net/tun
ip tuntap add dev tun0 mode tun

Android में कर्नेल में TUN समर्थन आम तौर पर संकलित होता है, क्योंकि प्लेटफ़ॉर्म की अपनी VPN सेवा उसे इस्तेमाल करती है, लेकिन इसका मतलब यह नहीं कि आपकी प्रक्रिया उसे इस्तेमाल कर सकती है। इंटरफ़ेस कॉन्फ़िगर करने के लिए नेटवर्क प्रशासन क्षमता चाहिए, और SELinux तय करता है कि प्रक्रिया डिवाइस नोड तक पहुँच सकती है या नहीं। इनकार बिना स्पष्ट कारण के अनुमति त्रुटि जैसा दिखता है, और जवाब ऑडिट ट्रेल में है:

dmesg | grep avc
logcat -d | grep "avc: denied"

root इसे हल नहीं करता। SELinux uid 0 के रूप में चलने वाली प्रक्रियाओं को भी दूसरों जैसे ही सीमित करता है, इसलिए root शेल से शुरू किया गया chroot भी ऐसे डिवाइस के लिए इनकार पा सकता है जिसे वह देखता है। पुराना इंस्टॉलर चलाने के लिए एन्फ़ोर्समेंट बंद करना पूरे फ़ोन का फ़ैसला है जिसके परिणाम सुरंग से बहुत आगे जाते हैं, और यह बासी बाइनरी का इलाज नहीं है।

Android ऐप्स आपकी सुरंग को क्यों नज़रअंदाज़ करते हैं

Android का समर्थित मॉडल एक VPN ऐप है जो प्लेटफ़ॉर्म की VPN सेवा में पंजीकरण करता है, उपयोगकर्ता से एक बार सहमति माँगता है और अपनी सुरंग के लिए फ़ाइल डिस्क्रिप्टर पाता है। फिर प्लेटफ़ॉर्म ट्रैफ़िक उस डिस्क्रिप्टर में भेजता है और उपयोगकर्ता या प्रशासक द्वारा चुना गया ऐप दायरा लागू करता है, इसलिए वही व्यवस्था प्रति-ऐप, प्रति-प्रोफ़ाइल और हमेशा-चालू तथा VPN बिना ब्लॉक सेटिंग्स के साथ जुड़ सकती है। Android VPN डेवलपमेंट गाइड उस हैंडशेक का वर्णन करती है, और मुख्य बात यह है कि यह पंजीकरण है, रूटिंग की चाल नहीं।

chroot के अंदर का डेमन कभी पंजीकरण नहीं करता। सहमति संवाद नहीं, स्टेटस बार में चाबी का चिह्न नहीं, प्रति-ऐप शामिल या बाहर सूची नहीं, और हमेशा-चालू नीति में भागीदारी नहीं। इसलिए ऐप्स डिफ़ॉल्ट नेटवर्क इस्तेमाल करते रहते हैं, और सुरंग केवल वही ढोती है जो शेल ख़ुद भेजता है।

दूसरी दिशा भी मदद नहीं करती। होस्ट नेमस्पेस में रूट धकेलने से सब कुछ पकड़ में आता है, वह ट्रैफ़िक भी जिसे प्लेटफ़ॉर्म स्थानीय रखना चाहता था, और यह प्रति-ऐप नियंत्रण के बिना, उपयोगकर्ता के देख या रद्द कर पाने की सुविधा के बिना होता है। ऐसी कोई बीच की सेटिंग नहीं है जहाँ chroot डेमन केवल एक ऐप के लिए ट्रैफ़िक रूट करे।

बाइनरी संगतता अलग दीवार है

नेटवर्क पक्ष दिलचस्प होने पर भी निष्पादन-योग्य फ़ाइल की अपनी ज़रूरतें हैं: CPU आर्किटेक्चर, डायनामिक लोडर, C लाइब्रेरी और वे कर्नेल क्षमताएँ जिनकी वह अपेक्षा करती है। Android glibc के बजाय bionic इस्तेमाल करता है, और डेस्कटॉप वितरण के लिए बनी पुरानी बाइनरी को ऐसी लाइब्रेरी चाहिए हो सकती हैं जो डिवाइस पर अब नहीं हैं।

लाइब्रेरी फ़ाइल के नाम को नए संस्करण से जोड़ना ABI संगतता नहीं बनाता, और दस साल पुराने पैकेज से संग्रहित क्रिप्टोग्राफ़ी लाइब्रेरी रखरखाव वाला घटक नहीं है। अगर योजना इस पर टिकी है, तो योजना फ़ोन पर नेटवर्क विशेषाधिकार के साथ बिना रखरखाव वाला कोड चलाना है।

Android संदर्भ में इसे साबित करें और बाद में सफ़ाई करें

जो वास्तव में आपके लिए मायने रखता है उसे उसी पक्ष से जाँचें: विशिष्ट ऐप खोलें, विशिष्ट निजी गंतव्य तक पहुँचें, पुष्टि करें कि किस रिज़ॉल्वर ने जवाब दिया, फिर सुरंग काटें और दस्तावेज़ व्यवहार की पुष्टि करें। chroot के अंदर के टर्मिनल का नतीजा केवल उस टर्मिनल के निष्पादन संदर्भ का प्रमाण है, उससे अधिक नहीं।

अगर प्रयोग के दौरान होस्ट रूट बदले हैं तो उन्हें लौटाएँ और लिखें कि क्या बदला। फिर देखें कि फ़ोन में हमेशा-चालू VPN सेट है या नहीं, क्योंकि नियम छोड़ गया पुराना प्रयोग महीनों बाद प्लेटफ़ॉर्म की ख़राबी जैसा लग सकता है।

असली दूरस्थ पहुँच ज़रूरत के लिए सेवा का समर्थित क्लाइंट या स्वीकृत गेटवे डिज़ाइन इस्तेमाल करें। पूछने लायक सवाल यह नहीं कि root इंस्टॉलर चलाया जा सकता है या नहीं, बल्कि यह कि समर्थित कार्यान्वयन आपके ज़रूरी ऐप्स को आपकी इच्छित सीमा के पार ले जाता है या नहीं, डिवाइस पर बिना मालिक वाले विशेषाधिकार बदलाव छोड़े।