Usmerjanje VPN na Androidu: pravila politike pred tabelo main
Android izbere usmerjevalno tabelo s pravili uid in oznak pred vsakim iskanjem cilja, zato pot, dodana v main, morda ne bo nikoli preverjena.
Pot, dodana v tabelo main na Androidu, je v vsakem seznamu videti pravilna in vseeno ne prenaša prometa. Razlog je, da je tabela main le ena od več možnosti in ni vprašana prva. Omrežna storitev Androida gradi pravila politike, ki izberejo usmerjevalno tabelo na podlagi podatkov, ki jih ciljni naslov ne vsebuje — uid aplikacije, oznaka na paketu, vmesnik, po katerem je prispel — iskanje cilja pa se zgodi pozneje, znotraj tabele, ki so jo izbrala ta pravila.
Tri odločitve v stalnem vrstnem redu
Odhodni paket sprejme tri ločene odločitve. Prvič, pravilo politike določi, katera usmerjevalna tabela velja. Drugič, pot v tej tabeli določi naslednji skok in izhodni vmesnik. Tretjič, kavlji netfilter odločijo, ali paket preživi, se spremeni ali preusmeri.
Vrstni red je pomemben, ker lahko vsaka stopnja odgovori le na svoje vprašanje. Pravilo požarnega zidu, ki paket sprejme, ne izbere tabele, pot, dodana v tabelo, ki je ne izbere nobeno pravilo, pa je neučinkovita. Velik del zmede okoli VPN-ov na Androidu izvira iz tega, da se popravi eno od treh in ne opazi nobene spremembe, ker je bila napaka v drugem.
| 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 |
Oznake so spakirano polje, ne nalepka, ki jo imate v lasti
Android spakira več dejstev v isto vrednost oznake: katero omrežje je bilo izbrano, ali je aplikacija omrežje izrecno izbrala, ali je vtičnica zaščitena pred VPN in biti, povezani z dovoljenji. Glava fwmark v AOSP določa to postavitev za trenutno drevo, postavitev pa je notranja podrobnost platforme, ki se med izdajami spreminja.
Zato je na Androidu nevarno zapisati celo vrednost oznake z iptables -j MARK --set-mark. To ne doda oznake; nadomesti izbiro omrežja, ki jo je sistem že opravil. Paket se nato ujema z drugimi pravili, kar je lahko videti, kot da je VPN začel delovati, ali kot da je nepovezana aplikacija izgubila povezljivost, odvisno od tega, kateri biti so bili prepisani.
Če se morate oznak dotakniti, najprej preberite trenutno vrednost in uporabite masko, da se spremenijo le biti, ki jih razumete:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11Oznaka povezave je ločen objekt od oznake paketa in nobena ni pot. Obnavljanje oznake na odgovornih paketih je ločen korak od izbire tabele na izhodu, zato enosmerni popravki ustvarijo povezave, ki se odprejo in nato obesijo.
Kdo ima v lasti pravila in tabele
Omrežna storitev Androida, netd, ustvari pravila in tabele za posamezno omrežje. AOSP RouteController je mesto, kjer se ta pravila sestavijo za VPN-e, fizična omrežja in obsege uid, njegov življenjski cikel pa je vezan na omrežne dogodke in ne na konfiguracijsko datoteko.
Sledita dve posledici. Prvič, prioritete in številke tabel, ki jih najdete na eni napravi, so notranjosti gradnje, ne vmesnik: enako videti številke na drugi različici Androida lahko pomenijo nekaj povsem drugega. Drugič, stanje se ob spremembi omrežij znova zgradi, zato pravilo, vstavljeno danes iz lupine root, lahko po naslednjem preklopu Wi-Fi izgine.
To izginotje se pogosto prijavi kot to, da sistem ignorira pot. V resnici je prenehalo obstajati pravilo, ki je izbralo tabelo, pot znotraj tabele pa je zdaj s stališča paketa nedosegljiva. Preverite seznam pravil, ne seznama poti, ko delujoča konfiguracija po ponovni povezavi preneha delovati.
Vprašanja o vrstnem redu kavljev nimajo splošnega odgovora
Na vprašanje, ali iptables teče pred usmerjanjem VPN, ni mogoče odgovoriti brez poimenovanja poti paketa. Lokalno ustvarjen paket gre skozi kavelj output, kjer sprememba oznake sproži preverjanje ponovnega usmerjanja — drugo iskanje, ne naknadno urejanje prvega. Paket, ki prispe od odjemalca prek tetheringa, gre po poti prerouting in se namesto tega posreduje naprej, verige, ki ga vidijo, pa so druge.
Ista regula je torej lahko učinkovita za promet aplikacije in nevidna za promet prek tetheringa, števec, ki ostane na ničli, pa vam pove, katero pot je paket ubral, ne ali je pravilo napačno. S števci ugotovite pot, preden spremenite kateri koli pogoj ujemanja.
To je tudi stopnja, na kateri napaka usmerjanja po politiki postane težko vidna. Usmerjanje v tabelo, ki obstaja, a ne vsebuje cilja, ustvari omrežje nedosegljivo, kar je videti kot zavrženje požarnega zidu, medtem ko zavrženje požarnega zidu ustvari časovno prekoračitev, ki je videti kot usmerjevalna črna luknja.
Diagnosticirajte znotraj sistema ali ga pustite pri miru
Za pooblaščen pregled pred dotikom česarkoli ugotovite štiri dejstva: uid in profil aplikacije, omrežje, ki ga je Android izbral zanjo, ali VPN to aplikacijo sploh vključuje, in ali težava obstaja za obe družini naslovov. Izključitev po aplikaciji pojasni zelo veliko poročil VPN ne deluje brez kakršne koli usmerjevalne napake.
Nato preberite pravila, maske in tabele, ki resnično veljajo, in zadržite preklop omrežja znotraj opazovalnega okna. Če se vedenje med ponovno povezavo spremeni, gledate upravljani življenjski cikel, ne manjkajočo pot.
Za običajne zahteve uporabite podprte kontrolnike: vključitev in izključitev po aplikaciji v aplikaciji VPN in lastno izbiro omrežja platforme za vse, kar potrebuje določeno pot. Če mora privilegirana integracija res sodelovati z usmerjevalnim strojem, ciljajte na izvedbo točno tiste različice Androida, ki jo podpirate, in vzdržujte njen življenjski cikel prek komponente, ki ji je lastnik. Izpraznitev verig platforme ali vstavitev pravila z visoko prioriteto spremeni diagnozo v drugega upravitelja omrežja in telefon se bo obnašal temu primerno.