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

Добивате Linux дистрибуција што работи под chroot на телефонот, инсталирате VPN клиент во неа, и школката објавува дека тунелот е завршен. Потоа префрлате на прелистувач и сообраќајот излегува преку мобилни податоци како ништо да не се случило. Или обратно: секоја апликација на телефонот губи поврзаност затоа што клиентот поставил стандардна рута во namespace-от што Android всушност го користи. Овие два симптома доаѓаат од истиот дел што недостасува, и ниту еден не е грешка во VPN клиентот.

Школката вели поврзано, апликациите не се согласуваат

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

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

Кој од двата го добивте може да се утврди со една команда. Споредете ip route внатре во chroot со истата команда од Android школка надвор од неа. Идентичен излез значи дека chroot е во namespace-от на домаќинот: секоја мрежна промена што ја прави важи за целиот телефон. Различен излез значи дека стартувачот создал namespace за него, и неговиот тунел е невидлив за Android по самата своја конструкција.

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

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

Затоа тврдењата дека 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 школка сепак може да биде одбиен за уред што го гледа. Исклучувањето на спроведувањето за да работи стар инсталер е одлука за целиот телефон со последици далеку надвор од тунелот и не е поправка за застарен бинарен файл.

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

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

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

Ниту одењето во спротивна насока не помага. Туркањето рути во namespace-от на домаќинот фаќа сè, вклучително сообраќајот што платформата очекуваше да остане локален, и тоа без контрола по апликација и без начин корисникот да го види или отповика. Нема средно поставување каде chroot демон рутира сообраќај само за една апликација.

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

Дури и кога мрежната страна е интересна, извршната датотека има свои барања: CPU архитектура, динамичен вчитувач, C библиотека и можности на јадрото што ги очекува. Android користи bionic наместо glibc, а стар бинарен файл изграден за десктоп дистрибуција може да бара библиотеки што веќе не постојат на уредот.

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

Докажете го во контекст на Android и исчистете потоа

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

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

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