Маршрутизиране на VPN в Android: правила за политика преди таблицата main

Маршрут, добавен в таблицата main на Android, изглежда правилен във всяко изброяване и въпреки това не пренася трафика. Причината е, че таблицата main е само една от няколко възможности и към нея не се обръщаме първо. Мрежовата услуга на Android изгражда правила за политика, които избират таблица за маршрутизиране чрез информация, която адресът на местоназначението не съдържа — uid на приложението, маркировка върху пакета, интерфейса, по който е пристигнал — а търсенето на местоназначението се случва след това, вътре в таблицата, която тези правила са избрали.

Три решения в фиксиран ред

Пакетът на изход прави три отделни решения. Първо, правило за политика решава коя таблица за маршрутизиране се прилага. Второ, маршрут в тази таблица решава следващия хоп и изходящия интерфейс. Трето, куките на netfilter решават дали пакетът оцелява, бива променен или пренасочен.

Редът има значение, защото всеки етап може да отговори само на собствения си въпрос. Правило на защитна стена, което приема пакет, не избира таблица, а маршрут, добавен в таблица, която никое правило не избира, е инертен. Голяма част от объркването около VPN на Android идва от поправяне на едно от трите и наблюдение на липса на промяна, защото повредата е била в друго.

Маркировките са опаковано поле, а не етикет, който притежавате

Android опакова няколко факта в една и съща стойност на маркировка: коя мрежа е избрана, дали приложение изрично е избрало мрежа, дали сокет е защитен от VPN и битове, свързани с разрешения. Заглавката fwmark в AOSP дефинира това разположение за текущото дърво и разположението е вътрешна за платформата подробност, която се променя между изданията.

Ето защо записването на цяла стойност на маркировка с iptables -j MARK --set-mark е опасно на Android. То не добавя етикет; то заменя избора на мрежа, който системата вече е направила. След това пакетът съвпада с други правила и това може да изглежда като че VPN е започнал да работи или като че несвързано приложение е загубило връзка, в зависимост от това кои битове са били презаписани.

Ако все пак трябва да пипате маркировки, първо прочетете текущата стойност и използвайте маска, така че да се променят само битовете, които разбирате:

ip rule show
ip route show table all | head -40
ip route get 10.20.4.11

Маркировката на връзка е отделен обект от маркировката на пакет и нито една от двете не е маршрут. Възстановяването на маркировката върху ответните пакети е отделна стъпка от избора на таблица на изхода, затова еднопосочните поправки дават връзки, които се отварят и след това увисват.

Кой притежава правилата и таблиците

Мрежовата услуга на Android, netd, създава правилата и таблиците за всяка мрежа. AOSP RouteController е мястото, където тези правила се сглобяват за VPN, физически мрежи и диапазони от uid, и жизненият му цикъл е обвързан с мрежови събития, а не с конфигурационен файл.

Следват две последствия. Първо, приоритетите и номерата на таблици, които намирате на един телефон, са вътрешни за компилацията детайли, а не интерфейс: еднакво изглеждащи номера на друга версия на Android може да означават нещо съвсем различно. Второ, състоянието се изгражда наново при промяна на мрежите, затова правило, вмъкнато днес от root shell, може да изчезне след следващия преход на Wi-Fi.

Това изчезване често се докладва като че системата пренебрегва маршрут. Всъщност правилото, което е избирало таблицата, вече не съществува и маршрутът в таблицата е недостижим от гледна точка на пакета. Проверявайте списъка с правила, а не списъка с маршрути, когато работеща конфигурация спре да работи след повторно свързване.

Въпросите за реда на куките нямат универсален отговор

Въпросът дали iptables работи преди маршрутизирането на VPN не може да получи отговор, без да се назове пътят на пакета. Локално генериран пакет преминава през куката output, където промяната на маркировка задейства проверка за повторно маршрутизиране — второ търсене, а не ретроактивна редакция на първото. Пакет, пристигащ от клиент през tethering, преминава по пътя prerouting и вместо това се препраща, а веригите, които го виждат, са други.

Така едно и също правило може да е ефективно за трафика на приложение и невидимо за трафика през tethering, а брояч, който остава на нула, ви казва кой път е поел пакетът, а не дали правилото е грешно. Използвайте броячи, за да установите пътя, преди да промените каквото и да е условие за съвпадение.

Това е и етапът, на който грешка в маршрутизирането по политика става трудно видима. Маршрутизиране към таблица, която съществува, но не съдържа местоназначението, произвежда мрежа недостъпна, което прилича на отхвърляне от защитна стена, докато отхвърлянето от защитна стена произвежда изчакване, което прилича на маршрутна черна дупка.

Диагностицирайте вътре в системата или я оставете на мира

За оторизиран преглед установете четири факта, преди да пипате нещо: uid и профила на приложението, мрежата, която Android е избрал за него, дали VPN изобщо включва това приложение и дали проблемът съществува за двете семейства адреси. Изключването на отделно приложение обяснява много доклади от вида VPN не работи без никаква маршрутна повреда.

След това прочетете правилата, маските и таблиците, които действително са в сила, и задръжте превключване на мрежата в прозореца на наблюдение. Ако поведението се промени при повторно свързване, виждате управляван жизнен цикъл, а не липсващ маршрут.

За обичайни изисквания използвайте поддържаните контроли: включване и изключване на отделни приложения в приложението VPN и собствения избор на мрежа на платформата за всичко, което се нуждае от конкретен път. Ако привилегирована интеграция наистина трябва да си сътрудничи с маршрутизиращата машина, насочете се към реализацията на точната версия на Android, която поддържате, и поддържайте жизнения й цикъл чрез компонента, който я притежава. Изчистването на платформени вериги или вмъкването на правило с висок приоритет превръща диагнозата във втори мрежов мениджър и телефонът ще се държи съответно.