Rutang VPN sa Android: mga tuntunin ng patakaran bago ang talahanayang main

Ang rutang idinagdag sa talahanayang main sa Android ay mukhang tama sa bawat listahan at hindi pa rin dinadala ang trapiko. Ang dahilan ay ang talahanayang main ay isa lamang sa ilang opsyon, at hindi ito ang unang tinatanong. Binubuo ng serbisyo ng network ng Android ang mga tuntunin ng patakaran na pumipili ng talahanayan ng rutang gamit ang impormasyong wala sa address ng destinasyon — ang uid ng app, isang marka sa packet, ang interface kung saan ito dumating — at ang paghahanap ng destinasyon ay nangyayari pagkatapos, sa loob ng talahanayang pinili ng mga tuntuning iyon.

Tatlong desisyon sa isang takdang pagkakasunod-sunod

Ang papasok na packet ay gumagawa ng tatlong magkakahiwalay na desisyon. Una, itinatakda ng tuntunin ng patakaran kung aling talahanayan ng rutang ang nalalapat. Ikalawa, itinatakda ng rutang nasa loob ng talahanayang iyon ang susunod na hop at ang palabas na interface. Ikatlo, nagpapasya ang mga hook ng netfilter kung mabubuhay ang packet, mababago ito, o mairedirekta.

Mahalaga ang pagkakasunod-sunod dahil ang bawat yugto ay makakasagot lamang sa sarili nitong tanong. Ang tuntunin ng firewall na tumatanggap ng packet ay hindi pumipili ng talahanayan, at ang rutang idinagdag sa talahanayang walang tuntuning pumipili ay walang bisa. Malaking bahagi ng kalituhan tungkol sa VPN sa Android ay nagmumula sa pagwawasto ng isa sa tatlo at walang nakikitang pagbabago, dahil nasa iba ang sira.

Ang mga marka ay isang naka-pack na field, hindi isang label na pag-aari mo

Pinagsasama-sama ng Android ang ilang katotohanan sa isang halaga ng marka: aling network ang napili, kung hayagang pumili ng network ang isang app, kung protektado ang socket mula sa VPN, at ang mga bit na may kaugnayan sa mga pahintulot. Tinutukoy ng fwmark header ng AOSP ang layout na iyon para sa kasalukuyang tree, at ang layout ay panloob na detalye ng platform na nagbabago sa pagitan ng mga release.

Kaya mapanganib sa Android na isulat ang buong halaga ng marka gamit ang iptables -j MARK --set-mark. Hindi ito nagdaragdag ng tag; pinapalitan nito ang pagpili ng network na nagawa na ng system. Pagkatapos ay tumutugma ang packet sa ibang mga tuntunin, na maaaring magmukhang nagsimulang gumana ang VPN, o nawalan ng koneksyon ang isang walang kaugnayang app, depende sa kung aling mga bit ang na-overwrite.

Kung kailangan mong hipuin ang mga marka, basahin muna ang kasalukuyang halaga at gumamit ng mask upang ang mga bit lamang na naiintindihan mo ang mabago:

ip rule show
ip route show table all | head -40
ip route get 10.20.4.11

Ang marka ng koneksyon ay hiwalay na object mula sa marka ng packet, at wala sa kanila ang ruta. Ang pagpapanumbalik ng marka sa mga packet ng tugon ay hiwalay na hakbang mula sa pagpili ng talahanayan sa labasan, kaya ang isang-direksyong pagwawasto ay gumagawa ng mga koneksyong bumubukas at pagkatapos ay bumabitin.

Sino ang may-ari ng mga tuntunin at talahanayan

Ang serbisyo ng network ng Android, ang netd, ay lumilikha ng mga tuntunin at talahanayan bawat network. Ang AOSP RouteController ang lugar kung saan binubuo ang mga tuntuning iyon para sa VPN, pisikal na network at hanay ng uid, at ang lifecycle nito ay nakatali sa mga kaganapan ng network kaysa sa isang configuration file.

