Android VPN राउटिङ: main तालिकाअघि नीति-नियम
Android ले कुनै पनि गन्तव्य खोजअघि uid र चिन्ह नियमद्वारा राउटिङ तालिका छान्छ, त्यसैले main मा थपिएको रुट कहिल्यै जाँचिन सक्दैन।
Android मा main तालिकामा थपिएको रुट हरेक सूचीमा सही देखिन्छ र तैपनि ट्राफिक बोक्दैन। कारण यो हो कि main तालिका धेरै विकल्पमध्ये एक हो, र यसलाई पहिले सोधिँदैन। Android को नेटवर्किङ सेवाले गन्तव्य ठेगानामा नभएको जानकारी प्रयोग गरेर राउटिङ तालिका छान्ने नीति-नियमहरू बनाउँछ — एपको uid, प्याकेटमा राखिएको चिन्ह, प्याकेट आएको इन्टरफेस — र गन्तव्यको खोज त्यसपछि, ती नियमले छानेको तालिकाभित्र हुन्छ।
निश्चित क्रममा तीन निर्णय
बाहिर जाने प्याकेटले तीन अलग निर्णय गर्छ। पहिलो, एक नीति-नियमले कुन राउटिङ तालिका लागू हुन्छ भन्ने निर्धारण गर्छ। दोस्रो, त्यो तालिकाभित्रको रुटले अर्को हप र बाहिर जाने इन्टरफेस निर्धारण गर्छ। तेस्रो, netfilter हुकहरूले प्याकेट बाँच्ने, परिवर्तन हुने वा पुनर्निर्देशित हुने निर्धारण गर्छन्।
क्रम महत्त्वपूर्ण छ किनभने हरेक चरणले आफ्नै प्रश्नको मात्र उत्तर दिन सक्छ। प्याकेट स्वीकार गर्ने फायरवाल नियमले तालिका छाँदैन, र कुनै नियमले नछानेको तालिकामा थपिएको रुट निष्क्रिय रहन्छ। Android VPN का बारेमा धेरै भ्रम तीनमध्ये एक सुधारेर कुनै परिवर्तन नदेखिनुबाट आउँछ, किनभने त्रुटि अर्कोमा थियो।
| Stage | Selector | What it cannot decide |
|---|---|---|
| Policy rule | uid range, mark, incoming interface | Which route exists inside the table |
| Route lookup | Destination prefix, longest match | Whether the packet is allowed out |
| Netfilter hook | Chain position, match conditions | Which table was selected |
चिन्हहरू प्याक गरिएको फिल्ड हुन्, तपाईंको आफ्नै लेबल होइन
Android ले धेरै तथ्यलाई एउटै चिन्ह मानमा प्याक गर्छ: कुन नेटवर्क छानियो, कुनै एपले स्पष्ट रूपमा नेटवर्क छान्यो कि, सकेट VPN बाट सुरक्षित छ कि, र अनुमतिसँग सम्बन्धित बिटहरू। AOSP को fwmark हेडरले हालको रूखका लागि त्यो लेआउट परिभाषित गर्छ, र लेआउट संस्करणहरूबीच बदलिने प्लेटफर्मको आन्तरिक कुरा हो।
त्यसैले Android मा iptables -j MARK --set-mark प्रयोग गरेर पूरै चिन्ह मान लेख्नु खतरनाक हुन्छ। यसले ट्याग थप्दैन; यसले प्रणालीले पहिले नै गरेको नेटवर्क छनोटलाई प्रतिस्थापन गर्छ। त्यसपछि प्याकेट अन्य नियमसँग मिल्छ, जुन कुन बिटहरू पुनः लेखिए भन्ने आधारमा VPN ले काम सुरु गरेजस्तो वा असम्बन्धित एपले जडान गुमाएजस्तो देखिन सक्छ।
चिन्हहरूलाई छुनै पर्ने भए, पहिले हालको मान पढ्नुहोस् र तपाईंले बुझेका बिटहरू मात्र बदलिने गरी मास्क प्रयोग गर्नुहोस्:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11जडान चिन्ह प्याकेट चिन्हभन्दा छुट्टै वस्तु हो, र कुनै पनि रुट होइन। जवाफ प्याकेटमा चिन्ह पुनर्स्थापित गर्नु बाहिर जाँदा तालिका छान्नुभन्दा छुट्टै चरण हो, त्यसैले एकतर्फी सुधारले खुल्ने र त्यसपछि अड्किने जडानहरू उत्पन्न गर्छ।
नियम र तालिकाको मालिक को हो
Android को नेटवर्क सेवा, netd, ले नियम र प्रत्येक नेटवर्कका तालिकाहरू बनाउँछ। AOSP RouteController भनेको VPN, भौतिक नेटवर्क र uid दायराका लागि ती नियमहरू जोडिने ठाउँ हो, र यसको जीवनचक्र कन्फिग फाइलसँग नभई नेटवर्क घटनासँग जोडिएको छ।
दुई परिणाम आउँछन्। पहिलो, एउटा ह्यान्डसेटमा भेटिने प्राथमिकता र तालिका नम्बरहरू बिल्डका आन्तरिक विवरण हुन्, इन्टरफेस होइन: अर्को Android संस्करणमा उस्तै देखिने नम्बरहरूले पूरै अर्कै अर्थ दिन सक्छन्। दोस्रो, नेटवर्क बदलिँदा अवस्था पुनः निर्माण हुन्छ, त्यसैले आज root शेलबाट हालिएको नियम अर्को Wi-Fi परिवर्तनपछि हराइसक्न सक्छ।
यो हराउने कुरा प्रायः प्रणालीले रुटलाई बेवास्ता गर्दैछ भनेर रिपोर्ट गरिन्छ। वास्तवमा भएको के हो भने तालिका छान्ने नियम अब अवस्थित छैन, र तालिकाभित्रको रुट अब प्याकेटको दृष्टिकोणबाट पहुँचयोग्य छैन। पुनः जडानपछि काम गर्ने कन्फिगरेसनले काम गर्न छाड्दा रुट सूची होइन, नियम सूची जाँच्नुहोस्।
हुकको क्रमसम्बन्धी प्रश्नको सार्वभौमिक उत्तर छैन
iptables ले VPN राउटिङभन्दा अघि चल्छ कि भन्ने प्रश्नको उत्तर प्याकेटको बाटो नबताई दिन सकिँदैन। स्थानीय रूपमा उत्पन्न प्याकेट output हुकबाट जान्छ, जहाँ चिन्ह परिवर्तनले पुनःराउटिङ जाँच सुरु गर्छ — यो दोस्रो खोज हो, पहिलोको पछिल्लो सम्पादन होइन। tether गरिएको क्लाइन्टबाट आउने प्याकेट prerouting बाटोबाट जान्छ र बरु अगाडि पठाइन्छ, र यसलाई देख्ने चेनहरू अरू हुन्।
त्यसैले एउटै नियम एपको ट्राफिकका लागि प्रभावकारी र tether ट्राफिकका लागि अदृश्य हुन सक्छ, र शून्यमा रहने काउन्टरले प्याकेटले कुन बाटो लियो भन्ने बताउँछ, नियम गलत छ कि छैन भनेर होइन। कुनै पनि मिलान सर्त बदल्नुअघि काउन्टरद्वारा बाटो स्थापित गर्नुहोस्।
नीति-राउटिङको गल्ती देख्न गाह्रो हुने चरण पनि यही हो। अवस्थित तर गन्तव्य नभएको तालिकामा राउट गर्दा फायरवाल ड्रपजस्तो देखिने नेटवर्क अगम्य आउँछ, जबकि फायरवाल ड्रपले राउटिङ ब्ल्याक होलजस्तो देखिने समय समाप्ति दिन्छ।
प्रणालीभित्रै निदान गर्नुहोस्, वा यसलाई छाडिदिनुहोस्
अधिकृत समीक्षाका लागि, केही पनि छुनुअघि चार तथ्य स्थापित गर्नुहोस्: एपको uid र प्रोफाइल, Android ले यसका लागि छानेको नेटवर्क, VPN ले त्यो एप समावेश गर्छ कि गर्दैन, र समस्या दुवै ठेगाना परिवारमा छ कि छैन। प्रति-एप बहिष्करणले कुनै पनि राउटिङ त्रुटिबिना VPN काम गरिरहेको छैन भन्ने धेरै रिपोर्टको व्याख्या गर्छ।
त्यसपछि वास्तवमै लागू भएका नियम, मास्क र तालिका पढ्नुहोस्, र अवलोकन विन्डोभित्र नेटवर्क परिवर्तन राख्नुहोस्। यदि पुनः जडानभरि व्यवहार बदलिन्छ भने तपाईं व्यवस्थित जीवनचक्र हेर्दै हुनुहुन्छ, हराएको रुट होइन।
सामान्य आवश्यकताका लागि समर्थित नियन्त्रणहरू प्रयोग गर्नुहोस्: प्रति-एप समावेश र बहिष्करण VPN अनुप्रयोगमा, र विशेष बाटो चाहिने जुनसुकै कुराका लागि प्लेटफर्मको आफ्नै नेटवर्क छनोट। यदि कुनै विशेषाधिकारप्राप्त एकीकरणले साँच्चै राउटिङ मेसिनरीसँग सहकार्य गर्नुपर्छ भने, तपाईंले समर्थन गर्ने ठ्याक्कै त्यही Android संस्करणको कार्यान्वयनलाई लक्षित गर्नुहोस् र त्यसको मालिक घटकमार्फत यसको जीवनचक्र कायम राख्नुहोस्। प्लेटफर्म चेन फ्लस गर्नु वा उच्च प्राथमिकताको नियम घुसाउनुले निदानलाई दोस्रो नेटवर्क प्रबन्धकमा बदल्छ, र फोन त्यही अनुसार व्यवहार गर्नेछ।