Android chroot VPN: सुरुङ किन काम गर्छ तर एपहरूले यसलाई बेवास्ता गर्छन्

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

शेल भन्छ जोडियो, एपहरू सहमत छैनन्

पहिलो नतिजा सामान्य हो। chroot बाट खोलिएको प्रयोगकर्ता-स्पेस सुरुङले आफ्नो ह्यान्डसेक पूरा गर्न सक्छ, तथ्याङ्क छाप्न सक्छ र त्यही शेलले उत्पादन गर्ने ट्राफिक बोक्न सक्छ, तर Android का एपहरू फोनको पूर्वनिर्धारित नेटवर्क प्रयोग गरिरहन्छन्। तिनीहरूलाई केहीले रोक्दैन, किनकि VPN छ भनी Android लाई कसैले भनेको थिएन।

दोस्रो नतिजा खतरनाक हो। chroot ले Android को नेटवर्क नेमस्पेस साझा गर्यो भने, जुन पूर्वनिर्धारित रूपमा गर्छ, पर्याप्त विशेषाधिकार भएको प्रक्रियाले सम्पूर्ण फोनमा असर गर्ने मार्ग र TUN इन्टरफेस थप्न सक्छ। त्यसपछि सुरुङ हरेक एपका लागि काम गर्छ, तपाईंले रुट गर्न नचाहेका एपहरू पनि, र फोनको कनेक्टिभिटी अब जीवनचक्र व्यवस्थापन, जडान सूचक र always-on नीति नभएको डेमनमा निर्भर हुन्छ।

तपाईंले कुन पाउनुभयो भन्ने एउटै आदेशले थाहा हुन्छ। chroot भित्रको ip route लाई त्यसको बाहिरको Android शेलबाट त्यही आदेशसँग तुलना गर्नुहोस्। समान आउटपुट भनेको chroot होस्ट नेमस्पेसमा छ: यसले गर्ने कुनै पनि नेटवर्किङ परिवर्तन सम्पूर्ण फोनमा लागू हुन्छ। फरक आउटपुट भनेको लन्चरले यसका लागि नेमस्पेस बनायो, र यसको सुरुङ Android का लागि संरचनागत रूपमै अदृश्य छ।

chroot ले के बदल्यो र के बदलेन

chroot सिस्टम कलले एउटै काम गर्छ: पथ नाम खोजीका लागि प्रयोग हुने डाइरेक्टरी बदल्छ। यो सुरक्षा सीमा होइन भनी म्यान पेजले स्पष्ट भन्छ, र इन्टरफेस, मार्ग वा 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 ले यसलाई समाधान गर्दैन। 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 गरिएको इन्स्टलर चलाउन सकिन्छ कि भन्ने होइन, तर समर्थित कार्यान्वयनले तपाईंलाई चाहिने एपहरू तपाईंले चाहेको सीमापार पुर्याउँछ कि भन्ने हो, यन्त्रमा मालिकविहीन विशेषाधिकार परिवर्तन नछोडी।