Llwybro VPN Android: rheolau polisi cyn y tabl main

Mae llwybr a ychwanegir at y tabl main ar Android yn edrych yn gywir ym mhob rhestr ac eto nid yw'n cario'r traffig. Y rheswm yw bod y tabl main yn un opsiwn ymhlith sawl un, ac ni ymgynghorir ag ef yn gyntaf. Mae gwasanaeth rhwydweithio Android yn adeiladu rheolau polisi sy'n dewis tabl llwybro gan ddefnyddio gwybodaeth nad yw'r cyfeiriad cyrchfan yn ei chynnwys — uid y rhaglen, marc ar y pecyn, y rhyngwyneb y daeth i mewn arno — ac mae'r chwiliad cyrchfan yn digwydd wedyn, y tu mewn i ba bynnag dabl a ddewiswyd gan y rheolau hynny.

Tri phenderfyniad mewn trefn sefydlog

Mae pecyn ar ei ffordd allan yn gwneud tri phenderfyniad ar wahân. Yn gyntaf, mae rheol polisi yn penderfynu pa dabl llwybro sy'n berthnasol. Yn ail, mae llwybr o fewn y tabl hwnnw yn penderfynu'r naid nesaf a'r rhyngwyneb allan. Yn drydydd, mae bachau netfilter yn penderfynu a yw'r pecyn yn goroesi, yn cael ei addasu, neu'n cael ei ailgyfeirio.

Mae'r drefn o bwys oherwydd gall pob cam ateb dim ond ei gwestiwn ei hun. Nid yw rheol mur cadarn sy'n derbyn pecyn yn dewis tabl, ac mae llwybr a ychwanegir at dabl nad oes unrhyw reol yn ei ddewis yn ddi-rym. Daw llawer o'r dryswch o amgylch VPN Android o drwsio un o'r tri a gweld dim newid, oherwydd roedd y nam mewn un arall.

Mae marciau yn faes wedi'i bacio, nid label sy'n eiddo i chi

Mae Android yn pacio sawl ffaith i'r un gwerth marc: pa rwydwaith a ddewiswyd, a wnaeth rhaglen ddewis rhwydwaith yn benodol, a yw soced wedi'i amddiffyn rhag y VPN, a darnau sy'n ymwneud â chaniatâd. Mae pennawd fwmark AOSP yn diffinio'r cynllun hwnnw ar gyfer y goeden gyfredol, ac mae'r cynllun yn fewnol i'r platfform ac yn newid rhwng rhyddhau.

Dyna pam mae ysgrifennu gwerth marc cyfan gyda iptables -j MARK --set-mark yn beryglus ar Android. Nid yw'n ychwanegu tag; mae'n disodli'r dewis rhwydwaith a wnaeth y system yn barod. Yna mae'r pecyn yn cyfateb i reolau gwahanol, a all edrych fel bod y VPN wedi dechrau gweithio, neu fel bod rhaglen ddi-gysylltiad wedi colli cysylltiad, yn dibynnu pa ddarnau a ailysgrifennwyd.

Os oes rhaid i chi gyffwrdd â marciau, darllenwch y gwerth cyfredol yn gyntaf a defnyddiwch fwgwd fel mai dim ond y darnau rydych yn eu deall sy'n cael eu newid:

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

Mae marc cysylltiad yn wrthrych ar wahân i farc pecyn, ac nid yw'r un ohonynt yn llwybr. Mae adfer y marc ar becynnau ateb yn gam ar wahân i ddewis tabl ar y ffordd allan, a dyna pam mae atgyweiriadau unffordd yn cynhyrchu cysylltiadau sy'n agor ac yna'n hongian.

Pwy sy'n berchen ar y rheolau a'r tablau

Mae gwasanaeth rhwydwaith Android, netd, yn creu'r rheolau a'r tablau fesul rhwydwaith. Y AOSP RouteController yw'r man lle mae'r rheolau hynny'n cael eu casglu ar gyfer VPN, rhwydweithiau ffisegol ac ystodau uid, ac mae ei gylch bywyd ynghlwm wrth ddigwyddiadau rhwydwaith yn hytrach nag wrth ffeil ffurfweddu.

