VPN en chroot sur Android: kial la tunelo funkcias kaj la aplikaĵoj ignoras ĝin

Vi instalas Linux-distribuon funkciantan en chroot sur la telefono, instalas VPN-klienton ene, kaj la ŝelo anoncas pretan tunelon. Poste vi transiras al retumilo kaj la trafiko eliras per la movebla datumaro, kvazaŭ nenio okazis. Aŭ la malo: ĉiu aplikaĵo sur la telefono perdas la konekton, ĉar la kliento aldonis defaŭltan vojon en la nomspacon, kiun Android vere uzas. Tiuj du simptomoj venas de la sama mankanta peco, kaj neniu el ili estas miso de la VPN-kliento.

La ŝelo diras konektite, la aplikaĵoj malkonsentas

La unua rezulto estas la ordinara. Uzantspaca tunelo malfermita el chroot povas fini sian manpremon, presi siajn statistikojn kaj porti trafikon, kiun generas la sama ŝelo, dum la aplikaĵoj de Android daŭre uzas la defaŭltan reton de la telefono. Nenio interkaptas ilin, ĉar nenio diris al Android, ke ekzistas VPN.

La dua rezulto estas la danĝera. Se la chroot dividas la retan nomspacon de Android, kio estas la defaŭlto, procezo kun sufiĉaj privilegioj povas aldoni vojojn kaj TUN-interfacon, kiuj efikas al la tuta telefono. Tiam la tunelo funkcias por ĉiu aplikaĵo, inkluzive de tiuj, kiujn vi ne intencis enkursigi, kaj la konektebleco de la telefono nun dependas de demono sen vivcikla administrado, sen konekta indikilo kaj sen ĉiam-ena politiko.

Kiun el la du rezultoj vi ricevis, eblas respondi per unu komando. Komparu ip route ene de la chroot kun la sama komando el Android-ŝelo ekstere. Identa eligo signifas, ke la chroot estas en la nomspaco de la gastiganto: ĉiu reta ŝanĝo, kiun ĝi faras, validas por la tuta telefono. Malsama eligo signifas, ke la lanĉilo kreis nomspacon por ĝi, kaj ĝia tunelo estas laŭkonstrue nevidebla al Android.

Kion chroot ŝanĝis kaj kion ne

La sistema voko chroot faras unu aferon: ĝi ŝanĝas la dosierujon uzatan por voja distingo. La man-paĝo klare diras, ke ĝi ne estas sekureca limo, kaj diras nenion pri interfacoj, vojoj aŭ VPN-stato. Ĉio, kion homoj atendas de Linux-kontenero — privata reta stako, filtrita dosiersistemo, rimedaj limoj — venas de aliaj mekanismoj, kiujn la lanĉilo eble uzis aŭ ne.

Tial asertoj, ke chroot izolas VPN, kutime respondas la malĝustan demandon. La grava demando estas, en kiu nomspaco la procezo funkcias kaj al kiu SELinux-domajno ĝi estas limigita, kaj ambaŭ estas ecoj de tio, kiel ĝi estis lanĉita, ne de la vorto chroot.

TUN bezonas tri aferojn, kaj aparata nodo estas nur unu

Tradicia uzantspaca tunelo bezonas TUN-aparaton, kiun ĝi povas malfermi, kernan subtenon por tiu aparato, kaj permeson agordi la interfacon kaj la vojojn. Tiuj estas apartaj postuloj, kaj krei vojnomojn sub /dev plenumas neniun el ili sole:

ls -l /dev/net/tun
ip tuntap add dev tun0 mode tun

Sur Android la TUN-subteno kutime estas enkompilita en la kernon, ĉar la propra VPN-servo de la platformo uzas ĝin, sed tio ne signifas, ke via procezo rajtas uzi ĝin. Interfaca agordo bezonas la retadministran kapablon, kaj SELinux decidas, ĉu la procezo entute povas atingi la aparatan nodon. Rifuzo aspektas kiel permesa eraro sen evidenta kaŭzo, kaj la respondo estas en la revizia spuro:

dmesg | grep avc
logcat -d | grep "avc: denied"

