Smerovanie VPN na Androide: pravidlá zásad pred tabuľkou main
Android vyberá smerovaciu tabuľku pravidlami uid a značiek ešte pred každým hľadaním cieľa, takže trasa pridaná do main nemusí byť nikdy overená.
Trasa pridaná do tabuľky main na Androide vyzerá správne v každom výpise a napriek tomu prenos neprenáša. Dôvod je ten, že tabuľka main je len jedna z viacerých možností a nie je opytovaná prvá. Sieťová služba Androidu zostavuje pravidlá zásad, ktoré vyberajú smerovaciu tabuľku podľa informácií, ktoré cieľová adresa neobsahuje — uid aplikácie, značka na pakete, rozhranie, ktorým prišiel — a vyhľadanie cieľa prebieha až potom, vnútri tabuľky, ktorú tieto pravidlá vybrali.
Tri rozhodnutia v pevnom poradí
Odchádzajúci paket robí tri samostatné rozhodnutia. Po prvé, pravidlo zásad určuje, ktorá smerovacia tabuľka platí. Po druhé, trasa v tejto tabuľke určuje ďalší skok a výstupné rozhranie. Po tretie, háky netfilter rozhodujú, či paket prežije, bude upravený alebo presmerovaný.
Poradie je dôležité, pretože každá fáza vie odpovedať len na svoju vlastnú otázku. Pravidlo firewallu, ktoré paket prijme, nevyberá tabuľku, a trasa pridaná do tabuľky, ktorú nevyberá žiadne pravidlo, je neúčinná. Veľká časť zmätku okolo VPN na Androide vzniká tým, že sa opraví jedna z troch vecí a nevidno žiadnu zmenu, pretože chyba bola v inej.
| 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 |
Značky sú zabalené pole, nie štítok, ktorý vlastníte
Android zabaluje niekoľko faktov do rovnakej hodnoty značky: ktorá sieť bola vybratá, či aplikácia sieť výslovne vybrala, či je socket chránený pred VPN a bity súvisiace s oprávneniami. Hlavička fwmark v AOSP definuje toto rozloženie pre aktuálny strom a rozloženie je vnútorná záležitosť platformy, ktorá sa medzi vydaniami mení.
Preto je zápis celej hodnoty značky pomocou iptables -j MARK --set-mark na Androide nebezpečný. Nepridáva štítok; nahrádza voľbu siete, ktorú systém už urobil. Paket potom zodpovedá iným pravidlám, čo môže vyzerať, akoby VPN začala fungovať, alebo akoby nesúvisiaca aplikácia stratila pripojenie, podľa toho, ktoré bity boli prepísané.
Ak sa značiek musíte dotknúť, najprv prečítajte aktuálnu hodnotu a použite masku, aby sa menili len tie bity, ktorým rozumiete:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11Značka spojenia je samostatný objekt od značky paketu a ani jedna nie je trasa. Obnovenie značky na odpovedných paketoch je iný krok ako voľba tabuľky na výstupe, preto jednosmerné opravy vytvárajú spojenia, ktoré sa otvoria a potom visia.
Kto vlastní pravidlá a tabuľky
Sieťová služba Androidu, netd, vytvára pravidlá a tabuľky pre jednotlivé siete. AOSP RouteController je miesto, kde sa tieto pravidlá skladajú pre VPN, fyzické siete a rozsahy uid, a jeho životný cyklus je viazaný na sieťové udalosti, nie na konfiguračný súbor.
Vyplývajú z toho dva dôsledky. Po prvé, priority a čísla tabuliek, ktoré nájdete na jednom zariadení, sú vnútornosti zostavenia, nie rozhranie: rovnako vyzerajúce čísla na inej verzii Androidu môžu znamenať niečo úplne iné. Po druhé, stav sa pri zmene sietí znova zostavuje, takže pravidlo vložené dnes z root shellu môže po ďalšom prepnutí Wi-Fi zmiznúť.
Toto zmiznutie sa často hlási ako ignorovanie trasy systémom. V skutočnosti pravidlo, ktoré tabuľku vyberalo, už neexistuje a trasa v tabuľke je teraz z pohľadu paketu nedostupná. Kontrolujte zoznam pravidiel, nie zoznam trás, keď funkčná konfigurácia prestane po opätovnom pripojení fungovať.
Otázky poradia hákov nemajú univerzálnu odpoveď
Otázku, či iptables beží pred smerovaním VPN, nemožno zodpovedať bez pomenovania cesty paketu. Lokálne vytvorený paket prechádza hákom output, kde zmena značky spustí kontrolu opätovného smerovania — druhé vyhľadanie, nie dodatočná úprava prvého. Paket prichádzajúci od tethering klienta prechádza cestou prerouting a namiesto toho sa preposiela ďalej, a reťazce, ktoré ho vidia, sú iné.
To isté pravidlo teda môže byť účinné pre prevádzku aplikácie a neviditeľné pre tethering prevádzku, a počítadlo, ktoré zostane na nule, vám povie, akou cestou sa paket vydal, nie či je pravidlo nesprávne. Pred zmenou akejkoľvek podmienky zhody zistite cestu pomocou počítadiel.
Toto je aj fáza, v ktorej je chyba smerovania zásad ťažko viditeľná. Smerovanie do tabuľky, ktorá existuje, ale neobsahuje cieľ, vytvára sieť nedostupná, čo vyzerá ako zahodenie firewallom, kým zahodenie firewallom vytvára časový limit, ktorý vyzerá ako smerovacia čierna diera.
Diagnostikujte vnútri systému, alebo ho nechajte na pokoji
Pri autorizovanej kontrole zistite štyri fakty, kým sa čohokoľvek dotknete: uid a profil aplikácie, sieť, ktorú pre ňu Android vybral, či VPN túto aplikáciu vôbec zahŕňa a či problém existuje pre obe rodiny adries. Vylúčenie po aplikáciách vysvetľuje veľa hlásení VPN nefunguje bez akejkoľvek smerovacej chyby.
Potom si prečítajte pravidlá, masky a tabuľky, ktoré skutočne platia, a udržte prepnutie siete v rámci pozorovacieho okna. Ak sa správanie pri opätovnom pripojení zmení, pozeráte sa na riadený životný cyklus, nie na chýbajúcu trasu.
Pre bežné požiadavky používajte podporované ovládacie prvky: zahrnutie a vylúčenie po aplikáciách v aplikácii VPN a vlastnú voľbu siete platformy pre všetko, čo potrebuje konkrétnu cestu. Ak privilegovaná integrácia naozaj musí spolupracovať so smerovacím strojom, cieli na implementáciu presne tej verzie Androidu, ktorú podporujete, a udržujte jej životný cyklus cez komponent, ktorý ju vlastní. Prepláchnutie reťazcov platformy alebo vloženie pravidla s vysokou prioritou premení diagnózu na druhého správcu siete a telefón sa bude správať podľa toho.