बहिष्कृत ऐप अब भी ऑनलाइन? ऐप और रूट के नियम अलग हैं
Android ऐप को VPN से बाहर रखना उसे ब्लॉक नहीं करता। अनुमति सूचियाँ, UID नीति नियम और भेजे गए रूट पथ का अलग-अलग हिस्सा तय करते हैं।
पैकेज को बाहर रखना ब्लॉक नहीं, रूटिंग निर्देश है, इसलिए VPN जुड़ने के बाद लोड होने वाले पेज अपेक्षित हैं, विफलता का प्रमाण नहीं। बहिष्करण ऐप को ब्लॉक करने के बजाय टनल से हटा देता है, और सामान्य नेटवर्क उसका ट्रैफ़िक ढोता है। यहाँ दो अलग नीतियाँ मिलती हैं: एक प्रक्रियाएँ चुनती है, दूसरी गंतव्य चुनती है. उन्हें इसी क्रम में पढ़ने से समझ आता है कि जुड़ा हुआ आइकन और चलता हुआ ऐप विरोधाभास क्यों नहीं हैं।
बहिष्करण नेटवर्क को खुला क्यों रखता है
VpnService.Builder या तो अनुमति सूची लेता है या निषेध सूची, दोनों कभी नहीं। अनुमति सूची के पैकेज ही टनल से जाते हैं। निषेध सूची इसे उलट देती है: सूचीबद्ध के अलावा हर पैकेज टनल का उपयोग करता है, और सूचीबद्ध भौतिक पथ पर बने रहते हैं। अनुमति सूची में शामिल न किया गया पैकेज भी टनल से बाहर रहता है, इसलिए उस मोड में अधिकांश ऐप के लिए बहिष्करण सामान्य स्थिति है।
इससे स्थानीय निषेध प्रविष्टि फ़ायरवॉल नियम नहीं, रूटिंग निर्णय बन जाती है। अगर आवश्यकता किसी ऐप को होस्ट तक पहुँचने से रोकना है, तो टनल को उसे ढकना होगा और सर्वर या स्थानीय नीति को ट्रैफ़िक अस्वीकार करना होगा। ऐप को टनल से हटाना केवल यह बदलता है कि उसके पैकेट कौन-सा इंटरफ़ेस ढोता है।
Play Store का मामला सामान्य जानबूझकर लिया गया उदाहरण है। स्टोर पैकेज को बाहर रखने से डाउनलोड अंतर्निहित कनेक्शन का उपयोग कर पाते हैं जब VPN निकास स्थानांतरण में बाधा डालता है, और यह दिखाता है कि बहिष्करण का अर्थ ब्लॉक नहीं, बचाव है।
एक प्रोफ़ाइल, एक सूची
दोनों कॉल उपयोग होने पर बिल्डर अपवाद फेंकता है, इसलिए आपके सामने की प्रोफ़ाइल या तो अनुमति सूची है या निषेध सूची। यही एक तथ्य तय करता है कि हर बाद के अवलोकन को कैसे पढ़ा जाए। रूटिंग तालिका से पहले कोड या प्रबंधित कॉन्फ़िगरेशन जाँचें, क्योंकि सूची ही तय करती है कि बाकी आउटपुट का क्या अर्थ है। संकर प्रोफ़ाइल ऐसी स्थिति नहीं है जिसे आप देख सकें।
यह अंतर यह भी बताता है कि नई स्थापित ऐप क्या करेगी। अनुमति सूची में वह बाहर रहती है जब तक कोई उसे जोड़ न दे, जबकि निषेध सूची में वह डिफ़ॉल्ट रूप से टनल में शामिल हो जाती है।
प्रबंधित कॉन्फ़िगरेशन यही चुनाव अलग कुंजी नामों के अंतर्गत दिखाते हैं, और कुछ कंसोल इसे सूची के बजाय प्रति-ऐप VPN मोड कहते हैं। व्यवहार फिर भी उन्हीं दो कॉल तक सिमटता है, इसलिए लेबल पर भरोसा करने के बजाय सेटिंग को पैकेज सूची तक पीछे ट्रेस करें। अगर लेबल और सूची में मेल न हो, सूची जीतती है।
UID नियम का पालन करते हुए टनल तालिका तक जाएँ
Android हर ऐप को उसका अपना Linux उपयोगकर्ता ID देता है, और VPN सेवा UID श्रेणियों से मेल खाते नीति नियम स्थापित करती है। मेल खाता ट्रैफ़िक ऐसी रूटिंग तालिका में भेजा जाता है जिसका डिफ़ॉल्ट रूट tun डिवाइस की ओर इशारा करता है। तालिका संख्या प्रत्येक VPN इंस्टेंस के लिए आवंटित होती है, इसलिए फिर से जुड़ने या दूसरी VPN प्रोफ़ाइल बनने के बाद वह बदल जाती है।
नियमों का आउटपुट ही नक्शा है। हर पंक्ति एक लुकअप तालिका का नाम लेती है, और वह तालिका वह डिफ़ॉल्ट रूट रखती है जो तय करता है कि मेल खाते पैकेट टनल में प्रवेश करेंगे या नहीं।
adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>UID पाने के लिए पहले तीसरा कमांड चलाएँ, फिर वह नियम खोजें जिसकी श्रेणी में वह आता है। वह नियम तालिका संख्या की ओर इशारा करता है, और ip route show table <n> उस संख्या के साथ दिखाता है कि tun डिवाइस से होकर कोई डिफ़ॉल्ट रूट है या नहीं। अगर तालिका में डिफ़ॉल्ट न हो, तो ऐप चुना गया है पर उसका कोई पथ नहीं, जो अलग विफलता है।
इन कमांड के लिए डिबग करने योग्य बिल्ड या ऐसा डिवाइस चाहिए जहाँ adb shell नेटवर्क स्थिति पढ़ सके। उत्पादन हैंडसेट पर पैकेज मैनेजर फिर भी उत्तर देता है, पर रूटिंग जाँच अस्वीकार हो सकती है, इसलिए जो कर सकें दर्ज करें और बाकी को असत्यापित मानें।
रूट प्रीफ़िक्स का दावा करता है, ऐप का नहीं
Builder.addRoute टनल के लिए गंतव्य प्रीफ़िक्स का दावा करता है। जो प्रोफ़ाइल केवल 10.0.0.0/8 जोड़ती है वह उस प्रीफ़िक्स को टनल से भेजती है और हर दूसरे गंतव्य को भौतिक पथ पर छोड़ती है। यह सामान्य विभाजित टनलिंग है, और यह इस पर निर्भर नहीं करती कि नियमों ने कौन-से ऐप चुने।
सर्वर से भेजा गया कॉन्फ़िगरेशन वही मॉडल दोहराता है। अलग-अलग रूट पुश प्रीफ़िक्स जोड़ते हैं, जबकि redirect-gateway निर्देश डिफ़ॉल्ट रूट बदल देता है और टनल जिन ऐप को ढकता है उनके लिए सब कुछ पकड़ लेता है। उस निर्देश को हटाने से चलता हुआ टनल डिवाइस पर किसी भी बदलाव के बिना एक सबनेट तक सिकुड़ सकता है।
असामान्य गेटवे या मीट्रिक क्वालिफ़ायर वाला भेजा गया रूट भी स्थापित होने में विफल हो सकता है। सादा प्रीफ़िक्स रूप पसंद करें और फ़ॉरवर्डिंग तथा NAT सर्वर को सौंपें।
सेटिंग बदलने से पहले प्रतिच्छेद पढ़ें
टनल ढके हुए प्रक्रियाओं और दावा किए गए गंतव्यों का प्रतिच्छेद ढोता है। ढका हुआ ऐप प्रकाशित प्रीफ़िक्स के बाहर का पता माँगे तो भौतिक नेटवर्क से निकलता है। निषिद्ध पैकेज उन प्रीफ़िक्स के भीतर का पता माँगने पर भी बाहर रहता है। दोनों में से कोई दोष नहीं; दोनों वही दो नीतियाँ अपना काम कर रही हैं।
प्रति-ऐप VPN किसी संबद्ध ऐप को कनेक्टिविटी के बिना भी छोड़ सकता है। जब on-demand बंद हो और टनल नीचे हो, ऐप प्रति-ऐप VPN से बँधा रहता है और उसके पास कोई विकल्प नहीं होता, जो नीति की स्थिति नहीं बल्कि टूटा ऐप जैसा दिखता है। on-demand चालू करना, या प्रबंधन से संबंध हटाना, इसे बदलता है।
| Layer | What it selects | Where to look | Typical mismatch |
|---|---|---|---|
| Package list | Processes | Builder calls or managed configuration | App excluded but expected to be blocked |
| UID policy rule | Which table a UID uses | ip rule show | Tunnel icon on, app still on Wi-Fi |
| Routing table | Destinations for matched traffic | ip route show table <n> | Covered app reaches only one subnet |
| Server push | Prefixes offered to the client | Server route configuration | Tunnel shrinks after a server edit |
एक बार में एक अक्ष का निदान करें। पहले अनुमति या निषेध की पुष्टि करें, दूसरे स्थापित UID नियम और तालिकाएँ पढ़ें, और अंत में उसी गंतव्य के विरुद्ध दूसरा ऐप जाँचें। दूसरा ऐप एक ही अनुरोध में प्रक्रिया चयन को गंतव्य चयन से अलग करता है।
परिणाम को ऐप, गंतव्य और तालिका संख्या के रूप में लिखें। यही त्रिक अगले बदलाव को बनाए रखना है।