Nid yw twnelu hollt ar gyfer cleientiaid hotspot yn eithrio fesul ap

Nid yw dau ofyniad sy’n swnio’n gyfartal yr un peth: „eithrio’r ap hwn o’r VPN” a „anfon y gyrchfan hon yn unig y tu allan i’r VPN ar gyfer y gliniadur ar fy hotspot”. Mae’r cyntaf yn newid sut mae soced ar y ffôn yn dewis rhwydwaith. Mae’n rhaid i’r ail newid penderfyniad anfon ar gyfer pecyn a ddaeth o ddyfais arall ar ôl i’r ffôn ei dderbyn yn barod. Cymysgu’r ddau yw sut y mae cleient hotspot yn gorffen gydag eithriad nad oedd byth ond yn berthnasol i borwr y ffôn ei hun.

Mae dau is-system yn berchen ar y ddau gwestiwn

Mae Android yn cadw rhwydweithio apiau a thethru ar wahân. Mae socedi apiau’n cael eu neilltuo i rwydwaith gan y pentwr cysylltedd, ac mae ap VPN yn penderfynu pa rai o’i socedi ei hun sy’n mynd i mewn i’r twnnel. Mae pecynnau a anfonir o gleient sydd wedi’i gysylltu yn cael eu trin gan is-system y tethru, sy’n gofyn i netd am lwybrau, rheolau polisi a chyfieithu ar y rhyngwyneb i lawr.

Mae eithriad fesul ap yn cael ei werthuso pan fydd ap yn agor soced. Nid yw pecyn a anfonwyd byth yn cyrraedd y gwiriad hwnnw, oherwydd ni ddeilliodd o soced ap ar y ddyfais hon. Dyna’r union reswm pam na all y ddau osodiad gymryd lle ei gilydd, ac nid yw’n fai yn y naill na’r llall.

Beth mae eithriad fesul ap yn ei newid mewn gwirionedd

Gall adeiladydd VpnService enwi pecynnau sy’n aros y tu allan i’r twnnel gydag addDisallowedApplication, neu enwi’r unig becynnau a ganiateir y tu mewn gydag addAllowedApplication. Yna mae’r apiau hynny’n agor socedi ar y rhwydwaith sylfaenol tra bod y VPN yn parhau i fod yn berchen ar y llwybr diofyn ar gyfer popeth arall.

Mae’r cwmpas yn fanwl: socedi’r pecyn ei hun, ar y ddyfais hon, cyhyd ag y bo’r twnnel i fyny. Nid yw’n dweud dim am draffig a anfonwyd, dim am ail ddyfais, a dim am becynnau y mae’r system yn eu hanfon ar ran tethru.

Nid yw’n rheolaeth cyrchfan chwaith. Mae eithrio porwr yn eithrio pob cyfeiriad y mae’r porwr hwnnw’n ei gyrraedd, gan gynnwys yr un roeddech am ei gadw y tu mewn i’r twnnel. Pan fydd y gofyniad yn enwi cyrchfan yn hytrach nag ap, y dewisydd ap yw’r offeryn anghywir o ran ei adeiladwaith.

Sut mae pecyn tethru yn edrych i’r ffôn

Mae pecyn y cleient yn cyrraedd rhyngwyneb y hotspot gyda chyfeiriad ffynhonnell preifat a neilltuwyd gan y ffôn, dyweder 192.168.43.20, a chyrchfan gyhoeddus. I’w anfon mae angen llwybr i’r cyswllt i fyny ar y ffôn a rheol gyfieithu fel y gall yr atebion ddod o hyd i’w ffordd yn ôl, oherwydd nid yw cyfeiriad preifat y cleient yn golygu dim ar y rhwydwaith cellog.

