रूट बिना Android VPN: सहमति, मार्ग र ब्लकिङ कसको
सहमति, TUN इन्टरफेस र प्रणालीको ब्लकिङ नीति तीन फरक अनुमति हुन्। Android VPN एप समीक्षा गर्नुअघि कुन घटकले कुनको स्वामित्व राख्छ पहिचान गर्नुहोस्।
रूट त्यो होइन जसले Android VPN एपलाई ट्राफिक बोक्न, चुहावट रोक्न वा रिबुटपछि टिकिरहन सक्षम बनाउँछ। मानिसहरू यी सबैलाई „एपसँग VPN अनुमति छ“ भनेर सारांश गर्छन्, जसले तीन छुट्टै संयन्त्र लुकाउँछ: प्रयोगकर्ताको सहमति, प्रणालीले बनाउने प्याकेट इन्टरफेस, र प्लेटफर्मको ब्लकिङ नीति जुन एपले परिभाषित गर्ने कुरा होइन। Android VPN डिजाइन समीक्षा गर्नु भनेको कुनै दाबी वास्तवमा यी तीनमध्ये कुनमा टिकेको छ भनेर सोध्नु हो, किनकि प्रत्येकको मालिक र असफलताको तरिका फरक छ।
सहमति प्रणाली गतिविधिबाट आउँछ
VpnService.prepare() केही दिँदैन। सहमति नभएपछि यसले प्रणाली सहमति गतिविधिमा intent फर्काउँछ, र प्रयोगकर्ताले सेवा स्वीकृत गर्न सकून् भनेर एपले त्यो संवाद खोल्छ। एपको आफ्नै प्रक्रिया सुरु गर्नु, म्यानिफेस्टमा अनुमति थप्नु, वा अनुकूलित „VPN सक्षम गर्नुहोस्“ स्क्रिन देखाउनुले अनुमति बनाउँदैन।
अनुमतिको दायरा पनि सीमित छ। यो प्रयोगकर्ता प्रोफाइलभित्रको प्याकेजको हो, त्यसैले व्यक्तिगत प्रतिलिपि र कार्य प्रतिलिपि छुट्टै निर्णय हुन्, र यन्त्र मालिकले व्यवस्थापित प्रोफाइललाई व्यक्तिगतभन्दा फरक तरिकाले तयार गर्न सक्छन्। यदि संवाद कहिल्यै देखिएन र prepare() ले null फर्कायो भने, त्यो प्रोफाइलमा त्यो प्याकेजको सहमति पहिले नै छ; यो एप विश्वसनीय हुनुको प्रमाण होइन, अनुमति मात्र छ भन्ने हो।
इन्टरफेस प्रणालीले पूरा गर्ने अनुरोध हो
सहमतिपछि एपले VpnService.Builder प्रयोग गरेर के चाहिन्छ भन्छ: ठेगानाहरू, मार्गहरू, DNS सर्भरहरू, MTU र समर्थित भएको ठाउँमा समावेश वा बहिष्कृत गर्ने एपहरू। establish() ले प्रणालीलाई टनेल इन्टरफेस बनाई मिल्ने ट्राफिक त्यसमा पठाउन अनुरोध गर्छ। राउटिङ निर्णय प्रणालीको हो; एपले फाइल डिस्क्रिप्टर पाउँछ र त्यसपछि प्याकेटसँग केही उपयोगी गर्नुपर्छ।
| What you observe | Who actually owns it |
|---|---|
| VPN consent dialog | The system, triggered by prepare() |
| Routes, DNS and app lists | The app requests them; the system applies them |
| One active VPN per profile | The platform; a new service replaces the old one |
| Always-on and block-without-VPN | Device policy enforced by the platform |
त्यो तालिका एकै ठाउँमा वास्तुकला हो। एप प्याकेट ह्यान्डलिङमा सहभागी हुन्छ; इन्टरफेस, राउटिङ तालिका वा चल्न सक्ने सेवाहरूको संख्या यसको होइन।
टनेल सकेटले आफ्नै टनेलबाट भाग्नुपर्छ
इन्क्रिप्टेड ट्राफिक बोक्ने जडान आफैं एक सकेट हो। यदि यो एपले भर्खरै बनाएको इन्टरफेसमा फर्काइयो भने, टनेल टनेलमा निर्भर हुन्छ र रोकिन्छ। VpnService.protect() ले त्यो सकेटलाई तल्लो सञ्जालसँग बाँध्छ ताकि यसले क्याप्चरबाट बच्न सकोस्, त्यसैले सही क्लाइन्टले पहिलो ह्यान्डशेकअघि आफ्नो बाहिरी सकेट सुरक्षित गर्छ।
adb shell dumpsys connectivity | grep -i -A5 vpn
adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdownयी आदेशहरूले स्थापित VPN सञ्जाल, सधैं खुला प्याकेज र लकडाउन सेट छ कि छैन देखाउँछन्। यी केवल पढ्ने अवलोकन हुन्: यदि मानहरू डिजाइनको दाबीसँग मिलेनन् भने, दाबी प्रणालीको अवस्थाबारे होइन, एपको इन्टरफेसबारे हो।
ब्लकिङ प्लेटफर्मको हुन सक्छ
Android ले VPN प्रयोग नगर्ने जडानहरू ब्लक गर्ने नीतिको दस्तावेजीकरण गर्छ। त्यो प्रवर्तन प्लेटफर्मको सम्झौता हो, एपले लूपमा जडान पुनः प्रयास गर्ने होइन। स्विच यन्त्रको VPN सेटिङमा „VPN बिना जडान ब्लक गर्नुहोस्“ का रूपमा छ, र व्यवस्थापित यन्त्रमा मालिकले यसलाई पूरै प्रोफाइलका लागि खोल्न सक्छन्। मार्केटिङ दाबी मूल्याङ्कन गर्दा यो भिन्नता महत्त्वपूर्ण छ: क्लाइन्टले ताल्चा आइकन देखाएर आक्रामक रूपमा पुनः जडान गर्न सक्छ जबकि सीधा ट्राफिक अझै सम्भव छ, वा समेटिएका एपहरू प्रणालीले लकडाउन लागू गरेकाले अफलाइन रहन सक्छन्।
ताल्चाको आइकन एपले कोर्छ, त्यसैले यसले एप आफैं जोडिएको छ भन्ने विश्वास गर्छ भन्ने मात्र प्रमाणित गर्छ। अर्को एपले आफ्नो सञ्जाल पहुँच गुमाउँछ कि भन्ने प्लेटफर्मले निर्णय गर्छ, त्यसैले उपयोगी जाँच भनेको टनेल खुला रहँदा त्यो एप असफल हुनु हेर्नु हो।
एप स्टोरको „सधैं खुला“ लेबलले पनि त्यो सम्झौताको प्रतिस्थापन गर्दैन। सधैं खुला र लकडाउन यन्त्र सेटिङ हुन्, प्रायः यन्त्र मालिकले लागू गर्छन्, र बहिष्कृत एपहरूका लागि तिनको व्यवहार प्लेटफर्मले परिभाषित गर्छ। ब्याज होइन, सेटिङ पढ्नुहोस्।
डिजाइन समीक्षाका लागि चार प्रश्न
पहिलो, कसले सहमति दियो: कुन प्याकेज, कुन प्रोफाइल, र त्यो प्रयोगकर्ता थियो कि व्यवस्थापित यन्त्र नीति? दोस्रो, एपले के माग्यो: कुन मार्ग, कुन ठेगाना परिवार, कुन एप समावेश वा बहिष्कृत? तेस्रो, टनेल उपलब्ध नहुँदा के हुन्छ: प्रणालीले ब्लक गर्छ कि ट्राफिक तल्लो सञ्जालमा फर्कन्छ? चौथो, एपले प्राप्त प्याकेटसँग के गर्छ?
चौथो प्रश्न त्यो हो जसको उत्तर अनुमति मोडेलले दिन सक्दैन। सहमति र TUN इन्टरफेसले एपले ट्राफिक प्राप्त गर्न सक्छ भन्ने प्रमाणित गर्छन्, त्यसलाई इन्क्रिप्ट गर्छ, साथीलाई प्रमाणित गर्छ वा सफा रूपमा पुनःस्थापित हुन्छ भन्ने होइन। यी कार्यान्वयनका गुण हुन्, र इमानदार समीक्षाले त्यहीँ समय बिताउँछ।
अनावश्यक रूट अनुरोधलाई नतिजालाई किल स्विच भनेर वैध बनाउँदैन, र सहमति संवाद सुरक्षा अडिट होइन। तीनै अनुमति छुट्टाछुट्टै राख्नुहोस्, हरेक दाबी जाँचयोग्य हुन्छ।