Pam mae Android VpnService yn dal rhywfaint o draffig ac nid y cyfan

Nid yw unrhyw beth yn VpnService yn rhyng-gipio traffig ar ei ben ei hun. Mae'n gofyn i'r system am ryngwyneb tun, yn rhoi set o gyfeiriadau a llwybrau i'r rhyngwyneb hwnnw, ac o'r eiliad honno mae'r cnewyllyn yn copïo pob pecyn sy'n cyfateb i'r llwybrau hynny i ddisgrifydd ffeil y gall yr ap ei ddarllen. Ni fydd cod yr ap byth yn gweld y pecynnau na ddewisodd y llwybrau, felly mae amrediad twnnel yn gwestiwn tabl llwybro cyn iddo fod yn gwestiwn rhaglennu. Dyna pam y gall yr un gweithrediad gwasanaeth lyncu pob llif ar un ffôn a dim ond rhan ar un arall, a pham mae ychwanegu llwybr weithiau'n trwsio twnnel a oedd yn edrych yn doredig. Yr hyn a gewch yw'r hyn a ddatganoch, heb y cyfan a wrthododd yr adeilydd yn ddistaw.

Mae llwybrau'n penderfynu pa becynnau sy'n cyrraedd

Mae Builder.addRoute(prefix, prefixLength) yn gosod rhagddodiad yn nhabl llwybro'r rhwydwaith VPN. Mae'r system yn trin y rhwydwaith hwnnw fel y rhagosodiad i'r apiau yn yr amrediad, felly ymgynghorir ei gofnodion o flaen llwybr rhagosodedig y rhwydwaith corfforol ac mae rhagddodiad cyfatebol yn ddigon i ddargyfeirio llif. Felly mae llwybr ar gyfer 0.0.0.0/0 yn cymryd IPv4 yn gyfan, gan gynnwys yr argraffydd, y targed cast a thudalen weinyddol y llwybrydd.

Mae cleientiaid sydd am y sylw hwnnw heb ddileu'r cofnod rhagosodedig corfforol yn defnyddio'r pâr 0.0.0.0/1 a 128.0.0.0/1 yn lle hynny. Mae dau lwybr mwy penodol yn curo llwybr rhagosodedig, gyda'i gilydd maent yn rhychwantu'r holl ofod cyfeiriadau, ac mae cofnod rhagosodedig y ffôn ei hun yn aros yn y tabl ar gyfer y socedi sydd wedi'u rhwymo i'r rhwydwaith corfforol o hyd.

Mae cyfeiriadau a chofnodion DNS yn dod o'r un adeilydd ac yn ateb cwestiwn gwahanol. Mae addAddress yn rhoi cyfeiriad i'r rhyngwyneb gyda hyd rhagddodiad, ac mae addDnsServer yn gosod datryswr y bydd apiau yn yr amrediad yn ymholi ag ef drwy'r rhyngwyneb. Gall y ddau deulu eistedd ar un rhyngwyneb, felly mae set llwybrau IPv4 yn unig wrth ymyl cyfeiriad IPv6 yn ffurfweddiad sy'n darllen yn gywir ac yn gollwng o hyd. Os ydych yn llwybro teulu nad oes gan y rhyngwyneb gyfeiriad ynddo, nid oes gan y cnewyllyn gyfeiriad ffynhonnell ar gyfer y pecynnau hynny ac ni fyddant byth yn ymddangos yn y disgrifydd.

Yr hyn y mae establish() yn ei ddychwelyd

Mae establish() yn dychwelyd ParcelFileDescriptor, neu null pan nad yw'r ap wedi'i awdurdodi. Mae null yn gyflwr cydsyniad yn hytrach na gwall rhwydwaith: rhaid i VpnService.prepare() fod wedi dychwelyd null yn barod, neu rhaid i'r defnyddiwr fod wedi cymeradwyo deialog y system cyn yr alwad. Gellir tynnu cydsyniad yn ôl tra bo'r gwasanaeth yn rhedeg, ac mae'r rhyngwyneb yn cau o danoch heb unrhyw alwad yn ôl i'ch dolen ddarllen.

Nid yw'r disgrifydd yn rhwystro oni bai eich bod yn dweud yn wahanol, felly mae darlleniad yn dychwelyd ar unwaith heb ddata yn hytrach na pharcio'r edau. Mae dolen a ysgrifennwyd ar gyfer soced rhwystro yn llosgi craidd, ac mae dolen sy'n trin darlleniad gwag fel un angheuol yn rhwygo'r twnnel yn ystod eiliad segur. Mae Builder.setBlocking(true) yn newid yr ymddygiad hwnnw, a'r pris yw edau sy'n aros y tu mewn i'r darlleniad.

Mae dadleuon llwybr a chyfeiriad yn cael eu dilysu fel gwerthoedd LinkAddress, ac mae cyrchfannau multicast fel 224.0.0.0/4 yn cael eu gwrthod yn syth. Nid oes gan ryngwyneb tun pwynt-i-bwynt barth darlledu chwaith, felly mae darganfod multicast drosto angen dyluniad gwahanol yn hytrach nag un llwybr yn fwy. Mae cyfeirlyfr VpnService.Builder yn y rhestr i'w gwirio cyn i chi ddod i'r casgliad bod alwad wedi'i hanwybyddu.