Dalawang kahihinatnan ang sumusunod. Una, ang mga priyoridad at numero ng talahanayan na makikita mo sa isang aparato ay panloob na detalye ng build, hindi interface: ang magkatulad na numerong makikita sa ibang bersyon ng Android ay maaaring mangahulugan ng lubos na iba. Ikalawa, muling itinatayo ang estado kapag nagbago ang mga network, kaya ang tuntuning ipinasok ngayon mula sa root shell ay maaaring wala na pagkatapos ng susunod na paglipat ng Wi-Fi.

Ang pagkawalang iyon ay madalas iulat na parang binabalewala ng system ang isang ruta. Ang aktwal na nangyari ay wala nang tuntunin na pumipili ng talahanayan, at ang ruta sa loob ng talahanayan ay hindi na maabot mula sa pananaw ng packet. Suriin ang listahan ng mga tuntunin, hindi ang listahan ng mga ruta, kapag tumigil sa paggana ang isang gumaganang configuration pagkatapos ng muling pagkonekta.

Walang pangkalahatang sagot ang mga tanong tungkol sa pagkakasunod-sunod ng mga hook

Ang tanong kung ang iptables ay tumatakbo bago ang routing ng VPN ay hindi masasagot nang hindi pinangalanan ang landas ng packet. Ang packet na ginawa sa lokal ay dumadaan sa hook na output, kung saan ang pagbabago ng marka ay nag-uudyok ng muling pagsusuri ng routing — pangalawang paghahanap, hindi retroactive na pag-edit ng una. Ang packet na galing sa isang tether client ay dumadaan sa landas na prerouting at ipinapasa sa halip, at ang mga chain na nakakakita nito ay iba.

Kaya ang parehong tuntunin ay maaaring mabisa para sa trapiko ng isang app at hindi nakikita para sa trapikong tether, at ang counter na nanatili sa zero ay nagsasabi kung aling landas ang tinahak ng packet, hindi kung mali ang tuntunin. Gumamit ng mga counter upang itatag ang landas bago baguhin ang anumang kundisyon ng pagtutugma.

Ito rin ang yugtong nagiging mahirap makita ang pagkakamali sa routing na batay sa patakaran. Ang pag-route sa talahanayang mayroon ngunit walang destinasyon ay gumagawa ng network na hindi maabot na mukhang drop ng firewall, habang ang drop ng firewall ay gumagawa ng timeout na mukhang itim na butas ng routing.

Magsuri sa loob ng system, o hayaang ito

Para sa awtorisadong pagsusuri, itatag ang apat na katotohanan bago hipuin ang anuman: ang uid at profile ng app, ang network na pinili ng Android para dito, kung isinasama ng VPN ang app na iyon, at kung umiiral ang problema sa parehong pamilya ng address. Ang pagbubukod bawat app ay nagpapaliwanag ng napakaraming ulat na hindi gumagana ang VPN nang walang anumang sira sa routing.

Pagkatapos basahin ang mga tuntunin, mask at talahanayang aktwal na may bisa, at panatilihin ang paglipat ng network sa loob ng window ng pagmamasid. Kung nagbabago ang pag-uugali sa muling pagkonekta, tinitingnan mo ang pinamamahalaang lifecycle, hindi ang nawawalang ruta.

Para sa karaniwang pangangailangan, gamitin ang mga sinusuportahang kontrol: pagsasama at pagbubukod bawat app sa application ng VPN, at ang sariling pagpili ng network ng platform para sa anumang nangangailangan ng partikular na landas. Kung ang isang privileged integration ay talagang kailangang makipagtulungan sa makinarya ng routing, i-target ang implementasyon ng eksaktong bersyon ng Android na sinusuportahan mo at panatilihin ang lifecycle nito sa pamamagitan ng component na may-ari nito. Ang pag-flush ng mga chain ng platform o pagpasok ng tuntuning may mataas na priyoridad ay ginagawang pangalawang tagapamahala ng network ang pagsusuri, at ang telepono ay kikilos ayon doon.