Android chroot VPN: बोगदा का चालतो पण ॲप्स त्याकडे दुर्लक्ष करतात
chroot फक्त पथ-शोध बदलतो, कर्नल, नेटवर्क नेमस्पेस किंवा Android ची VPN नोंदणी नाही. यातून दोन परिणाम येतात आणि दोन्ही लोकांना आश्चर्यचकित करतात.
तुम्ही फोनवर chroot खाली चालणारी Linux वितरण आणता, त्यात VPN क्लायंट बसवता, आणि शेल बोगदा पूर्ण झाला असे जाहीर करते. मग तुम्ही ब्राउझरवर जाता आणि रहदारी काहीच घडलं नसल्यासारखी मोबाइल डेटावरून बाहेर जाते. किंवा उलट: क्लायंटने Android प्रत्यक्षात वापरत असलेल्या नेमस्पेसमध्ये डीफॉल्ट मार्ग बसवल्यामुळे फोनवरील प्रत्येक ॲपची कनेक्टिव्हिटी जाते. ही दोन्ही लक्षणे एकाच गहाळ भागातून येतात, आणि दोन्हीपैकी एकही VPN क्लायंटमधील बग नाही.
शेल म्हणते जोडले आहे, ॲप्स सहमत नाहीत
पहिला परिणाम सामान्य आहे. chroot मधून उघडलेला वापरकर्ता-स्पेस बोगदा त्याचा हँडशेक पूर्ण करू शकतो, आकडेवारी छापू शकतो आणि तोच शेल निर्माण करणारी रहदारी वाहून नेऊ शकतो, तर Android ची ॲप्स फोनचे डीफॉल्ट नेटवर्क वापरत राहतात. त्यांना काहीही अडवत नाही, कारण VPN आहे हे Android ला काहीही सांगितले नाही.
दुसरा परिणाम धोकादायक आहे. chroot ने Android चा नेटवर्क नेमस्पेस सामायिक केला, जे डीफॉल्टने करते, तर पुरेशा विशेषाधिकार असलेला प्रक्रिया संपूर्ण फोनवर परिणाम करणारे मार्ग आणि TUN इंटरफेस जोडू शकतो. मग बोगदा प्रत्येक ॲपसाठी काम करतो, तुम्ही मार्गस्थ करण्याचा विचार न केलेल्या ॲप्ससह, आणि फोनची कनेक्टिव्हिटी आता जीवनचक्र व्यवस्थापन, कनेक्शन निर्देशक आणि always-on धोरण नसलेल्या डीमॉनवर अवलंबून असते.
तुम्हाला यापैकी कोणते मिळाले हे एका आदेशात सांगता येते. chroot मधील ip route ची त्याबाहेरील Android शेलमधील त्याच आदेशाशी तुलना करा. सारखे आउटपुट म्हणजे chroot होस्ट नेमस्पेसमध्ये आहे: ते करते ते कोणतेही नेटवर्किंग बदल संपूर्ण फोनला लागू होतात. वेगळे आउटपुट म्हणजे लाँचरने त्यासाठी नेमस्पेस तयार केला, आणि त्याचा बोगदा Android ला रचनेनेच अदृश्य आहे.
chroot ने काय बदलले आणि काय बदलले नाही
| Object | Effect of a chroot |
|---|---|
| Pathname resolution | Changed: lookups start at the new root |
| Kernel and drivers | Unchanged: the phone's kernel, its TUN driver, its limits |
| Network namespace | Unchanged unless the launcher creates one |
| Android VPN registration | Unchanged: no app consented, no VPN is selected |
chroot सिस्टम कॉल एकच काम करतो: पथ-नाव शोधासाठी वापरलेली डिरेक्टरी बदलतो. ती सुरक्षा सीमा नाही असे मॅन पेज स्पष्ट सांगते, आणि इंटरफेस, मार्ग किंवा VPN स्थितीबद्दल काहीही सांगत नाही. लोक Linux कंटेनरकडून अपेक्षित असलेली प्रत्येक गोष्ट — खाजगी नेटवर्क स्टॅक, गाळलेली फाइलसिस्टम, संसाधन मर्यादा — लाँचरने वापरलेल्या किंवा न वापरलेल्या इतर यंत्रणांमधून येते.
म्हणूनच chroot VPN ला वेगळे करते अशी विधाने सामान्यतः चुकीच्या प्रश्नाचे उत्तर देतात. संबंधित प्रश्न असा आहे की प्रक्रिया कोणत्या नेमस्पेसमध्ये चालते आणि ती कोणत्या SELinux डोमेनपुरती मर्यादित आहे; दोन्ही ती कशी सुरू केली गेली याचे गुणधर्म आहेत, chroot या शब्दाचे नाही.
TUN ला तीन गोष्टी लागतात, आणि डिव्हाइस नोड त्यातील एकच
पारंपरिक वापरकर्ता-स्पेस बोगद्याला उघडता येणारे TUN डिव्हाइस, त्या डिव्हाइससाठी कर्नल समर्थन, आणि इंटरफेस व मार्ग संरचीत करण्याची परवानगी लागते. हे स्वतंत्र आवश्यकता आहेत, आणि /dev खाली पथ-नाव तयार करणे त्यातील एकही स्वतः पूर्ण करत नाही:
ls -l /dev/net/tun
ip tuntap add dev tun0 mode tunAndroid वर कर्नलमध्ये TUN समर्थन सहसा संकलित असते, कारण प्लॅटफॉर्मची स्वतःची VPN सेवा ते वापरते, पण याचा अर्थ तुमच्या प्रक्रियेला ते वापरण्याची परवानगी आहे असा नाही. इंटरफेस संरचनेसाठी नेटवर्क-प्रशासन क्षमता लागते, आणि प्रक्रिया डिव्हाइस नोडपर्यंत पोहोचू शकते का हे SELinux ठरवते. नकार स्पष्ट कारण नसलेल्या परवानगी त्रुटीसारखा दिसतो, आणि उत्तर ऑडिट ट्रेलमध्ये असते:
dmesg | grep avc
logcat -d | grep "avc: denied"Root हे सोडवत नाही. uid 0 म्हणून चालणाऱ्या प्रक्रियांना SELinux इतरांप्रमाणेच मर्यादित करते, म्हणून root शेलमधून सुरू केलेल्या chroot ला आपल्याला दिसणाऱ्या डिव्हाइसला नकार मिळू शकतो. जुना इंस्टॉलर चालवण्यासाठी अंमलबजावणी बंद करणे हा बोगद्यापलीकडे परिणाम असलेला संपूर्ण फोनचा निर्णय आहे, आणि तो जुन्या बायनरीसाठी उपाय नाही.
Android ॲप्स तुमच्या बोगद्याकडे दुर्लक्ष का करतात
Android चे समर्थित मॉडेल असे आहे की VPN ॲप प्लॅटफॉर्मच्या VPN सेवेद्वारे नोंदणी करते, वापरकर्त्याकडून एकदा संमती मागते आणि आपल्या बोगद्यासाठी फाइल डिस्क्रिप्टर मिळवते. मग प्लॅटफॉर्म रहदारी त्या डिस्क्रिप्टरमध्ये वळवते आणि वापरकर्ता किंवा प्रशासकाने निवडलेली ॲप-व्याप्ती लागू करते; म्हणूनच तीच यंत्रणा प्रत्येक ॲपसाठी, प्रत्येक प्रोफाइलसाठी आणि always-on व block-without-VPN सेटिंग्जसह एकत्र केलेली असू शकते. Android VPN विकास मार्गदर्शक तो हँडशेक वर्णन करतो, आणि मुख्य मुद्दा असा की ती नोंदणी आहे, मार्गनिर्देशनाची युक्ती नाही.
chroot मधील डीमॉन कधीही नोंदणी करत नाही. संमती संवाद नाही, स्टेटस बारमध्ये की-चिन्ह नाही, प्रत्येक ॲपसाठी समावेश किंवा वगळण्याची यादी नाही, आणि always-on धोरणात सहभाग नाही. त्यामुळे ॲप्स डीफॉल्ट नेटवर्क वापरत राहतात, आणि बोगदा शेल स्वतः पाठवते तेवढेच वाहतो.
दुसऱ्या दिशेने जाण्यानेही फायदा होत नाही. होस्ट नेमस्पेसमध्ये मार्ग ढकलणे सर्व काही पकडते, प्लॅटफॉर्मने स्थानिक ठेवण्याची अपेक्षा केलेल्या रहदारीसह, आणि ते प्रत्येक ॲपसाठी नियंत्रणाशिवाय आणि वापरकर्त्याला ते पाहण्याचा किंवा रद्द करण्याचा मार्ग न देता करते. chroot डीमॉन फक्त एका ॲपसाठी रहदारी मार्गस्थ करेल अशी मधली सेटिंग नाही.
बायनरी सुसंगतता ही वेगळी भिंत आहे
नेटवर्क बाजू मनोरंजक असली तरी, एक्झिक्युटेबलच्या स्वतःच्या आवश्यकता असतात: CPU आर्किटेक्चर, डायनॅमिक लोडर, C लायब्ररी, आणि ती अपेक्षित असलेल्या कर्नल सुविधा. Android glibc ऐवजी bionic वापरते, आणि डेस्कटॉप वितरणासाठी बांधलेल्या जुन्या बायनरीला डिव्हाइसवर आता नसलेल्या लायब्ररी लागू शकतात.
लायब्ररीचे फाइलनाव नव्या आवृत्तीशी सिम्बॉलिक लिंक करणे ABI सुसंगतता निर्माण करत नाही, आणि दशकभर जुन्या पॅकेजमधील संग्रहित क्रिप्टोग्राफिक लायब्ररी ही देखभाल केलेली घटक नाही. योजना यावर अवलंबून असेल तर ती योजना फोनवर नेटवर्क विशेषाधिकारांसह अदेखभाल केलेला कोड चालवण्याची आहे.
Android संदर्भात ते सिद्ध करा आणि नंतर स्वच्छ करा
तुम्हाला खरोखर महत्त्वाचे असलेले, महत्त्वाच्या बाजूने तपासा: विशिष्ट ॲप उघडा, विशिष्ट खाजगी गंतव्य गाठा, कोणत्या रिझॉल्व्हरने उत्तर दिले हे तपासा, नंतर बोगदा डिस्कनेक्ट करा आणि नोंदवलेले वर्तन पुष्टी करा. chroot मधील टर्मिनलकडून मिळालेला निकाल त्या टर्मिनलच्या अंमलबजावणी संदर्भाबद्दलचा पुरावा आहे, त्यापेक्षा जास्त काही नाही.
प्रयोग करताना होस्ट मार्ग बदलले असतील तर ते परत करा आणि काय बदलले ते नोंदवा. नंतर फोनवर always-on VPN संरचीत आहे का ते तपासा, कारण नियम मागे सोडणारा जुना प्रयोग महिन्यांनंतर प्लॅटफॉर्मचा दोष वाटू शकतो.
खऱ्या रिमोट-प्रवेशाच्या गरजेसाठी, सेवेचा समर्थित क्लायंट किंवा मंजूर गेटवे रचना वापरा. विचारण्यासारखा प्रश्न असा नाही की root केलेला इंस्टॉलर चालवता येतो का, तर असा की समर्थित अंमलबजावणी तुम्हाला आवश्यक ॲप्स तुम्ही ठरवलेल्या सीमेपार पोहोचवते का, डिव्हाइसवर मालकी नसलेले विशेषाधिकार बदल मागे न सोडता.