Mae dau ganlyniad yn dilyn. Yn gyntaf, mae blaenoriaethau a rhifau tabl a welwch ar un ffôn yn fewnol i'r adeiladwaith, nid yn rhyngwyneb: gall rhifau sy'n edrych yn union yr un fath ar fersiwn Android arall olygu rhywbeth hollol wahanol. Yn ail, mae'r cyflwr yn cael ei ailadeiladu pan fydd rhwydweithiau'n newid, felly gall rheol a fewnosodwyd heddiw o grianghell root fod wedi diflannu ar ôl y newid Wi-Fi nesaf.

Adroddir am y diflaniad hwnnw'n aml fel bod y system yn anwybyddu llwybr. Yr hyn a ddigwyddodd mewn gwirionedd yw nad yw'r rheol a ddewisodd y tabl yn bodoli mwyach, ac mae'r llwybr o fewn y tabl bellach yn anghyrraeddadwy o safbwynt y pecyn. Edrychwch ar y rhestr rheolau, nid y rhestr llwybrau, pan fydd ffurfweddiad sy'n gweithio yn stopio gweithio ar ôl ailgysylltu.

Nid oes ateb cyffredinol i gwestiynau am drefn y bachau

Ni ellir ateb y cwestiwn a yw iptables yn rhedeg cyn llwybro VPN heb enwi llwybr y pecyn. Mae pecyn a gynhyrchir yn lleol yn croesi bachyn output, lle mae newid marc yn sbarduno gwiriad ail-lwybro — ail chwiliad, nid golygiad ôl-weithredol o'r cyntaf. Mae pecyn sy'n cyrraedd o gleient tether yn croesi llwybr prerouting ac yn cael ei anfon ymlaen yn lle hynny, ac mae'r cadwyni sy'n ei weld yn wahanol.

Felly gall yr un rheol fod yn effeithiol i draffig rhaglen ac yn anweledig i draffig tether, ac mae cownter sy'n aros ar sero yn dweud wrthych pa lwybr a gymerodd y pecyn, nid a yw'r rheol yn anghywir. Defnyddiwch gownteri i sefydlu'r llwybr cyn newid unrhyw amod cyfateb.

Dyma hefyd y cam lle mae camgymeriad llwybro polisi yn mynd yn anodd ei weld. Mae llwybro i dabl sy'n bodoli ond nad yw'n cynnwys y gyrchfan yn cynhyrchu rhwydwaith anghyrraeddadwy sy'n edrych fel gollyngiad mur cadarn, tra bod gollyngiad mur cadarn yn cynhyrchu goramser sy'n edrych fel twll du llwybro.

Diagnoswch y tu mewn i'r system, neu gadewch iddi fod

Ar gyfer adolygiad awdurdodedig, sefydlwch bedair ffaith cyn cyffwrdd ag unrhyw beth: uid a phroffil y rhaglen, y rhwydwaith a ddewisodd Android ar ei chyfer, a yw'r VPN yn cynnwys y rhaglen honno o gwbl, ac a yw'r broblem yn bodoli ar gyfer y ddwy deulu cyfeiriad. Mae eithrio fesul rhaglen yn egluro llawer iawn o adroddiadau VPN ddim yn gweithio heb unrhyw nam llwybro.

Yna darllenwch y rheolau, y mygydau a'r tablau sydd mewn gwirionedd mewn grym, a chadwch newid rhwydwaith o fewn y ffenestr arsylwi. Os yw'r ymddygiad yn newid dros ailgysylltiad, rydych yn edrych ar gylch bywyd a reolir, nid ar lwybr sydd ar goll.

Ar gyfer gofynion cyffredin, defnyddiwch y rheolyddion a gefnogir: cynnwys ac eithrio fesul rhaglen yn y rhaglen VPN, a dewis rhwydwaith y platfform ei hun ar gyfer unrhyw beth sy'n mynnu llwybr penodol. Os oes rhaid i integreiddiad braintol gydweithredu go iawn â'r peirianwaith llwybro, targedwch weithrediad yr union fersiwn Android rydych yn ei gefnogi a chynnal ei gylch bywyd drwy'r gydran sy'n berchen arno. Mae fflysio cadwyni platfform neu fewnosod rheol â blaenoriaeth uchel yn troi diagnosis yn ail reolwr rhwydwaith, a bydd y ffôn yn ymddwyn yn unol â hynny.