वगळलेले ॲप अजूनही ऑनलाइन? ॲप आणि मार्गाचे नियम वेगळे आहेत

पॅकेज वगळणे हे ब्लॉक नसून मार्गनिर्देशन सूचना आहे, म्हणून 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 सुरू केल्यास, किंवा व्यवस्थापनातून संबंध काढल्यास, ते बदलते.

एका वेळी एक अक्षाचे निदान करा. प्रथम परवानगी किंवा प्रतिबंध निश्चित करा, दुसरे स्थापित UID नियम आणि तक्ते वाचा, आणि शेवटी त्याच गंतव्याविरुद्ध दुसरे ॲप तपासा. दुसरे ॲप एकाच विनंतीत प्रक्रिया निवडीचे गंतव्य निवडीपासून विभाजन करते.

निकाल ॲप, गंतव्य आणि तक्ता क्रमांक असे लिहा. पुढील बदलाने नक्की हेच त्रिक जपले पाहिजे.