Mae amrediad fesul ap yn culhau'r set, nid y twnnel

O API 21 ymlaen mae'r adeilydd yn derbyn addAllowedApplication a addDisallowedApplication, ac mae'r ddwy restr yn atgyfnerthol o fewn un adeilydd. Mae rhestr ganiatáu yn gwneud i'r twnnel fodoli ar gyfer y pecynnau hynny tra bo popeth arall yn cadw'r rhwydwaith corfforol; mae rhestr gwahardd yn dal popeth heblaw'r pecynnau a enwir, sef yr hyn y mae cleient yn ei gynnig fel twnnelu hollt. Cyn API 21 nid oes unrhyw fecanwaith platfform o gwbl, a daeth ymddygiad fesul ap o gleientiaid trydydd parti yn hidlo yn ôl UID y tu mewn i'w trosglwyddydd eu hunain. Mae'r gwahaniaeth yn bwysig pan fyddwch yn dadfygio, oherwydd mae twnnel fesul ap gyda rhestr ganiatáu o un pecyn yn cynhyrchu bron dim traffig ac mae hynny'n ymddygiad cywir, nid llwybr toredig.

Beth bynnag fo'r amrediad, ni chaiff y soced y mae eich ap yn ei agor i weinydd VPN deithio drwy'r twnnel y mae'n ei adeiladu. Mae VpnService.protect(socket) yn rhwymo'r soced hwnnw i'r rhwydwaith sylfaenol fel bod ei becynnau'n sgipio'r ddyfais tun. Os sgipiwch yr alwad, bydd y cydlawenhad yn cael ei lyncu gan y rhyngwyneb y dylai fod wedi'i godi.

Mae VpnService.setUnderlyingNetworks yn cau'r ddolen drwy ddweud wrth y system pa rwydwaith corfforol sy'n cario'r twnnel. Mae'r gwerth hwnnw'n pennu sut mae'r VPN yn adrodd cysylltedd i apiau eraill, ac mae gwerth null neu hen yn achos arferol o dwnnel cysylltiedig y mae gweddill y ffôn yn ei drin fel un all-lein. Diweddarwch ef pan fydd y rhwydwaith sylfaenol yn newid, nid yn unig wrth gychwyn.

Swm gwirio a MTU: lle mae llwybr cywir yn methu o hyd

Unwaith y bydd pecynnau'n cyrraedd, mae dwy fanwl yng ngham y pecyn yn penderfynu a oes unrhyw beth yn gweithio o un pen i'r llall. Y cyntaf yw'r cyfeiriad ffynhonnell: gyda sawl cyfeiriad rhyngwyneb gall y cnewyllyn ollwng pecynnau'n cario'r cyntaf, felly rhaid i drosglwyddydd sy'n ailysgrifennu pennawdau drwsio'r cyfeiriad a'r swm gwirio sy'n ei gwmpasu.

Yr ail yw cwmpas y swm gwirio. Pan fydd yr ap yn adeiladu pecynnau TCP neu UDP ei hun, mae'r swm gwirio'n cwmpasu pseudo-bennawd yn dal y cyfeiriad ffynhonnell, y cyfeiriad cyrchfan, rhif y protocol a hyd y cludiant, ac mae hepgor unrhyw un o'r rheini'n rhoi pecynnau sy'n cyrraedd ac yn cael eu gollwng. Mae'r methiant hwnnw'n edrych fel goramser ar ôl ateb na ddaw byth, sy'n anfon y rhan fwyaf o bobl yn ôl at y llwybrau. Mae setMtu yn gosod MTU y rhyngwyneb, ac mae pob darlleniad yn dychwelyd yn union un pecyn IP cyflawn, felly bydd byffer a ysgrifennwyd ar gyfer llif beitiau yn tameidio'ch dadansoddiad, nid y pecyn.

Pàs gwirio sy'n gwahanu'r haenau

I ddod o hyd i ble aeth yr amrediad o'i le, profwch yr haenau yn eu trefn. Gofynnwch i'r ddyfais pa lwybrau y mae'r rhwydwaith VPN yn eu dal mewn gwirionedd, yna gwiriwch a yw llif i gyfeiriad hysbys yn ymddangos fel darlleniad ar y disgrifydd, yna gwiriwch a yw'r pecyn y mae eich trosglwyddydd yn ei ollwng wedi'i ffurfio'n dda. Nid yw problem llwybr yn dangos dim ar y disgrifydd, tra bo problem swm gwirio yn dangos pecyn sy'n cyrraedd ac yn diflannu.

Os na chyrhaedda dim y disgrifydd, y set llwybrau yw'r sawl a amheuir yn hytrach na'r darllenydd: cadarnhewch y rhagddodiaid, cadarnhewch fod cyfeiriad yn yr un teulu, a chadarnhewch fod yr ap o fewn yr amrediad a osodoch. Os yw pecynnau'n cyrraedd y disgrifydd ond nad oes dim yn dod yn ôl, archwiliwch protect() a gwerth y rhwydwaith sylfaenol cyn i chi gyffwrdd â llwybr eto. Os yw'r ochr bell yn adrodd pecynnau diffygiol, y swm gwirio a'r MTU yw'r lleoedd i edrych. Mae un prawf fesul haen yn arbed prynhawn o ddyfalu.