Mae Android yn mynegi hynny â rheolau polisi sy’n dewis tabl llwybro, ac mae netd yn ailadeiladu’r tablau a’r rheolau perthnasol pan fydd rhwydweithiau a VPNau’n newid. Nid yw rhif tabl, blaenoriaeth rheol nac enw rhyngwyneb a gopïwyd o bost fforwm, neu o’r un model ar ryddhad hŷn, yn sefydlu perchnogaeth barhaus. Dyna hefyd pam y gall rheol a ysgrifennwyd â llaw weithio am awr a stopio ar ôl yr ailgysylltiad nesaf.

Y polisi y mae eithriad hotspot ei angen mewn gwirionedd

Ysgrifennwch y penderfyniad fel ffynhonnell, cyrchfan a llwybr arfaethedig cyn cyffwrdd â rheol. Mae’r ffurf leiaf ar gyfer un gyrchfan a gymeradwywyd yn edrych fel hyn:

Rhaid i’r ddau gyfeiriad fod yn gyflawn. Mae angen llwybr defnyddiadwy ar y gangen uniongyrchol drwy’r cyswllt cellog i fyny sydd ar hyn o bryd yn gyfredol; mae angen llwybr y twnnel ynghyd â chaniatâd i anfon ar gangen y VPN. Rhaid i unrhyw gyfieithu ffynhonnell gyd-fynd â’r allanfa a ddewiswyd gennych, oherwydd mae NAT a gymhwysir ar ryngwyneb twnnel yn cyflwyno cyfeiriad y twnnel ac nid yr un cellog, ac yna nid yw’r llwybr yn ôl yn cytuno â’r llwybr allan.

Rhaid i atebion gyrraedd yr un cleient i lawr drwy gyflwr a olrheinir neu lwybr penodol, ac nid yw cyfrifydd pecynnau allan yn profi dim o hynny. Cadwch gludiant allanol y VPN ei hun y tu allan i gwmpas yr eithriad hefyd, neu bydd pecynnau cludydd y twnnel yn etifeddu polisi a ysgrifennwyd ar gyfer cais gwe cleient.

Nid yw un cyfeiriad a ddaliwyd yn gyrchfan

Mae un cyfeiriad IPv4 a ddarllenwyd o borwr yn snapshot. Mae gwasanaethau mawr yn ateb o anycast neu o set gylchdroi o gyfeiriadau ymyl, mae llawer yn ddau-stac, a gall llif mewngofnodi gyffwrdd â gwesteiwyr dilysu a thelemetreg nad yw’r dudalen byth yn eu dangos. Mae eithriad a adeiladwyd o amgylch y cyfeiriad a welsoch ar hap yn torri’r tro nesaf y bydd y gwasanaeth yn ailgydbwyso.

Defnyddiwch gyfeiriadau dogfennol perchennog y gwasanaeth, neu ystod y mae’n ei chyhoeddi, a chyfrifwch ar gyfer y ddwy deulu cyfeiriad. Os na ellir mynegi’r gofyniad fel set sefydlog, mae’n debyg mai cwestiwn polisi i’r gwasanaeth yw hyn, yn hytrach na thric llwybro ar ffôn.

Gwiriwch o’r ochr i lawr

Tri gwiriad, yn y drefn hon: y gwasanaeth a ddewiswyd o’r gliniadur, cyrchfan gyffredin y mae’n rhaid iddi aros y tu mewn i’r VPN, ac ap ffôn y mae’n rhaid iddo aros heb ei effeithio. Yna ailadroddwch ar ôl ailgysylltu ac ar ôl newid y cyswllt i fyny, oherwydd dyna pryd y mae’r tablau polisi yn cael eu hailadeiladu.

Os na all gweithrediad rhannu’r ffôn ddal y contract hwnnw ar draws ailgysylltiad, symudwch y polisi detholol i lwybrydd i lawr a gefnogir yn hytrach na chronni rheolau root ar y ffôn. Gall llwybrydd fynegi cyfateb ffynhonnell a chyrchfan gyda pherchennog sefydlog, a’r dogfennaeth modiwl tethru yw’r cyfeiriad cywir ar gyfer yr hyn y mae’r ffôn yn ei wneud mewn gwirionedd.