Android chroot VPN: зашто тунел ради, а апликације га игноришу

Покренете Linux дистрибуцију под chroot-ом на телефону, инсталирате VPN клијент у њој, и shell објави да је тунел спреман. Затим пређете на прегледач и саобраћај излази преко мобилних података као да се ништа није догодило. Или обрнуто: свака апликација на телефону изгуби везу јер је клијент поставио подразумевану руту у namespace који Android заиста користи. Оба симптома долазе из истог дела који недостаје, и ниједан није грешка у VPN клијенту.

Shell каже повезано, апликације се не слажу

Први исход је уобичајен. Тунел у корисничком простору отворен из chroot-а може завршити руковање, исписати статистику и преносити саобраћај који ствара исти shell, док Android апликације настављају да користе подразумевану мрежу телефона. Ништа их не пресреће, јер ништа није рекло Android-у да VPN постоји.

Други исход је опасан. Ако chroot дели мрежни namespace Android-а, што по default-у чини, процес са довољно привилегија може додати руте и TUN интерфејс који утичу на цео телефон. Тада тунел ради за сваку апликацију, укључујући оне које нисте намеравали да рутујете, а веза телефона сада зависи од демона без управљања животним циклусом, без индикатора везе и без политике сталног укључивања.

Који од два случаја имате може се утврдити једном командом. Упоредите ip route унутар chroot-а са истом командом из Android shell-а споља. Идентичан излаз значи да је chroot у namespace-у хоста: свака мрежна промена коју направи важи за цео телефон. Различит излаз значи да је launcher направио namespace за њега, и његов тунел је Android-у невидљив по конструкцији.

Шта је chroot променио, а шта није

Системски позив chroot ради једну ствар: мења директоријум који се користи за разрешавање имена путања. Man страница изричито каже да то није безбедносна граница и не говори ништа о интерфејсима, рутама или стању VPN-а. Све што људи очекују од Linux контејнера — приватни мрежни стек, филтрирани фајл систем, ограничења ресурса — долази из других механизама које је launcher можда или није користио.

Зато тврдње да chroot изолује VPN обично одговарају на погрешно питање. Релевантно питање је у ком namespace-у процес ради и на који SELinux домен је ограничен, а оба су особине начина на који је покренут, не речи chroot.

TUN тражи три ствари, а чвор уређаја је само једна

Традиционални тунел у корисничком простору тражи TUN уређај који може отворити, подршку кернела за тај уређај и дозволу за конфигурисање интерфејса и рута. То су одвојени захтеви, а прављење имена путање под /dev само по себи не испуњава ниједан од њих:

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

На Android-у кернел обично има уграђену TUN подршку, јер је користи сопствена VPN услуга платформе, али то не значи да ваш процес сме да је користи. Конфигурација интерфејса тражи способност мрежне администрације, а SELinux одлучује да ли процес уопште може да дође до чвора уређаја. Одбијање изгледа као грешка дозволе без очигледног узрока, а одговор је у ревизијском трагу:

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

Root ово не решава. SELinux ограничава процесе који раде као uid 0 исто као и остале, па chroot покренут из root shell-а и даље може бити одбијен за уређај који види. Искључивање примене ради рада старог инсталатера је одлука за цео телефон са последицама далеко изван тунела и није поправка застарелог бинарног фајла.

Зашто Android апликације игноришу ваш тунел

Подржани модел Android-а је VPN апликација која се региструје преко VPN услуге платформе, једном тражи сагласност корисника и добија фајл дескриптор за свој тунел. Платформа затим усмерава саобраћај у тај дескриптор и примењује опсег апликација који је изабрао корисник или администратор, зато исти механизам може бити по апликацији, по профилу и комбинован са поставкама сталног укључивања и блокирања без VPN-а. Android водич за развој VPN-а описује то руковање, а кључно је да је то регистрација, а не трик са рутирањем.

Демон унутар chroot-а се никада не региструје. Нема дијалога сагласности, нема иконе кључа у статусној траци, нема листе укључивања или искључивања по апликацији и нема учешћа у политици сталног укључивања. Зато апликације настављају да користе подразумевану мрежу, а тунел преноси само оно што shell сам пошаље.

Ни одлазак у другу крајност не помаже. Гурање рута у namespace хоста хвата све, укључујући саобраћај који је платформа очекивала да остане локални, и то без контроле по апликацији и без начина да корисник то види или опозове. Нема средње поставке у којој chroot демон рутира саобраћај само за једну апликацију.

Бинарна компатибилност је посебан зид

Чак и када је мрежна страна занимљива, извршни фајл има своје захтеве: архитектуру процесора, динамички loader, C библиотеку и могућности кернела које очекује. Android користи bionic уместо glibc, а стари бинарни фајл изграђен за desktop дистрибуцију може тражити библиотеке којих више нема на уређају.

Симболичко повезивање имена библиотеке са новијом верзијом не ствара ABI компатибилност, а архивирана криптографска библиотека из пакета старог деценију није одржавана компонента. Ако план зависи од тога, план је покретати неодржаван код са мрежним привилегијама на телефону.

Докажите то у Android контексту и очистите за собом

Тестирајте оно што вам је заиста важно, са стране која је важна: отворите конкретну апликацију, стигните до конкретног приватног одредишта, потврдите који је resolver одговорио, затим искључите тунел и потврдите документовано понашање. Резултат из терминала унутар chroot-а је доказ само о контексту извршавања тог терминала и ништа више.

Ако сте током експеримената мењали руте хоста, вратите их и запишите шта сте променили. Затим проверите да ли телефон има конфигурисан VPN са сталним укључивањем, јер стари експеримент који је оставио правило може изгледати као квар платформе месецима касније.

За стварну потребу за даљинским приступом користите подржани клијент услуге или одобрен дизајн гејтвеја. Питање које вреди поставити није да ли се root инсталатер може покренути, већ да ли подржана имплементација преноси потребне апликације преко границе коју сте намеравали, без остављања привилегованих измена без власника на уређају.