App na hindi kasama, online pa rin? Magkaiba ang mga tuntunin ng app at ruta
Ang pagbubukod ng Android app mula sa VPN ay hindi ito hinaharangan. Ang mga listahan ng pahintulot, mga tuntuning UID at ang mga ipinadalang ruta ang nagtatakda ng magkaibang bahagi ng landas.
Ang pagbubukod ng pakete ay tagubilin sa pagruruta, hindi pagharang, kaya ang mga pahinang naglo-load pagkatapos kumonekta ang VPN ay inaasahan at hindi patunay ng pagkabigo. Inaalis ng pagbubukod ang app mula sa lagusan sa halip na harangin ito, at ang karaniwang network ang nagdadala ng trapiko nito. Dalawang magkaibang patakaran ang nagtatagpo dito: pinipili ng isa ang mga proseso, pinipili ng isa pa ang mga destinasyon. Ang pagbasa sa kanila sa ganoong pagkakasunod-sunod ay nagpapaliwanag kung bakit ang konektadong icon at gumaganang app ay hindi magkasalungat.
Bakit pinananatiling bukas ng pagbubukod ang network
Tinatanggap ng VpnService.Builder ang listahan ng pahintulot o listahan ng pagbabawal, hindi kailanman pareho. Tanging mga pakete sa listahan ng pahintulot ang dumadaan sa lagusan. Binabaliktad ito ng listahan ng pagbabawal: bawat pakete maliban sa mga nakalista ay gumagamit ng lagusan, at ang mga nakalista ay nagpapanatili ng pisikal na landas. Ang paketeng hindi nakalista sa ilalim ng listahan ng pahintulot ay nasa labas din ng lagusan, kaya ang pagbubukod ay ang normal na kalagayan ng karamihan sa mga app sa ganoong mode.
Ginagawa nitong desisyon sa pagruruta ang lokal na entry ng pagbabawal, hindi tuntunin ng firewall. Kung ang pangangailangan ay pigilan ang app na maabot ang host, kailangang saklawin ito ng lagusan at kailangang tanggihan ng server o lokal na patakaran ang trapiko. Ang pag-alis ng app mula sa lagusan ay nagbabago lamang kung aling interface ang nagdadala ng mga pakete nito.
Ang kaso ng Play Store ay ang karaniwang sinadyang halimbawa. Ang pagbubukod sa pakete ng tindahan ay nagpapahintulot sa mga download na gamitin ang pinagbabatayang koneksyon kapag ang labasan ng VPN ay nakikialam sa mga paglilipat, at ipinapakita na ang pagbubukod ay nangangahulugang pag-iwas, hindi pagharang.
Isang profile, isang listahan
Nagtatapon ng eksepsiyon ang tagabuo kung gagamitin ang dalawang tawag, kaya ang profile sa harap mo ay listahan ng pahintulot o listahan ng pagbabawal. Ang nag-iisang katotohanang iyon ang nagtatakda kung paano basahin ang bawat susunod na obserbasyon. Suriin ang code o ang pinamamahalaang configuration bago ang talahanayan ng pagruruta, dahil ang listahan ang nagtatakda ng kahulugan ng natitirang output. Ang hybrid na profile ay hindi kalagayang maaari mong tingnan.
Ang pagkakaiba ay hinuhulaan din kung ano ang gagawin ng bagong naka-install na app. Sa ilalim ng listahan ng pahintulot mananatili ito sa labas hanggang may magdagdag dito, samantalang sa ilalim ng listahan ng pagbabawal sumasama ito sa lagusan bilang default.
Ipinapakita ng mga pinamamahalaang configuration ang parehong pagpipilian sa ilalim ng iba't ibang pangalan ng key, at inilalarawan ito ng ilang console bilang mode ng VPN kada app sa halip na listahan. Bumababa pa rin ang pag-uugali sa dalawang tawag na iyon, kaya sundan ang setting pabalik hanggang sa listahan ng pakete sa halip na magtiwala sa label. Kung hindi magtugma ang label at listahan, ang listahan ang mananalo.
Sundin ang tuntuning UID hanggang sa talahanayan ng lagusan
Binibigyan ng Android ang bawat app ng sarili nitong Linux user ID, at ang serbisyo ng VPN ay nag-iinstall ng mga tuntunin ng patakaran na tumutugma sa mga saklaw ng UID. Ang tumutugmang trapiko ay ipinapadala sa talahanayan ng pagruruta na ang default na ruta ay tumuturo sa tun device. Ang numero ng talahanayan ay inilalaan kada instance ng VPN, kaya nagbabago ito pagkatapos muling kumonekta o pagkatapos gumawa ng pangalawang profile ng VPN.
Ang output ng mga tuntunin ay ang mapa. Binabanggit ng bawat linya ang isang talahanayan ng paghahanap, at ang talahanayang iyon ang may hawak ng default na rutang nagtatakda kung ang tumutugmang mga pakete ay pumapasok sa lagusan.
adb shell ip rule show
adb shell ip route show table all
adb shell cmd package list packages -U | grep <package>
Patakbuhin muna ang ikatlong utos upang makuha ang UID, pagkatapos hanapin ang tuntuning naglalaman nito sa saklaw. Itinuturo ng tuntuning iyon ang numero ng talahanayan, at ip route show table <n> sa numerong iyon makikita kung may default na ruta sa pamamagitan ng tun device. Kung walang default ang talahanayan, napili ang app ngunit walang landas, na ibang pagkabigo.
Ang mga utos na ito ay nangangailangan ng build na maaaring i-debug o device kung saan mababasa ng adb shell ang kalagayan ng network. Sa production phone sumasagot pa rin ang tagapamahala ng pakete, ngunit maaaring tanggihan ang inspeksiyon ng pagruruta, kaya itala ang kaya mo at ituring na hindi pa beripikado ang natitira.
Humihingi ng prefix ang ruta, hindi app
Humihingi ng mga prefix ng destinasyon ang Builder.addRoute para sa lagusan. 10.0.0.0/8 Ang profile na nagdadagdag lamang ay nagpapadala ng prefix na iyon sa lagusan at iniiwan ang bawat ibang destinasyon sa pisikal na landas. Ito ay karaniwang hati na lagusan, at hindi ito nakadepende sa kung aling mga app ang pinili ng mga tuntunin.
Sinasalamin ng configuration na itinutulak ng server ang parehong modelo. Ang mga indibidwal na pagtulak ng ruta ay nagdadagdag ng prefix, samantalang pinapalitan ng direktibang redirect-gateway ang default na ruta at hinuhuli ang lahat para sa mga app na saklaw ng lagusan. Ang pag-alis ng direktibang iyon ay maaaring paliitin ang gumaganang lagusan sa isang subnet nang walang anumang pagbabago sa device.
Ang ruta na itinulak na may kakaibang gateway o panukat na kwalipikador ay maaari ring mabigong mai-install. Piliin ang simpleng anyo ng prefix at hayaang hawakan ng server ang pagpapasa at NAT.
Basahin ang interseksiyon bago baguhin ang isang setting
Dinadala ng lagusan ang interseksiyon ng mga saklaw na proseso at ng mga hinihinging destinasyon. Ang saklaw na app na humihingi ng address sa labas ng mga nailathalang prefix ay lumalabas sa pisikal na network. Ang ipinagbabawal na pakete ay nananatili sa labas kahit humihingi ito ng address sa loob ng mga prefix na iyon. Wala sa dalawa ang bug; pareho silang ang dalawang patakarang gumagawa ng kanilang trabaho.
Ang VPN kada app ay maaari ring mag-iwan ng kaugnay na app na walang konektibidad. Kapag patay ang on-demand at nakababa ang lagusan, nananatiling nakatali ang app sa VPN kada app at walang reserba, na mukhang sirang app sa halip na kalagayan ng patakaran. Ang pag-on ng on-demand, o pag-alis ng kaugnayan sa pamamagitan ng pamamahala, ay nagbabago niyon.
| Layer | What it selects | Where to look | Typical mismatch |
|---|---|---|---|
| Package list | Processes | Builder calls or managed configuration | App excluded but expected to be blocked |
| UID policy rule | Which table a UID uses | ip rule show | Tunnel icon on, app still on Wi-Fi |
| Routing table | Destinations for matched traffic | ip route show table <n> | Covered app reaches only one subnet |
| Server push | Prefixes offered to the client | Server route configuration | Tunnel shrinks after a server edit |
Suriin ang isang aksis bawat pagkakataon. Tiyakin muna ang pahintulot o pagbabawal, basahin ang mga naka-install na tuntuning UID at talahanayan bilang pangalawa, at subukan ang pangalawang app laban sa parehong destinasyon sa huli. Hinihiwalay ng pangalawang app ang pagpili ng proseso mula sa pagpili ng destinasyon sa isang kahilingan.
Itala ang resulta bilang app, destinasyon at numero ng talahanayan. Iyon ang triplet na dapat panatilihin ng susunod na pagbabago.