बहिष्कृत एप अझै अनलाइन? एप र मार्गका नियम फरक छन्
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 नियम र तालिका पढ्नुहोस्, र अन्त्यमा त्यही गन्तव्यविरुद्ध दोस्रो एप परीक्षण गर्नुहोस्। दोस्रो एपले एउटै अनुरोधमा प्रक्रिया छनोटलाई गन्तव्य छनोटबाट अलग गर्छ।
नतिजा एप, गन्तव्य र तालिका नम्बरका रूपमा लेख्नुहोस्। अर्को परिवर्तनले ठ्याक्कै यही त्रिक जोगाउनुपर्छ।