chroot VPN на Android: защо тунелът работи, а приложенията го пренебрегват
chroot променя търсенето на пътища, а не ядрото, мрежовото пространство от имена или регистрацията на VPN в Android. Оттук следват два изхода и двата изненадват хората.
Инсталирате Linux дистрибуция в chroot на телефона, слагате VPN клиент вътре и шелът съобщава, че тунелът е готов. После отваряте браузър и трафикът излиза през мобилни данни, сякаш нищо не се е случило. Или обратното: всяко приложение губи връзка, защото клиентът е добавил маршрут по подразбиране в пространството от имена, което Android наистина използва. Тези два симптома идват от една липсваща част и нито един не е дефект на VPN клиента.
Шелът казва свързано, приложенията не са съгласни
Първият изход е обичайният. Тунел в потребителско пространство, отворен от chroot, може да завърши ръкостискането си, да отпечата статистиката си и да носи трафика, който същият шел генерира, докато приложенията на Android продължават да използват мрежата по подразбиране на телефона. Нищо не ги прихваща, защото нищо не е казало на Android, че съществува VPN.
Вторият изход е опасният. Ако chroot споделя мрежовото пространство от имена на Android, което е по подразбиране, процес с достатъчно права може да добави маршрути и TUN интерфейс, които засягат целия телефон. Тогава тунелът работи за всяко приложение, включително тези, които не сте възнамерявали да маршрутизирате, и връзката на телефона вече зависи от демон без управление на жизнения цикъл, без индикатор за връзка и без политика за постоянна активност.
Кой от двата изхода сте получили се отговаря с една команда. Сравнете ip route в chroot със същата команда от шел на Android отвън. Еднакъв изход означава, че chroot е в пространството от имена на хоста: всяка мрежова промяна, която прави, е за целия телефон. Различен изход означава, че стартерът е създал отделно пространство за него и тунелът му е невидим за Android по конструкция.
Какво промени chroot и какво не
| Object | Effect of a chroot |
|---|---|
| Pathname resolution | Changed: lookups start at the new root |
| Kernel and drivers | Unchanged: the phone's kernel, its TUN driver, its limits |
| Network namespace | Unchanged unless the launcher creates one |
| Android VPN registration | Unchanged: no app consented, no VPN is selected |
Системното извикване chroot прави едно нещо: променя директорията, използвана за търсене на пътища. Страницата на man изрично казва, че това не е граница за сигурност, и не казва нищо за интерфейси, маршрути или състояние на VPN. Всичко, което хората очакват от контейнер на Linux — отделен мрежов стек, филтрирана файлова система, ограничения на ресурсите — идва от други механизми, които стартерът може да е използвал или не.
Затова твърденията, че chroot изолира VPN, обикновено отговарят на грешния въпрос. Релевантният въпрос е в кое пространство от имена работи процесът и в кой домейн на 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. Ръководството за разработка на VPN в Android описва това ръкостискане и ключовият момент е, че то е регистрация, а не трик с маршрутизация.
Демон вътре в chroot никога не се регистрира. Няма диалог за съгласие, няма икона на ключ в лентата на състоянието, няма списък за включване или изключване по приложения и няма участие в политиката за постоянна активност. Затова приложенията продължават да използват мрежата по подразбиране и тунелът носи само това, което шелът сам изпраща.
Обратната посока също не помага. Избутването на маршрути в пространството от имена на хоста прихваща всичко, включително трафик, който платформата е очаквала да остане локален, и го прави без контрол по приложения и без начин потребителят да го види или отмени. Няма междинна настройка, при която демон в chroot маршрутизира трафик само за едно приложение.
Двоичната съвместимост е отделна стена
Дори когато мрежовата страна е интересна, изпълнимият файл има свои изисквания: архитектура на процесора, динамичен зареждач, библиотеката C и възможностите на ядрото, които очаква. Android използва bionic, а не glibc, и стар двоичен файл, компилиран за настолна дистрибуция, може да се нуждае от библиотеки, които вече не съществуват на устройството.
Свързването на име на библиотечен файл към по-нова версия не създава ABI съвместимост и архивирана криптографска библиотека от десетгодишен пакет не е поддържан компонент. Ако планът зависи от това, планът е да се изпълнява неподдържан код с мрежови права на телефон.
Докажете го в контекста на Android и почистете след себе си
Тествайте това, което наистина ви интересува, от страната, която има значение: отворете конкретното приложение, достигнете конкретната частна дестинация, потвърдете кой резолвер е отговорил, след което прекъснете тунела и потвърдете документираното поведение. Резултат от терминал в chroot е доказателство за контекста на изпълнение на този терминал и нищо повече.
Ако сте променили маршрути на хоста по време на експеримента, върнете ги и запишете какво сте променили. След това проверете дали телефонът има настроен VPN с постоянна активност, защото стар експеримент, оставил правило, може да изглежда като дефект на платформата месеци по-късно.
За реална нужда от отдалечен достъп използвайте поддържания клиент на услугата или одобрен дизайн на шлюз. Въпросът, който си струва да се зададе, не е дали инсталатор с root може да бъде накаран да работи, а дали поддържана реализация пренася нужните ви приложения през границата, която сте предвидили, без да оставя на устройството привилегировани промени без собственик.