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 shell-ээс оруулсан дүрэм дараагийн Wi-Fi шилжилтийн дараа алга болсон байж болно.
Энэ алга бололтыг систем маршрутыг үл тоомсорлож байна гэж ихэвчлэн мэдээлдэг. Үнэндээ болсон зүйл нь хүснэгтийг сонгож байсан дүрэм одоо байхгүй, хүснэгтийн доторх маршрут пакетын өнцгөөс хүрэх боломжгүй болсон явдал юм. Дахин холбогдсоны дараа ажиллаж байсан тохиргоо ажиллахаа болиход маршрутын жагсаалтыг биш, дүрмийн жагсаалтыг шалга.
Дэгээний дарааллын асуултад нийтлэг хариулт байхгүй
iptables VPN маршрутлалтаас өмнө ажилладаг эсэх асуултад пакетын замыг нэрлэхгүйгээр хариулах боломжгүй. Локалаар үүссэн пакет output дэгээгээр дамжина, тэнд тэмдгийн өөрчлөлт дахин маршрутлалтын шалгалтыг өдөөдөг — энэ нь хоёр дахь хайлт, эхнийхийг буцаан засах биш. tether хийсэн клиентээс ирсэн пакет prerouting замаар явж, оронд нь дамжуулагдана, түүнийг хардаг гинжин хэлхээ өөр байна.
Тиймээс нэг дүрэм програмын трафикт үр дүнтэй, tether трафикт үл үзэгдэх байж болно, тэг дээр үлдэх тоолуур пакет ямар зам явсныг хэлнэ, дүрэм буруу эсэхийг биш. Ямар нэг тохирлын нөхцөлийг өөрчлөхөөс өмнө тоолуураар замыг тогтоо.
Энэ нь бодлогын маршрутлалтын алдаа харахад хэцүү болдог үе шат ч юм. Байгаа боловч очих хаяггүй хүснэгт рүү маршрутлах нь галт хананы хасалт мэт харагдах сүлжээ хүрэхгүй гэсэн алдаа үүсгэдэг бол, галт хананы хасалт нь маршрутлалтын хар нүх мэт харагдах хугацаа хэтрэлт үүсгэдэг.
Системийн дотор оношилгоо хий, эсвэл түүнд бүү хүр
Зөвшөөрөгдсөн шалгалтын хувьд ямар нэг зүйлд хүрэхээс өмнө дөрвөн баримтыг тогтоо: програмын uid ба профайл, Android түүнд сонгосон сүлжээ, VPN тэр програмыг ер нь багтаж байгаа эсэх, асуудал хоёр хаягийн бүлэгт хоёуланд нь байгаа эсэх. Програм тус бүрийн хасалт нь маршрутлалтын гэмтэлгүйгээр VPN ажиллахгүй байна гэсэн олон мэдээллийг тайлбарладаг.
Дараа нь бодитоор хүчинтэй дүрэм, маск, хүснэгтийг уншаад, ажиглалтын цонх дотор сүлжээний шилжилтийг байрлуул. Хэрэв зан төлөв дахин холбогдолтын явцад өөрчлөгдвөл та удирдагдаж буй амьдралын мөчлөгийг харж байна, дутуу маршрутыг биш.
Энгийн шаардлагад дэмжигдсэн удирдлагыг ашигла: програм тус бүрийн оруулалт ба хасалт VPN програмын дотор, тодорхой зам шаарддаг бүх зүйлд платформын өөрийн сүлжээний сонголтыг. Хэрэв онцгой эрхтэй интеграц маршрутлалтын механизмтай үнэхээр хамтрах ёстой бол таны дэмждэг яг тэр Android хувилбарын хэрэгжүүлэлтийг зориод, түүнийг эзэмшдэг компонентоор дамжуулан амьдралын мөчлөгийг нь хадгал. Платформын гинжийг цэвэрлэх эсвэл өндөр эрэмбийн дүрэм оруулах нь оношилгоог хоёр дахь сүлжээний менежер болгож хувиргадаг бөгөөд утас нь үүний дагуу ажиллана.