Android VPN rutiranje: pravila politike prije tablice main
Android bira tablicu rutiranja pravilima uid i oznaka prije svake pretrage odredišta, pa ruta dodana u main možda nikad neće biti konsultovana.
Ruta dodana u tablicu main na Androidu izgleda ispravno u svakom ispisu i ipak ne prenosi saobraćaj. Razlog je to što je tablica main samo jedna od nekoliko opcija i ne konsultuje se prva. Androidova mrežna služba gradi pravila politike koja biraju tablicu rutiranja pomoću informacija koje odredišna adresa ne sadrži — uid aplikacije, oznaka na paketu, interfejs na koji je stigao — a pretraga odredišta se dešava poslije, unutar one tablice koju su ta pravila izabrala.
Tri odluke u fiksnom redoslijedu
Paket na izlazu donosi tri odvojene odluke. Prvo, pravilo politike odlučuje koja tablica rutiranja važi. Drugo, ruta unutar te tablice odlučuje sljedeći hop i izlazni interfejs. Treće, netfilter kuke odlučuju da li paket preživljava, biva izmijenjen ili preusmjeren.
Redoslijed je važan jer svaka faza može odgovoriti samo na svoje pitanje. Pravilo firewall-a koje prihvata paket ne bira tablicu, a ruta dodana u tablicu koju nijedno pravilo ne bira je inertna. Veliki dio zabune oko Android VPN-ova dolazi od toga što se popravi jedna od tri stvari i ne vidi promjena, jer je kvar bio u drugoj.
| 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 su spakovano polje, a ne etiketa koju posjedujete
Android pakuje nekoliko činjenica u istu vrijednost oznake: koja mreža je 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 mijenja između izdanja.
Zato je pisanje cijele vrijednosti oznake pomoću iptables -j MARK --set-mark opasno na Androidu. Ono ne dodaje oznaku; ono zamjenjuje izbor mreže koji je sistem već napravio. Paket se zatim poklapa s drugim pravilima, što može izgledati kao da je VPN počeo raditi ili kao da je nepovezana aplikacija izgubila vezu, zavisno od toga koji su bitovi prepisani.
Ako morate dirati oznake, prvo pročitajte trenutnu vrijednost i koristite masku tako da se mijenjaju samo bitovi koje razumijete:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11Oznaka veze je odvojen objekat od oznake paketa i nijedna nije ruta. Vraćanje oznake na odgovorne pakete je poseban korak od biranja tablice na izlazu, zato jednosmjerna rješenja daju veze koje se otvore i onda se zakače.
Ko posjeduje pravila i tablice
Androidova mrežna služba, netd, stvara pravila i tablice po mreži. AOSP RouteController je mjesto gdje se ta pravila sastavljaju za VPN-ove, fizičke mreže i uid raspone, a njegov životni ciklus je vezan za mrežne događaje, a ne za konfiguracijsku datoteku.
Slijede dvije posljedice. Prvo, prioriteti i brojevi tablica koje nađete na jednom telefonu su unutrašnjost builda, a ne interfejs: identično označeni brojevi na drugoj Android verziji mogu značiti nešto sasvim drugo. Drugo, stanje se ponovo gradi kada se mreže promijene, pa pravilo umetnuto danas iz root shell-a može nestati nakon sljedećeg Wi-Fi prelaza.
To nestajanje se često prijavljuje kao da sistem ignoriše rutu. Stvarno se dogodilo to da pravilo koje je biralo tablicu više ne postoji, a ruta unutar tablice je sada nedostupna iz perspektive paketa. Provjerite listu pravila, a ne listu ruta, kada radna konfiguracija prestane raditi nakon ponovnog povezivanja.
Pitanja o redu kuka nemaju univerzalni odgovor
Pitanje da li iptables radi prije VPN rutiranja ne može se odgovoriti bez imenovanja putanje paketa. Lokalno generisan paket prolazi kroz output kuku, gdje promjena oznake pokreće provjeru ponovnog rutiranja — druga pretraga, a ne retroaktivno uređivanje prve. Paket koji dolazi od tethered klijenta prolazi kroz prerouting putanju i umjesto toga se prosljeđ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 prije nego što promijenite bilo koji uslov podudaranja.
Ovo je i faza u kojoj greška rutiranja politike postaje teško vidljiva. Rutiranje u tablicu 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 ne dirajte
Za autorizovani pregled, utvrdite četiri činjenice prije 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 obje adresne porodice. Izuzetak po aplikaciji objašnjava mnoge prijave VPN ne radi bez ikakvog kvara u rutiranju.
Zatim pročitajte pravila, maske i tablice koje su stvarno na snazi i držite promjenu mreže unutar prozora posmatranja. Ako se ponašanje promijeni kroz ponovno povezivanje, gledate u upravljani životni ciklus, a ne u rutu koja nedostaje.
Za obične zahtjeve 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 posjeduje. 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.