Android VPN-rutning: politikregler før tabellen main
Android vælger en rutetabel med uid- og mærkeregler før noget destinationsopslag, så en rute, der føjes til main, bliver måske aldrig konsulteret.
En rute, der føjes til tabellen main på Android, ser korrekt ud i enhver visning og bærer alligevel ikke trafikken. Årsagen er, at tabellen main er én mulighed blandt flere, og den konsulteres ikke først. Androids netværkstjeneste bygger politikregler, der vælger en rutetabel ud fra information, som destinationsadressen ikke indeholder — applikationens uid, et mærke på pakken, det interface den ankom på — og destinationsopslaget sker derefter, inde i den tabel som disse regler valgte.
Tre beslutninger i fast rækkefølge
En pakke på vej ud træffer tre separate beslutninger. For det første afgør en politikregel, hvilken rutetabel der gælder. For det andet afgør en rute i den tabel næste hop og det udgående interface. For det tredje afgør netfilter-kroge, om pakken overlever, ændres eller omdirigeres.
Rækkefølgen betyder noget, fordi hvert trin kun kan besvare sit eget spørgsmål. En firewall-regel, der accepterer en pakke, vælger ikke en tabel, og en rute, der føjes til en tabel, som ingen regel vælger, er inaktiv. Meget af forvirringen omkring Android-VPN'er kommer af at rette en af de tre og konstatere ingen ændring, fordi fejlen lå i en anden.
| 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 |
Mærker er et pakket felt, ikke et label du ejer
Android pakker flere kendsgerninger i samme mærkeværdi: hvilket netværk der blev valgt, om en applikation udtrykkeligt valgte et netværk, om en socket er beskyttet mod VPN'en, og bits vedrørende tilladelser. AOSP-fwmark-headeren definerer det layout for det aktuelle træ, og layoutet er en platformsintern detalje, der ændrer sig mellem udgivelser.
Derfor er det farligt på Android at skrive en hel mærkeværdi med iptables -j MARK --set-mark. Det tilføjer ikke et tag; det erstatter det netværksvalg, systemet allerede har foretaget. Pakken matcher derefter andre regler, hvilket kan se ud som om VPN'en begyndte at virke, eller som om en urelateret app mistede forbindelsen, afhængigt af hvilke bits der blev overskrevet.
Hvis du absolut skal røre mærker, så læs den aktuelle værdi først og brug en maske, så kun de bits, du forstår, ændres:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11Et forbindelsesmærke er et separat objekt fra et pakkemærke, og ingen af dem er en rute. At gendanne mærket på svarpakker er et andet trin end at vælge en tabel på vej ud, og derfor giver ensrettede rettelser forbindelser, der åbner og derefter hænger.
Hvem ejer reglerne og tabellerne
Androids netværkstjeneste, netd, opretter reglerne og tabellerne pr. netværk. AOSP RouteController er hvor disse regler samles for VPN'er, fysiske netværk og uid-intervaller, og dens livscyklus er knyttet til netværkshændelser frem for til en konfigurationsfil.
To konsekvenser følger. For det første er prioriteter og tabelnumre, som du finder på én telefon, interne byggedetaljer, ikke et interface: ens udseende numre på en anden Android-version kan betyde noget helt andet. For det andet genopbygges tilstanden, når netværk ændres, så en regel, der indsættes i dag fra et root-shell, kan være væk efter den næste Wi-Fi-overgang.
Den forsvinden rapporteres ofte som at systemet ignorerer en rute. Hvad der faktisk skete, er at reglen, der valgte tabellen, ikke længere findes, og ruten i tabellen nu er uopnåelig set fra pakkens synspunkt. Kontroller regellisten, ikke rutelisten, når en fungerende konfiguration holder op med at virke efter en genopkobling.
Spørgsmål om kædernes rækkefølge har intet universelt svar
Spørgsmålet om iptables kører før VPN-rutning, kan ikke besvares uden at navngive pakkens vej. En lokalt genereret pakke passerer output-krogen, hvor en mærkeændring udløser et genrutningscheck — et andet opslag, ikke en efterfølgende redigering af det første. En pakke, der ankommer fra en tethered klient, passerer prerouting-vejen og videresendes i stedet, og de kæder, der ser den, er andre.
Så den samme regel kan være effektiv for en apps trafik og usynlig for tethered trafik, og en tæller, der bliver på nul, fortæller dig, hvilken vej pakken tog, ikke om reglen er forkert. Brug tællere til at fastslå vejen, før du ændrer en matchbetingelse.
Det er også det trin, hvor en politikrutningsfejl bliver svær at se. Rutning til en tabel, der findes, men ikke indeholder destinationen, giver et netværk uopnåeligt, der ligner et firewall-drop, mens et firewall-drop giver en timeout, der ligner et rutningssort hul.
Diagnostiser inde i systemet, eller lad det være
For en autoriseret gennemgang skal du fastslå fire kendsgerninger, før du rører noget: appens uid og profil, det netværk Android valgte til den, om VPN'en overhovedet inkluderer den app, og om problemet findes for begge adressefamilier. En udelukkelse pr. app forklarer mange rapporter om VPN virker ikke uden nogen rutningsfejl.
Læs derefter de regler, masker og tabeller, der faktisk er i kraft, og hold et netværksskift inden for observationsvinduet. Hvis adfærden ændrer sig over en genopkobling, ser du på en administreret livscyklus, ikke på en manglende rute.
Til almindelige krav brug de understøttede kontroller: inklusion og udelukkelse pr. app i VPN-applikationen og platformens eget netværksvalg til alt, der kræver en bestemt vej. Hvis en privilegeret integration virkelig skal samarbejde med rutningsmaskineriet, så sigt mod implementeringen af den præcise Android-version, du understøtter, og vedligehold dens livscyklus gennem den komponent, der ejer den. At skylle platforms-kæder eller indsætte en regel med høj prioritet gør en diagnose til en ekstra netværksmanager, og telefonen vil opføre sig derefter.