Android VPN usmjeravanje: pravila politike prije tablice main
Android odabire tablicu usmjeravanja pravilima uid i oznaka prije svake pretrage odredišta, pa ruta dodana u main možda nikad neće biti provjerena.
Ruta dodana u tablicu main na Androidu izgleda ispravno u svakom popisu, a ipak ne prenosi promet. Razlog je u tome što je tablica main samo jedna od nekoliko mogućnosti i ne provjerava se prva. Androidova mrežna usluga gradi pravila politike koja odabiru tablicu usmjeravanja pomoću podataka koje odredišna adresa ne sadrži — uid aplikacije, oznaka na paketu, sučelje na koje je stigao — a pretraga odredišta događa se poslije, unutar one tablice koju su ta pravila odabrala.
Tri odluke u čvrstom redoslijedu
Paket na izlazu donosi tri zasebne odluke. Prvo, pravilo politike određuje koja tablica usmjeravanja vrijedi. Drugo, ruta unutar te tablice određuje sljedeći skok i izlazno sučelje. Treće, netfilter kuke određuju hoće li paket preživjeti, biti izmijenjen ili preusmjeren.
Redoslijed je važan jer svaka faza može odgovoriti samo na svoje pitanje. Pravilo vatrozida koje prihvaća paket ne odabire tablicu, a ruta dodana u tablicu koju nijedno pravilo ne odabire jest nijema. Velik dio zabune oko Android VPN-ova dolazi od toga da 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 zbijeno polje, a ne naljepnica koju posjedujete
Android zbija nekoliko činjenica u istu vrijednost oznake: koja je mreža odabrana, je li aplikacija izričito odabrala mrežu, je li socket zaštićen od VPN-a i bitovi vezani uz dopuštenja. AOSP fwmark zaglavlje definira taj raspored za trenutačno 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; zamjenjuje odabir mreže koji je sustav već obavio. 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, ovisno o tome koji su bitovi prepisani.
Ako ipak morate dirati oznake, pročitajte najprije trenutačnu vrijednost i upotrijebite masku kako bi se mijenjali samo bitovi koje razumijete:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11Oznaka veze zaseban je objekt od oznake paketa i nijedna nije ruta. Vraćanje oznake na odgovorne pakete zaseban je korak od odabira tablice na izlazu, zato jednosmjerni popravci stvaraju veze koje se otvore i potom zapnu.
Kome pripadaju pravila i tablice
Androidova mrežna usluga, 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 njezin je životni ciklus vezan uz mrežne događaje, a ne uz konfiguracijsku datoteku.
Slijede dvije posljedice. Prvo, prioriteti i brojevi tablica koje nađete na jednom telefonu unutrašnjosti su gradnje, a ne sučelje: istovjetni brojevi na drugoj verziji Androida mogu značiti nešto posve drugo. Drugo, stanje se ponovno gradi kad se mreže promijene, pa pravilo umetnuto danas iz root ljuske može nestati nakon sljedećeg prijelaza na Wi-Fi.
To nestajanje često se prijavljuje kao da sustav zanemaruje rutu. Stvarno se dogodilo to da pravilo koje je odabiralo tablicu više ne postoji, a ruta unutar tablice sada je nedostupna iz perspektive paketa. Provjerite popis pravila, a ne popis ruta, kada radna konfiguracija prestane raditi nakon ponovnog spajanja.
Pitanja o redoslijedu kuka nemaju univerzalan odgovor
Pitanje radi li iptables prije VPN usmjeravanja ne može se odgovoriti bez imenovanja puta paketa. Lokalno stvoren paket prolazi kroz output kuku, gdje promjena oznake pokreće provjeru ponovnog usmjeravanja — drugu pretragu, a ne naknadno uređivanje prve. Paket koji dolazi od tether klijenta prolazi putem prerouting i umjesto toga se prosljeđuje, a lanci koji ga vide drugačiji su.
Isto pravilo dakle može biti djelotvorno za promet aplikacije i nevidljivo za tether promet, a brojač koji ostaje na nuli govori vam kojim je putem paket krenuo, a ne je li pravilo pogrešno. Upotrijebite brojače da utvrdite put prije nego što promijenite bilo koji uvjet podudaranja.
Ovo je i faza u kojoj pogreška usmjeravanja politike postaje teško vidljiva. Usmjeravanje u tablicu koja postoji, ali ne sadrži odredište, daje mrežu nedostupnom koja izgleda kao odbacivanje vatrozida, dok odbacivanje vatrozida daje istek vremena koji izgleda kao crna rupa usmjeravanja.
Dijagnosticirajte unutar sustava ili ga ostavite na miru
Za ovlašteni pregled utvrdite četiri činjenice prije nego što bilo što dirnete: uid i profil aplikacije, mrežu koju je Android odabrao za nju, uključuje li VPN tu aplikaciju uopće i postoji li problem za obje obitelji adresa. Izuzetak po aplikaciji objašnjava mnoga izvješća VPN ne radi bez ikakvog kvara usmjeravanja.
Zatim pročitajte pravila, maske i tablice koje su doista na snazi i držite promjenu mreže unutar promatračkog okna. Ako se ponašanje promijeni kroz ponovno spajanje, gledate u upravljani životni ciklus, a ne u rutu koja nedostaje.
Za uobičajene zahtjeve upotrijebite podržane kontrole: uključivanje i isključivanje po aplikaciji u VPN aplikaciji i vlastiti odabir mreže platforme za sve što treba određeni put. Ako privilegirana integracija doista mora surađivati sa strojem usmjeravanja, ciljajte implementaciju točne verzije Androida koju podržavate i održavajte njezin životni ciklus kroz komponentu koja je posjeduje. Pražnjenje platformskih lanaca ili umetanje pravila visokog prioriteta pretvara dijagnozu u drugog mrežnog upravitelja i telefon će se ponašati u skladu s tim.