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 आवृत्तीच्या अंमलबजावणीला लक्ष्य करा आणि तिचे जीवनचक्र तिच्या मालकीच्या घटकाद्वारे टिकवा. प्लॅटफॉर्म साखळ्या फ्लश करणे किंवा उच्च प्राधान्याचा नियम घालणे निदानाचे दुसऱ्या नेटवर्क व्यवस्थापकात रूपांतर करते, आणि फोन त्यानुसार वागेल.