Насочување на 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, каде промената на ознака предизвикува проверка за повторно насочување — второ пребарување, а не ретроактивно уредување на првото. Пакет што доаѓа од tether клиент поминува по патеката prerouting и наместо тоа се препраќа, а ланците што го гледаат се други.

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

Ова е и фазата во која грешката во насочувањето по политика станува тешко видлива. Насочување кон табела што постои но не го содржи одредиштето дава мрежа недостапна што изгледа како отфрлање од огнен ѕид, додека отфрлањето од огнен ѕид дава истекување на времето што изгледа како црна дупка во насочувањето.

Дијагностицирајте внатре во системот или оставете го на мира

За авторизиран преглед, утврдете четири факти пред да допрете нешто: uid и профилот на апликацијата, мрежата што Android ја избрал за неа, дали VPN воопшто ја вклучува таа апликација, и дали проблемот постои за двете фамилии адреси. Исклучувањето по апликација објаснува многу извештаи од типот VPN не работи без никаков дефект во насочувањето.

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

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