Android VPN-leiðsögn: stefnureglur fyrir töfluna main
Android velur leiðartöflu með uid- og merkjareglum fyrir hverja áfangastaðaleit, þannig að leið sem bætt er við main er kannski aldrei skoðuð.
Leið sem bætt er við töfluna main á Android lítur rétt út í hverri skrá og flytur samt ekki umferðina. Ástæðan er sú að taflan main er einn valkostur af nokkrum, og hún er ekki skoðuð fyrst. Netþjónusta Android byggir stefnureglur sem velja leiðartöflu með upplýsingum sem áfangastaðarheitið inniheldur ekki — uid forritsins, merki á pakkanum, viðmótið sem hann kom inn á — og leitin að áfangastað fer fram á eftir, inni í þeirri töflu sem þessar reglur völdu.
Þrjár ákvarðanir í föstum röðum
Pakki á útleið tekur þrjár aðskildar ákvarðanir. Fyrst ákveður stefnuregla hvaða leiðartafla gildir. Næst ákveður leið inni í þeirri töflu næsta hopp og útviðmótið. Þriðja ákveða netfilter-kassar hvort pakkinn lifir, er breyttur eða er beint áfram.
Röðin skiptir máli því hvert stig getur aðeins svarað eigin spurningu. Eldveggjarregla sem samþykkir pakka velur ekki töflu, og leið sem bætt er við töflu sem engin regla velur er gagnslaus. Mikill hluti ruglingsins í kringum Android-VPN kemur frá því að laga eitt af þremur og sjá enga breytingu, því bilanirnar voru í öðru.
| 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 |
Merki eru pökkuð svið, ekki límmiði sem þú átt
Android pakkar nokkrum staðreyndum í sama merkisgildi: hvaða net var valið, hvort forrit valdi net sérstaklega, hvort samband er varið frá VPN og bitar sem tengjast heimildum. fwmark-haus AOSP skilgreinir þetta skipulag fyrir núverandi tré, og skipulagið er innri hlutur kerfisins sem breytist milli útgáfa.
Þess vegna er hættulegt á Android að skrifa heilt merkisgildi með iptables -j MARK --set-mark. Það bætir ekki við merkimiða; það kemur í stað netvalsins sem kerfið hefur þegar gert. Pakkinn passar þá við aðrar reglur, sem getur litið út eins og VPN hafi byrjað að virka, eða eins og ótengt forrit hafi misst samband, eftir því hvaða bitum var skrifað yfir.
Ef þú verður að snerta merki, lestu fyrst núverandi gildi og notaðu grímu þannig að aðeins þeim bitum sem þú skilur sé breytt:
ip rule show
ip route show table all | head -40
ip route get 10.20.4.11Tengingarmerki er aðskilinn hlutur frá pakkamerki, og hvorugt er leið. Að endurheimta merkið á svarpökkum er annað skref en að velja töflu á útleið, og þess vegna gefa einhliða lagfæringar sambönd sem opnast og hanga svo.
Hver á reglurnar og töflurnar
Netþjónusta Android, netd, býr til reglurnar og töflurnar fyrir hvert net. AOSP RouteController er staðurinn þar sem þessar reglur eru settar saman fyrir VPN, eðlisfræðileg net og uid-bil, og lífsferill þess er bundinn netviðburðum frekar en stillingarskrá.
Tvær afleiðingar fylgja. Fyrst eru forgangar og töflunúmer sem þú finnur í einum síma innri smáatriði byggingarinnar, ekki viðmót: númer sem líta eins út í annarri Android-útgáfu geta þýtt eitthvað allt annað. Næst er ástandinu endurbyggt þegar net breytast, þannig að regla sem sett er inn í dag úr root-skelf getur verið horfin eftir næstu Wi-Fi-breytingu.
Þessi hvarf eru oft tilkynnt sem að kerfið hunsar leið. Það sem raunverulega gerðist er að reglan sem valdi töfluna er ekki lengur til, og leiðin inni í töflunni er nú óaðgengileg frá sjónarhóli pakkans. Athugaðu reglulistann, ekki leiðarlistann, þegar virk stilling hættir að virka eftir endurtengingu.
Spurningar um röð kassanna hafa ekkert algilt svar
Spurningunni hvort iptables keyri fyrir VPN-leiðsögn er ekki hægt að svara án þess að nefna slóð pakkans. Pakki sem er búinn til á staðnum fer í gegnum output-kassann, þar sem merkjabreyting kallar á endurleiðsagnarprófun — önnur leit, ekki síðari breyting á þeirri fyrstu. Pakki sem kemur frá tether-skjá viðskiptavini fer um prerouting-slóð og er sendur áfram í staðinn, og keðjurnar sem sjá hann eru aðrar.
Þannig getur sama regla verið virk fyrir umferð forrits og ósýnileg fyrir tether-umferð, og teljari sem stendur á núlli segir þér hvaða slóð pakkinn fór, ekki hvort reglan er röng. Notaðu teljara til að staðfesta slóðina áður en þú breytir einhverju samsvörunarskilyrði.
Þetta er líka stigið þar sem mistök í stefnuleiðsögn verða illa sýnileg. Leiðsögn í töflu sem er til en inniheldur ekki áfangastaðinn gefur net óaðgengilegt sem lítur út eins og eldveggsfall, en eldveggsfall gefur tímanúll sem lítur út eins og leiðsagnar-svarthol.
Greindu inni í kerfinu, eða láttu það í friði
Fyrir leyfða endurskoðun skaltu staðfesta fjórar staðreyndir áður en þú snertir nokkuð: uid og prófíl forritsins, netið sem Android valdi fyrir það, hvort VPN inniheldur forritið yfirleitt, og hvort vandamálið er til í báðum heimilum heimilisfanga. Undanskilja eftir forriti skýrir mjög mörg tilkynningar um VPN virkar ekki án nokkurrar leiðsagnarbilunar.
Lestu svo reglurnar, grímurnar og töflurnar sem eru í raun í gildi, og haltu netbreytingu innan athugunargluggans. Ef hegðunin breytist yfir endurtengingu ertu að horfa á stýrðan lífsferil, ekki leið sem vantar.
Fyrir venjulegar kröfur skaltu nota studdu stýringarnar: innifokun og undanskilning eftir forriti í VPN-forritinu, og eigið netval kerfisins fyrir allt sem þarf sérstaka slóð. Ef forréttindasamþætting þarf í raun að vinna með leiðsagnarvélinni, miðaðu við útfærslu þeirrar nákvæmu Android-útgáfu sem þú styður og viðhaldið lífsferli hennar í gegnum hlutann sem á hana. Að skola kerfiskeðjur eða setja inn reglu með háan forgang breytir greiningu í annan netstjóra, og síminn mun hegða sér í samræmi við það.