Android VPN-ruting: policyreglar før tabellen main

Ei rute som blir lagd til tabellen main på Android ser rett ut i kvar oversikt og fraktar likevel ikkje trafikken. Grunnen er at tabellen main er eitt alternativ blant fleire, og han blir ikkje spurd fyrst. Nettverkstenesta i Android byggjer policyreglar som vel ein rutetabell ut frå informasjon som måladdressa ikkje inneheld — uid-en til applikasjonen, eit merke på pakken, grensesnittet han kom inn på — og oppslaget mot målet skjer etterpå, inne i den tabellen som desse reglane valde.

Tre avgjerder i fast rekkjefølgje

Ein pakke på veg ut tek tre separate avgjerder. Fyrst avgjer ein policyregel kva rutetabell som gjeld. Deretter avgjer ei rute i den tabellen neste hopp og det utgåande grensesnittet. Til slutt avgjer netfilter-krokar om pakken overlever, blir endra eller blir omdirigert.

Rekkjefølgja har noko å seie fordi kvart trinn berre kan svare på sitt eige spørsmål. Ein brannmurregel som godtek ein pakke vel ikkje ein tabell, og ei rute som blir lagd til ein tabell ingen regel vel, er inaktiv. Mykje av forvirringa kring Android-VPN-ar kjem av å rette ein av dei tre og ikkje sjå noka endring, fordi feilen låg i ein annan.

Merkje er eit pakka felt, ikkje ei etikett du eig

Android pakkar fleire fakta inn i same merkjeverdi: kva nettverk som vart valt, om ein applikasjon uttrykkeleg valde eit nettverk, om ein socket er verna mot VPN-en, og bitar knytte til løyve. fwmark-hovudet i AOSP definerer dette oppsettet for det gjeldande treet, og oppsettet er ein plattformintern detalj som endrar seg mellom utgåver.

Difor er det farleg på Android å skrive ein heil merkjeverdi med iptables -j MARK --set-mark. Det legg ikkje til ein tag; det erstattar nettverksvalet systemet allereie har gjort. Pakken samsvarar då med andre reglar, noko som kan sjå ut som VPN-en byrja å verke, eller som at ein urelatert app mista tilkoplinga, avhengig av kva bitar som vart overtekne.

Viss du må røre merkje, les den gjeldande verdien fyrst og bruk ei maske slik at berre bitane du forstår blir endra:

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

Eit tilkoplingsmerke er eit eige objekt frå eit pakkemerke, og ingen av dei er ei rute. Å gjenopprette merket på svarpakkar er eit anna trinn enn å velje tabell på veg ut, og difor gir einvegsrettingar tilkoplingar som opnar og deretter heng.

Kven eig reglane og tabellane

Nettverkstenesta i Android, netd, lagar reglane og tabellane per nettverk. AOSP RouteController er staden der desse reglane blir sette saman for VPN-ar, fysiske nettverk og uid-område, og livssyklusen er knytt til nettverkshendingar i staden for ei konfigurasjonsfil.

To konsekvensar følgjer. For det fyrste er prioritetar og tabellnummer du finn på eitt handsett byggjeinterne detaljar, ikkje eit grensesnitt: like nummer på ein annan Android-versjon kan tyde noko heilt anna. For det andre blir tilstanden bygd opp att når nettverk endrar seg, så ein regel som blir sett inn i dag frå eit root-skal kan vere borte etter neste Wi-Fi-overgang.

Den forsvinninga blir ofte rapportert som at systemet ignorerer ei rute. Det som faktisk skjedde, er at regelen som valde tabellen ikkje finst lenger, og ruta i tabellen er no uoppnåeleg frå synsstaden til pakken. Kontroller regellista, ikkje rutelista, når ein fungerande konfigurasjon sluttar å verke etter ei attilkopling.

Spørsmål om rekkjefølgja på krokane har ikkje noko allment svar

Spørsmålet om iptables køyrer før VPN-ruting kan ikkje svarast utan å namngje vegen til pakken. Ein lokalt generert pakke går gjennom output-kroken, der ei merkeendring utløyser ein ny rutekontroll — eit andre oppslag, ikkje ei etterfølgjande endring av det fyrste. Ein pakke som kjem frå ein tether-klient, går gjennom prerouting-vegen og blir vidaresend i staden, og kjedene som ser han er andre.

Dermed kan same regel vere verknadsfull for trafikken til ein app og usynleg for tether-trafikk, og ein teljar som blir ståande på null fortel deg kva veg pakken tok, ikkje om regelen er feil. Bruk teljarar for å fastslå vegen før du endrar eit samsvarsvilkår.

Dette er også trinnet der ein policyrutingsfeil blir vanskeleg å sjå. Ruting til ein tabell som finst, men ikkje inneheld målet, gir eit nettverk uoppnåeleg som ser ut som eit brannmurslepp, medan eit brannmurslepp gir ein tidsavbroten som ser ut som eit rutingssvart hol.

Diagnostiser inne i systemet, eller lat det vere

For ein autorisert gjennomgang, fastslå fire fakta før du rører noko: uid-en og profilen til appen, nettverket Android valde for han, om VPN-en i det heile tek med den appen, og om problemet finst for båe adressefamiliane. Ei utelukking per app forklarer svært mange rapportar om at VPN ikkje verkar utan nokon rutingsfeil.

Les deretter reglane, maskene og tabellane som faktisk gjeld, og hald eit nettverksbyte innanfor observasjonsvindauget. Viss åtferda endrar seg gjennom ei attilkopling, ser du på ein styrt livssyklus, ikkje ei manglande rute.

For vanlege krav, bruk dei støtta kontrollane: inkludering og utelukking per app i VPN-applikasjonen, og nettverksvalet til plattformen sjølv for alt som treng ein bestemt veg. Viss ein privilegert integrasjon verkeleg må samarbeide med rutingsmaskineriet, rett deg mot implementasjonen av den nøyaktige Android-versjonen du støttar, og hald livssyklusen ved like gjennom komponenten som eig han. Å tømme plattformkjeder eller setje inn ein regel med høg prioritet gjer ein diagnose om til ein ekstra nettverkshandsamar, og telefonen vil oppføre seg deretter.