Enkursigado de VPN en Android: reguloj de politiko antaŭ la tabelo main

Enkursigilo aldonita al la tabelo main en Android aspektas ĝusta en ĉiu listigo kaj tamen ne portas la trafikon. La kaŭzo estas, ke la tabelo main estas unu eblo inter pluraj, kaj ĝi ne estas konsultata unue. La reta servo de Android konstruas regulojn de politiko, kiuj elektas enkursigan tabelon per informoj, kiujn la cela adreso ne enhavas — la uid de la aplikaĵo, marko sur la paketo, la interfaco, per kiu ĝi alvenis — kaj la serĉo de la celo okazas poste, ene de tiu tabelo, kiun tiuj reguloj elektis.

Tri decidoj en fiksa ordo

Eliranta paketo faras tri apartajn decidojn. Unue, regulo de politiko decidas, kiun enkursigan tabelon oni aplikas. Due, enkursigilo ene de tiu tabelo decidas la sekvan hop-on kaj la eliran interfacon. Trie, hokoj de netfilter decidas, ĉu la paketo postvivas, estas modifata aŭ redirektata.

La ordo gravas, ĉar ĉiu etapo povas respondi nur sian propran demandon. Fajroŝirma regulo, kiu akceptas paketon, ne elektas tabelon, kaj enkursigilo aldonita al tabelo, kiun neniu regulo elektas, estas senefika. Granda parto de la konfuzo pri Android-VPN-oj venas de tio, ke oni riparas unu el la tri kaj ne vidas ŝanĝon, ĉar la paneo estis en alia.

Markoj estas pakitaj kampoj, ne etikedo, kiun vi posedas

Android pakas plurajn faktojn en la saman markovaloron: kiun reton oni elektis, ĉu aplikaĵo eksplicite elektis reton, ĉu ingo estas protektita kontraŭ la VPN, kaj bitojn rilatajn al permesoj. La fwmark-kapo de AOSP difinas tiun aranĝon por la nuna arbo, kaj la aranĝo estas internaĵo de la platformo, kiu ŝanĝiĝas inter eldonoj.

Tial skribi tutan markovaloron per iptables -j MARK --set-mark estas danĝere en Android. Ĝi ne aldonas etikedon; ĝi anstataŭigas la retan elekton, kiun la sistemo jam faris. La paketo tiam kongruas kun aliaj reguloj, kio povas aspekti kvazaŭ la VPN ekfunkciis, aŭ kvazaŭ nerilata aplikaĵo perdis konekton, depende de tio, kiuj bitoj estis superskribitaj.

Se vi devas tuŝi markojn, legu unue la nunan valoron kaj uzu maskon, por ke nur tiuj bitoj, kiujn vi komprenas, estu modifitaj:

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

Konekta marko estas aparta objekto de paketa marko, kaj nek unu nek la alia estas enkursigilo. Restarigi la markon sur respondaj paketoj estas aparta paŝo de elekti tabelon ĉe la eliro, kaj tial unudirektaj riparoj produktas konektojn, kiuj malfermiĝas kaj poste haltas.

Kiu posedas la regulojn kaj la tabelojn

La reta servo de Android, netd, kreas la regulojn kaj la tabelojn por ĉiu reto. La AOSP RouteController estas la loko, kie tiuj reguloj estas kunmetataj por VPN-oj, fizikaj retoj kaj uid-intervaloj, kaj ĝia vivociklo ligiĝas al retaj eventoj, ne al agorda dosiero.

Du konsekvencoj sekvas. Unue, prioritatoj kaj tabelnumeroj, kiujn vi trovas sur unu telefono, estas internaj detaloj de la konstruo, ne interfaco: same aspektaj numeroj sur alia Android-versio povas signifi tute alion. Due, la stato rekonstruiĝas kiam retoj ŝanĝiĝas, do regulo enmetita hodiaŭ el root-ŝelo povas malaperi post la sekva Wi-Fi-transiro.

Tiu malapero ofte raportiĝas kvazaŭ la sistemo ignoras enkursigilon. Kio fakte okazis estas, ke la regulo, kiu elektis la tabelon, ne plu ekzistas, kaj la enkursigilo ene de la tabelo nun estas neatingebla el la vidpunkto de la paketo. Kontrolu la reguloliston, ne la enkursigilan liston, kiam funkcianta agordo ĉesas funkcii post rekonekto.

Demandoj pri la ordo de la hokoj ne havas universalan respondon

La demando, ĉu iptables ruliĝas antaŭ VPN-enkursigado, ne respondeblas sen nomi la paketan vojon. Loke generita paketo trapasas la hokon output, kie ŝanĝo de marko kaŭzas rekontrolon de enkursigado — dua serĉo, ne retroefika redakto de la unua. Paketo alvenanta de tetherita kliento trapasas la vojon prerouting kaj anstataŭe estas plusendata, kaj la ĉenoj, kiuj vidas ĝin, estas aliaj.

Do la sama regulo povas esti efika por la trafiko de aplikaĵo kaj nevidebla por tetherita trafiko, kaj nombrilo, kiu restas ĉe nulo, diras al vi, kiun vojon la paketo prenis, ne ĉu la regulo estas malĝusta. Uzu nombrilojn por konstati la vojon antaŭ ol ŝanĝi ajnan kongruan kondiĉon.

Tio estas ankaŭ la etapo, en kiu eraro de politika enkursigado fariĝas malfacile videbla. Enkursigado al tabelo, kiu ekzistas sed ne enhavas la celon, produktas reton neatingebla, kiu aspektas kiel fajroŝirma forĵeto, dum fajroŝirma forĵeto produktas tempolimon, kiu aspektas kiel enkursiga nigra truo.

Diagnozu ene de la sistemo aŭ lasu ĝin trankvila

Por rajtigita revizio, konstatos kvar faktojn antaŭ ol tuŝi ion ajn: la uid kaj profilon de la aplikaĵo, la reton, kiun Android elektis por ĝi, ĉu la VPN entute inkluzivas tiun aplikaĵon, kaj ĉu la problemo ekzistas por ambaŭ adresaj familioj. Esceptigo po aplikaĵo klarigas multajn raportojn de la tipo VPN ne funkcias sen ia ajn enkursiga paneo.

Poste legu la regulojn, maskojn kaj tabelojn, kiuj efektive validas, kaj tenu retan ŝanĝon ene de la observa fenestro. Se la konduto ŝanĝiĝas dum rekonekto, vi rigardas administritan vivociklon, ne mankan enkursigilon.

Por ordinaraj bezonoj uzu la subtenatajn regilojn: inkluzivigo kaj esceptigo po aplikaĵo en la VPN-aplikaĵo, kaj la propran retan elekton de la platformo por ĉio, kio bezonas specifan vojon. Se privilegia integriĝo vere devas kunlabori kun la enkursiga maŝinaro, celi la efektivigon de la preciza Android-versio, kiun vi subtenas, kaj prizorgu ĝian vivociklon per la komponanto, kiu posedas ĝin. Malplenigo de platformaj ĉenoj aŭ enmeto de altprioritata regulo transformas diagnozon en duan retadministranton, kaj la telefono kondutos konforme.