Android VPN rutiranje: pravila politike pre tabele main

Ruta dodata u tabelu main na Androidu izgleda ispravno u svakom spisku i ipak ne prenosi saobraćaj. Razlog je što je tabela main samo jedna od nekoliko opcija i ne pita se prva. Androidova mrežna služba gradi pravila politike koja biraju tabelu rutiranja pomoću podataka kojih nema u adresi odredišta — uid aplikacije, oznaka na paketu, interfejs na koji je stigao — a traženje odredišta se dešava posle, unutar one tabele koju su ta pravila izabrala.

Tri odluke u utvrđenom redu

Paket na izlazu donosi tri odvojene odluke. Prvo, pravilo politike određuje koja tabela rutiranja važi. Drugo, ruta unutar te tabele određuje sledeći skok i izlazni interfejs. Treće, netfilter kuke određuju da li paket preživljava, biva izmenjen ili preusmeren.

Red je važan jer svaka faza može da odgovori samo na svoje pitanje. Pravilo firewall-a koje prihvata paket ne bira tabelu, a ruta dodata u tabelu koju nijedno pravilo ne bira je bez dejstva. Veliki deo zabune oko Android VPN-ova dolazi od toga što se popravi jedna od tri stvari i ne vidi promena, jer je kvar bio u drugoj.

Oznake su spakovano polje, a ne etiketa koju posedujete

Android pakuje nekoliko činjenica u istu vrednost oznake: koja je mreža izabrana, da li je aplikacija izričito izabrala mrežu, da li je socket zaštićen od VPN-a i bitovi vezani za dozvole. AOSP fwmark zaglavlje definiše taj raspored za trenutno stablo, a raspored je unutrašnjost platforme koja se menja između izdanja.

Zato je pisanje cele vrednosti oznake pomoću iptables -j MARK --set-mark opasno na Androidu. Ono ne dodaje oznaku; ono zamenjuje izbor mreže koji je sistem već napravio. Paket se zatim poklapa sa drugim pravilima, što može izgledati kao da je VPN počeo da radi ili kao da je nepovezana aplikacija izgubila vezu, zavisno od toga koji su bitovi prepisani.

Ako morate da dirate oznake, prvo pročitajte trenutnu vrednost i koristite masku tako da se menjaju samo bitovi koje razumete:

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

Oznaka veze je odvojen objekat od oznake paketa i nijedna nije ruta. Vraćanje oznake na odgovorne pakete je poseban korak od biranja tabele na izlazu, zato jednosmerna rešenja daju veze koje se otvore i onda se zakače.

Ko poseduje pravila i tabele

Androidova mrežna služba, netd, stvara pravila i tabele po mreži. AOSP RouteController je mesto gde se ta pravila sastavljaju za VPN-ove, fizičke mreže i uid opsege, a njegov životni ciklus je vezan za mrežne događaje, a ne za konfiguracionu datoteku.

Slede dve posledice. Prvo, prioriteti i brojevi tabela koje nađete na jednom telefonu su unutrašnjost builda, a ne interfejs: isto označeni brojevi na drugoj Android verziji mogu značiti nešto sasvim drugo. Drugo, stanje se ponovo gradi kada se mreže promene, pa pravilo umetnuto danas iz root shell-a može nestati nakon sledećeg Wi-Fi prelaza.

To nestajanje se često prijavljuje kao da sistem ignoriše rutu. Stvarno se dogodilo to da pravilo koje je biralo tabelu više ne postoji, a ruta unutar tabele je sada nedostupna iz perspektive paketa. Proverite listu pravila, a ne listu ruta, kada radna konfiguracija prestane da radi nakon ponovnog povezivanja.

Pitanja o redu kuka nemaju univerzalni odgovor

Pitanje da li iptables radi pre VPN rutiranja ne može se odgovoriti bez imenovanja putanje paketa. Lokalno generisan paket prolazi kroz output kuku, gde promena oznake pokreće proveru ponovnog rutiranja — druga pretraga, a ne retroaktivno uređivanje prve. Paket koji dolazi od tethered klijenta prolazi kroz prerouting putanju i umesto toga se prosleđuje, a lanci koji ga vide su drugačiji.

Zato isto pravilo može biti efikasno za saobraćaj aplikacije i nevidljivo za tethered saobraćaj, a brojač koji ostaje na nuli govori vam koju je putanju paket prešao, a ne da li je pravilo pogrešno. Koristite brojače da utvrdite putanju pre nego što promenite bilo koji uslov podudaranja.

Ovo je i faza u kojoj greška rutiranja politike postaje teško vidljiva. Rutiranje u tabelu koja postoji ali ne sadrži odredište proizvodi mrežu nedostupnu koja izgleda kao firewall drop, dok firewall drop proizvodi tajmaut koji izgleda kao rutirajuća crna rupa.

Dijagnostikujte unutar sistema ili ga ostavite na miru

Za autorizovani pregled, utvrdite četiri činjenice pre nego što bilo šta dirnete: uid i profil aplikacije, mrežu koju je Android izabrao za nju, da li VPN uopšte uključuje tu aplikaciju i da li problem postoji za obe adresne porodice. Izuzetak po aplikaciji objašnjava mnoge prijave VPN ne radi bez ikakvog kvara u rutiranju.

Zatim pročitajte pravila, maske i tabele koje su stvarno na snazi i držite promenu mreže unutar prozora posmatranja. Ako se ponašanje promeni kroz ponovno povezivanje, gledate u upravljani životni ciklus, a ne u rutu koja nedostaje.

Za obične zahteve koristite podržane kontrole: uključivanje i isključivanje po aplikaciji u VPN aplikaciji i vlastiti izbor mreže platforme za sve što treba određenu putanju. Ako privilegovana integracija zaista mora sarađivati s mašinerijom rutiranja, ciljajte implementaciju tačne Android verzije koju podržavate i održavajte njen životni ciklus kroz komponentu koja je poseduje. Brisanje platformskih lanaca ili umetanje pravila visokog prioriteta pretvara dijagnozu u drugi mrežni menadžer i telefon će se ponašati u skladu s tim.