Root ne solvas tion. SELinux limigas procezojn kun uid 0 same kiel la aliajn, do chroot lanĉita el root-ŝelo povas ankoraŭ esti rifuzita pri aparato, kiun ĝi vidas. Malŝalti la plenumadon por ke malnova instalilo funkciu estas decido por la tuta telefono kun sekvoj multe preter la tunelo, kaj ĝi ne estas riparo por eksdata dunuma dosiero.

Kial Android-aplikaĵoj ignoras vian tunelon

La subtenata modelo de Android estas VPN-aplikaĵo, kiu registriĝas per la VPN-servo de la platformo, petas unufoje konsenton de la uzanto kaj ricevas dosierpriskribilon por sia tunelo. Poste la platformo enkursigas trafikon en tiun priskribilon kaj plenumas la aplikaĵan amplekson, kiun elektis la uzanto aŭ administranto, tial la sama mekanismo povas esti po-aplikaĵe, po-profila kaj kombinita kun ĉiam-ena kaj blokado sen VPN. La Android-VPN-evoluiga gvidilo priskribas tiun manpremon, kaj la ŝlosila punkto estas, ke ĝi estas registrado, ne enkursiga artifiko.

Demono ene de chroot neniam registriĝas. Mankas konsenta dialogo, ŝlosila piktogramo en la stata breto, inkluda aŭ ekskluda listo po aplikaĵo, kaj partopreno en la ĉiam-ena politiko. Tial aplikaĵoj daŭre uzas la defaŭltan reton, kaj la tunelo portas nur tion, kion la ŝelo mem sendas.

Ankaŭ la mala direkto ne helpas. Puŝi vojojn en la nomspacon de la gastiganto kaptas ĉion, inkluzive trafikon, kiun la platformo atendis resti loka, kaj faras tion sen po-aplikaĵa kontrolo kaj sen maniero por la uzanto vidi aŭ revoki ĝin. Mankas meza agordo, kie demono en chroot enkursigas trafikon por nur unu aplikaĵo.

Dunuma kongrueco estas aparta muro

Eĉ kiam la reta flanko interesas, la plenumebla dosiero havas siajn postulojn: CPU-arkitekturon, la dinamikan ŝarĝilon, la C-bibliotekon kaj la kernajn kapablojn, kiujn ĝi atendas. Android uzas bionic anstataŭ glibc, kaj malnova dunuma dosiero konstruita por surtabla distribuo povas bezoni bibliotekojn, kiuj ne plu ekzistas sur la aparato.

Ligi bibliotekan dosiernomon al pli nova versio ne kreas ABI-kongruecon, kaj arkivita kriptografia biblioteko el dekjara pakaĵo ne estas prizorgata komponanto. Se la plano dependas de tio, la plano estas ruli neprizorgatan kodon kun retaj privilegioj sur telefono.

Pruvu ĝin en la Android-kunteksto kaj poste purigu

Testu tion, kio vere gravas al vi, de la flanko, kiu gravas: malfermu la konkretan aplikaĵon, atingi la konkretan privatan celon, konfirmu, kiu solvilo respondis, poste malkonektu la tunelon kaj konfirmu la dokumentitan konduton. Rezulto el terminalo ene de chroot estas pruvo pri la plenumkunteksto de tiu terminalo kaj nenio pli.

Se vi ŝanĝis gastigantajn vojojn dum la eksperimento, restarigu ilin kaj notu, kion vi ŝanĝis. Poste kontrolu, ĉu la telefono havas agorditan ĉiam-enan VPN, ĉar malnova eksperimento, kiu lasis regulon, povas aspekti kiel platforma misfunkcio monatojn poste.

Por reala bezono de fora aliro, uzu la subtenatan klienton de la servo aŭ aprobitan pordegan dezajnon. La demando inda je demando estas ne, ĉu root-instalilo povas esti igita funkcii, sed ĉu subtenata efektivigo portas la aplikaĵojn, kiujn vi bezonas, trans la limon, kiun vi intencis, sen lasi senposedajn privilegiajn ŝanĝojn sur la aparato.