Андроид VPN рутирање: правила политике пре табеле main
Андроид бира табелу рутирања правилима uid и ознака пре сваке претраге одредишта, па рута додата у main можда никада неће бити проверена.
Рута додата у табелу main на Андроиду изгледа исправно у сваком списку и ипак не преноси саобраћај. Разлог је што је табела main само једна од неколико опција и не пита се прва. Андроидова мрежна служба гради правила политике која бирају табелу рутирања помоћу података којих нема у адреси одредишта — uid апликације, ознака на пакету, интерфејс на који је стигао — а тражење одредишта се дешава после, унутар оне табеле коју су та правила изабрала.
Три одлуке у утврђеном реду
Пакет на излазу доноси три одвојене одлуке. Прво, правило политике одређује која табела рутирања важи. Друго, рута унутар те табеле одређује следећи скок и излазни интерфејс. Треће, netfilter куке одређују да ли пакет преживљава, бива измењен или преусмерен.
Ред је важан јер свака фаза може да одговори само на своје питање. Правило заштитног зида које прихвата пакет не бира табелу, а рута додата у табелу коју ниједно правило не бира је без дејства. Велики део забуне око Android VPN-ова долази од тога што се поправи једна од три ствари и не види промена, јер је квар био у другој.
| Stage | Selector | What it cannot decide |
|---|---|---|
| Policy rule | uid range, mark, incoming interface | Which route exists inside the table |
| Route lookup | Destination prefix, longest match | Whether the packet is allowed out |
| Netfilter hook | Chain position, match conditions | Which table was selected |
Ознаке су спаковано поље, а не етикета коју поседујете
Андроид пакује неколико чињеница у исту вредност ознаке: која је мрежа изабрана, да ли је апликација изричито изабрала мрежу, да ли је сокет заштићен од VPN-а и битови везани за дозволе. AOSP fwmark заглавље дефинише тај распоред за тренутно стабло, а распоред је унутрашњост платформе која се мења између издања.
Зато је писање целе вредности ознаке помоћу iptables -j MARK --set-mark опасно на Андроиду. Оно не додаје ознаку; оно замењује избор мреже који је систем већ направио. Пакет се затим поклапа са другим правилима, што може изгледати као да је VPN почео да ради или као да је неповезана апликација изгубила везу, зависно од тога који су битови преписивани.
Ако морате да дирате ознаке, прво прочитајте тренутну вредност и користите маску тако да се мењају само битови које разумете:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11Ознака везе је одвојен објекат од ознаке пакета и ниједна није рута. Враћање ознаке на одговорним пакетима је посебан корак од бирања табеле на излазу, зато једносмерна решења дају везе које се отворе и онда се закаче.
Ко поседује правила и табеле
Андроидова мрежна служба, netd, ствара правила и табеле по мрежи. AOSP RouteController је место где се та правила састављају за VPN-ове, физичке мреже и uid опсеге, а његов животни циклус је везан за мрежне догађаје, а не за конфигурациону датотеку.
Следе две последице. Прво, приоритети и бројеви табела које нађете на једном телефону су унутрашњост билда, а не интерфејс: исто означени бројеви на другој Андроид верзији могу значити нешто сасвим друго. Друго, стање се поново гради када се мреже промене, па правило уметнуто данас из root shell-а може нестати након следећег Wi-Fi прелаза.
То нестајање се често пријављује као да систем игнорише руту. Стварно се догодило то да правило које је бирало табелу више не постоји, а рута унутар табеле је сада недоступна из перспективе пакета. Проверите листу правила, а не листу рута, када радна конфигурација престане да ради након поновног повезивања.
Питања о реду кука немају универзалан одговор
Питање да ли iptables ради пре VPN рутирања не може се одговорити без именовања путање пакета. Локално генерисан пакет пролази кроз output куку, где промена ознаке покреће проверу поновног рутирања — друга претрага, а не ретроактивно уређивање прве. Пакет који долази од tethered клијента пролази кроз prerouting путању и уместо тога се прослеђује, а ланци који га виде су другачији.
Зато исто правило може бити ефикасно за саобраћај апликације и невидљиво за tethered саобраћај, а бројач који остаје на нули говори вам коју је путању пакет прешао, а не да ли је правило погрешно. Користите бројаче да утврдите путању пре него што промените било који услов подударања.
Ово је и фаза у којој грешка рутирања политике постаје тешко видљива. Рутирање у табелу која постоји али не садржи одредиште производи мрежу недоступну која изгледа као firewall drop, док firewall drop производи тајмаут који изгледа као рутирајућа црна рупа.
Дијагностикујте унутар система или га оставите на миру
За ауторизовани преглед, утврдите четири чињенице пре него што било шта дирнете: uid и профил апликације, мрежу коју је Андроид изабрао за њу, да ли VPN уопште укључује ту апликацију и да ли проблем постоји за обе адресне породице. Изузетак по апликацији објашњава многе пријаве VPN не ради без икаквог квара у рутирању.
Затим прочитајте правила, маске и табеле које су стварно на снази и држите промену мреже унутар прозора посматрања. Ако се понашање промени кроз поновно повезивање, гледате у управљани животни циклус, а не у руту која недостаје.
За обичне захтеве користите подржане контроле: укључивање и искључивање по апликацији у VPN апликацији и властити избор мреже платформе за све што треба одређену путању. Ако привилегована интеграција заиста мора да сарађује с машинеријом рутирања, циљајте имплементацију тачне Андроид верзије коју подржавате и одржавајте њен животни циклус кроз компоненту која је поседује. Брисање платформских ланаца или уметање правила високог приоритета претвара дијагнозу у други мрежни менаџер и телефон ће се понашати у складу с тим.