VPN sa Android na walang root: kanino ang pahintulot, ruta at pagharang
Ang pahintulot, TUN interface at patakaran ng pagharang ng system ay tatlong magkaibang permiso. Alamin kung aling bahagi ang may-ari ng bawat isa bago suriin ang isang app na VPN para sa Android.
Hindi root ang nagbibigay-daan sa isang app na VPN sa Android na magdala ng trapiko, harangan ang pagtagas o mabuhay pagkatapos ng reboot. Pinagsasama-sama ito ng mga tao bilang „may permiso ng VPN ang app“, na nagtatago ng tatlong magkahiwalay na mekanismo: pahintulot mula sa gumagamit, interface ng packet na itinatag ng system, at patakaran ng pagharang ng platform na hindi para sa app na tukuyin. Ang pagsusuri sa disenyo ng VPN sa Android ay nangangahulugang itanong kung alin sa tatlo ang tunay na pinagbabatayan ng isang pahayag, dahil bawat isa ay may ibang may-ari at ibang paraan ng pagpalya.
Dumarating ang pahintulot sa pamamagitan ng aktibidad ng system
VpnService.prepare() walang ibinibigay. Nagbabalik ito ng intent sa aktibidad ng pahintulot ng system kapag kulang ang pahintulot, at binubuksan ng app ang dialog na iyon upang aprubahan ng gumagamit ang serbisyo. Ang pagsisimula ng sariling proseso ng app, pagdaragdag ng permiso sa manifest, o pagpapakita ng pasadyang screen na „i-enable ang VPN“ ay hindi lumilikha ng pahintulot.
May saklaw din ang pahintulot. Pag-aari ito ng isang pakete sa isang profile ng gumagamit, kaya magkaibang desisyon ang personal na kopya at kopya sa trabaho, at maaaring ihanda ng may-ari ng device ang pinamamahalaang profile nang iba kaysa sa personal. Kung hindi kailanman lumabas ang dialog at nagbalik ng null ang prepare(), may pahintulot na para sa paketeng iyon sa profile na iyon; hindi iyon patunay na mapagkakatiwalaan ang app, nagpapakita lamang na may permiso.
Ang interface ay kahilingang tinutupad ng system
Pagkatapos ng pahintulot, inilalarawan ng app ang gusto nito gamit ang VpnService.Builder: mga address, ruta, DNS server, MTU at, kung sinusuportahan, ang mga app na isasama o ibubukod. Hinihiling ng establish() sa system na likhain ang interface ng tunnel at ihatid doon ang tugmang trapiko. Pag-aari ng system ang desisyon sa pagruruta; natatanggap ng app ang file descriptor at pagkatapos ay kailangang gumawa ng kapaki-pakinabang sa mga packet.
| What you observe | Who actually owns it |
|---|---|
| VPN consent dialog | The system, triggered by prepare() |
| Routes, DNS and app lists | The app requests them; the system applies them |
| One active VPN per profile | The platform; a new service replaces the old one |
| Always-on and block-without-VPN | Device policy enforced by the platform |
Ang talahanayang iyon ang arkitektura sa isang lugar. Lumalahok ang app sa paghawak ng packet; hindi ito nagmamay-ari ng interface, routing table o bilang ng mga serbisyong maaaring tumakbo.
Kailangang makatakas ang socket ng tunnel sa sarili nitong tunnel
Ang koneksiyong nagdadala ng naka-encrypt na trapiko ay isa ring socket. Kung iruruta ito pabalik sa interface na kalilikha lamang ng app, umaasa ang tunnel sa tunnel at humihinto. Itinatali ng VpnService.protect() ang socket na iyon sa pinagbabatayang network upang malampasan ang paghuli, at dahil doon pinoprotektahan ng tamang client ang panlabas na socket nito bago ang unang handshake.
adb shell dumpsys connectivity | grep -i -A5 vpn
adb shell settings get global always_on_vpn_app
adb shell settings get global always_on_vpn_lockdownIpinapakita ng mga utos na ito ang naka-install na network ng VPN, ang packet na laging naka-on at kung nakatakda ang lockdown. Mga obserbasyong babasahin lamang ang mga ito: kung hindi tugma ang mga halaga sa sinasabi ng disenyo, ang pahayag ay tungkol sa interface ng app at hindi sa kalagayan ng system.
Maaaring pag-aari ng platform ang pagharang
Dinodokumento ng Android ang patakarang humaharang sa mga koneksiyong hindi gumagamit ng VPN. Ang pagpapatupad na iyon ay kontrata ng platform, hindi isang app na paulit-ulit na sumusubok kumonekta sa loop. Nasa settings ng VPN ng device ang switch bilang Harangan ang mga koneksiyon nang walang VPN, at sa pinamamahalaang device maaaring i-on ito ng may-ari para sa buong profile. Mahalaga ang pagkakaibang ito kapag tinatasa ang pahayag sa marketing: maaaring magpakita ng icon ng kandado ang client at agresibong muling kumonekta habang posible pa ang direktang trapiko, o maaaring manatiling offline ang mga sakop na app dahil ipinapatupad ng system ang lockdown.
Ang icon ng kandado ay iginuhit ng app, kaya pinatutunayan lamang nito na naniniwala ang app na konektado ito. Kung mawawalan ng access sa network ang ibang app, ang platform ang nagpapasya, kaya ang kapaki-pakinabang na pagsusuri ay panoorin ang app na iyon na pumapalya habang naka-on ang tunnel.
Ang label na „laging naka-on“ mula sa app store ay hindi rin pumapalit sa kontratang iyon. Ang laging naka-on at lockdown ay mga setting ng device, kadalasang inilalapat ng may-ari, at ang pag-uugali nito para sa mga ibinukod na app ay tinutukoy ng platform. Basahin ang setting, hindi ang badge.
Apat na tanong para sa pagsusuri ng disenyo
Una, sino ang pumayag: aling pakete, aling profile, at gumagamit ba o patakaran ng pinamamahalaang device? Ikalawa, ano ang hiningi ng app: aling mga ruta, aling mga pamilya ng address, aling mga app ang isinama o ibinukod? Ikatlo, ano ang nangyayari kapag hindi available ang tunnel: humaharang ba ang system o bumabalik ang trapiko sa pinagbabatayang network? Ikaapat, ano ang ginagawa ng app sa mga packet na natatanggap nito?
Ang ikaapat na tanong ang hindi kayang sagutin ng modelo ng permiso. Pinatutunayan ng pahintulot at interface ng TUN na maaaring tumanggap ng trapiko ang app, hindi na ine-encrypt nito ito, ina-authenticate ang kabilang panig o maayos na nakakabawi. Mga katangian iyon ng implementasyon, at doon ginugugol ng tapat na pagsusuri ang oras nito.
Ang hindi kailangang kahilingan ng root ay hindi nagiging lehitimo sa pagtawag sa resulta na kill switch, at ang dialog ng pahintulot ay hindi audit ng seguridad. Panatilihing hiwalay ang tatlong permiso at nagiging masusuri ang bawat pahayag.