Rhestr ganiatáu Android VpnService: pam mae tudalennau a ganiateir yn dal i hongian
Mae eich rhestr ganiatáu yn debygol o fod yn iawn. Mae tudalennau yn hongian oherwydd yr ateb DNS, y tabl llwybrau, soced y datryswr neu'r MTU. Dyma'r drefn i'w gwirio.
Fe wnaethoch ychwanegu parth at y rhestr ganiatáu, mae'r ymholiad yn cyrraedd eich ap, mae'r cymharwr yn dychwelyd caniatawyd, ac eto nid yw'r dudalen byth yn llwytho. Ar y pwynt hwnnw mae'r rhan fwyaf o bobl yn dechrau ailysgrifennu'r cymharwr ac yn ychwanegu cymariaethau â cherdynnod. Yn fy mhrofiad i, mae'r cymharwr fel arfer yn gywir, ac mae'r methiant un haen yn ddiweddarach: yn yr ateb DNS a syntheseiddiwch, yn y llwybr a osodwch, neu yn y soced a ddefnyddiwch i anfon yr ymholiad ymlaen. Y rhestr yw'r rhan hawdd; llwybr y pecyn yw'r lle mae rhestrau caniatáu yn torri.
Anaml y cymharwr yw'r bai
Y peth cyntaf i'w wahanu yw blociedig oddi wrth wedi torri. Dylai enw blociedig fethu'n gyflym ac yn weladwy, oherwydd mae'r porwr yn cael ateb sy'n dweud nad yw'r enw'n bodoli ac yn stopio. Mae enw wedi torri yn hongian, yn ceisio eto dros IPv6, yn disgyn i drafnidiaeth arall, ac yn eich gadael gyda dangosydd troelli. Os gwelwch ddangosydd troelli, mae eich rhestr ganiatáu yn debygol o ateb rhywbeth na all y cleient weithredu arno.
Y cofnod A gwag yw'r camgymeriad clasuraddol. Mae dychwelyd NOERROR gyda dim atebion yn edrych fel ateb dilys, felly mae'r datryswr stub yn ei dderbyn, mae'r porwr yn ceisio eto, yn ceisio AAAA, yn ceisio datryswr arall, ac yn rhoi'r gorau iddi lawer yn ddiweddarach. Mae cod ateb 3, NXDOMAIN, gyda'r adran gwestiwn wedi'i hadleisio a'r ID trafodiad wedi'i gopïo, yn diweddu'r sgwrs ar unwaith. Defnyddiwch ef ar gyfer pob enw rydych yn ei wrthod yn fwriadol.
Mae IPv6 yn haeddu'r un penderfyniad yn hytrach na rhagosodiad. Os byddwch yn ateb NXDOMAIN ar gyfer A ac yn gadael AAAA drwodd, gall y cleient gyrraedd yr enw blociedig dros IPv6 ac mae'r hidlydd yn gollwng. Mae rhai gweithrediadau yn ateb ymholiadau AAAA blociedig ag arwyddiad loopback fel bod y cysylltiad yn methu ar unwaith yn hytrach na disgyn yn ôl. Dewiswch un polisi, cymhwyswch ef i'r ddau fath o gofnod, a chofnodwch y ddau.
Llwybr sy'n dal popeth sy'n berchen ar bopeth
Nid yw cynllun DNS yn unig byth yn ychwanegu addRoute("0.0.0.0", 0), felly dim ond ymholiadau sy'n mynd i mewn i'r rhyngwyneb TUN ac mae popeth arall yn parhau i ddefnyddio'r rhwydwaith sylfaenol. Dyna'r ffurf ddiogel, ac mae hefyd yn esbonio pam mae rhai rhestrau caniatáu yn ymddangos yn gweithio ar Wi-Fi ac yn methu ar y rhwydwaith symudol.
Y foment y mae llwybr rhagosodedig yn bodoli, mae pob llif yn eiddo i chi. Mae pecyn TCP sy'n cyrraedd y rhyngwyneb ac nad yw'n cael ei anfon ymlaen nac yn cael ateb yn eistedd yn y ciw nes bod y cleient yn amseru allan, ac nid oes gwall i'w gofnodi oherwydd ni ddigwyddodd gwall. Gwelais rywun yn treulio prynhawn ar restr ganiatáu wedi torri a oedd mewn gwirionedd yn anfonwr coll ar gyfer porth 443. Cofnodwch brotocol a chyrchfan pob pecyn y byddwch yn penderfynu ei ollwng.
Rhaid i soced y datryswr adael y twnnel
Anfon ymlaen yw'r lle mae'r trap nesaf. Mae datryswyr y cludwr yn aml yn byw ar gyferiad preifat nad yw'r twnnel yn gallu ei gyrraedd, felly mae'r ymholiad a anfonwch ymlaen yn mynd i unman ac mae'r ap yn adrodd am amserau allan darllen. Anfonwch ymholiadau cymeradwy at ddatryswr rydych yn gwybod sy'n gyrraeddadwy, a phasiwch y soced hwnnw i VpnService.protect() yn gyntaf. Mae soced heb ei amddiffyn yn anfon yr ymholiad yn ôl i'ch twnnel eich hun, lle mae'n cyrraedd yr ap eto ac yn cylchdroi nes bod yr amserlen yn tanio.
Mae'r methiant yn edrych yn union yr un fath â thoriad rhwydwaith, a dyna pam mae'n goroesi mor hir mewn adroddiadau namau. Cadwch gyfrifwyr ar gyfer ymholiadau a anfonwyd ac atebion a gafwyd: os yw'r rhif cyntaf yn dringo a'r ail yn aros ar sero, rydych yn edrych ar y soced, nid y rhestr.
Mae maint a swm gwirio yn methu heb neges
Mae gollyngiadau tawel hefyd yn dod o faint. Gall ateb DNS gyda set atebion fawr, neu ysgwyd llaw TCP ag opsiynau hael, fod yn fwy na MTU llwybr na wnaethoch ei osod yn benodol erioed; mae'r darn yn diflannu i fyny'r afon ac mae'r cleient naill ai'n ceisio eto'n llai neu'n rhoi'r gorau i geisio. Mae gosod MTU'r rhyngwyneb i 1280 yn ddewis ceidwadol sy'n goroesi'r rhan fwyaf o lwybrau symudol, ac mae bod yn benodol yn well na etifeddu rhagosodiad na fesurodd neb.
Os ydych yn adeiladu pecynnau eich hun, y swm gwirio yw'r llofrudd tawel arall. Mae swm gwirio UDP a gyfrifir dros bennawd ffug sy'n gadael allan hyd UDP neu'r maes protocol yn cynhyrchu pecyn sy'n edrych yn ffurfiol iawn ar eich ochr chi ac sy'n cael ei daflu gan y derbynnydd heb unrhyw ôl. Cymharwch eich pennawd ffug â'r fanyleb maes wrth faes, a phrintiwch y swm gwirio a gyfrifwyd ar gyfer un llif hysbys wrth ddadnamu.
Beth na wnaiff VpnService drosoch
Mae dau derfyn yn werth eu gwybod cyn i chi gynllunio o'u cwmpas. Ni all unrhyw ap cyffredin osod procsi system-gyfan na ffeil PAC y tu allan i Wi-Fi, ac nid yw'r rhan honno wedi newid. Mae'r llwybr fesul ap wedi newid: cyn API 29 ni allai VpnService.Builder gario procsi o gwbl, ac o API 29 mae setHttpProxy(ProxyInfo.buildPacProxy(uri)) yn rhoi sgript PAC i'r platfform ei gwerthuso ar gyfer y rhwydwaith VPN. Gwerthuswch reolau yn eich cod eich hun pan fyddwch yn targedu API hŷn neu pan na all model PAC fynegi'r rheol. Nid yw UDP yn rhad ac am ddim chwaith: dim ond TCP mae porwyr yn ei anfon drwy brocsi SOCKS, ac mae'r rhan fwyaf o gleientiaid SOCKS5 byth yn gweithredu UDP ASSOCIATE, felly mae cynllun sy'n seiliedig ar brocsi yn gollwng neu'n gollwng UDP tra bo TCP yn edrych yn iach.
Yr ail derfyn hwnnw yw'r rheswm y gall protocol sy'n seiliedig ar UDP weithio ar rwydwaith cyffredin a methu'r foment y bydd eich VPN yn cysylltu. Os disgwylir i'r twnnel gario UDP, rhaid i'r anfonwr weithredu'r llwybr anfon ar ei gyfer, nid yn unig y llwybr TCP gyda math gwahanol o soced.
Gwiriwch yn y drefn hon
Ewch drwy'r rhestr mewn trefn a stopiwch yn y cam cyntaf sy'n methu, oherwydd mae pob gwiriad diweddarach yn sŵn nes bod yr un blaenorol yn dal.
- Rhestrwch y llwybrau sydd wedi'u gosod a chadarnhewch a yw pecynnau nad ydynt yn DNS yn mynd i mewn i'r rhyngwyneb TUN o gwbl.
- Cofnodwch enw'r ymholiad, y penderfyniad a'r cod ateb ar gyfer un enw blociedig ac un enw cymeradwy.
- Cadarnhewch fod soced y datryswr wedi'i amddiffyn a bod y datryswr a ddewiswyd yn ateb o du mewn'r twnnel.
- Cadarnhewch MTU'r rhyngwyneb a swm gwirio un ateb a adeiladwyd gennych â llaw.
- Ailadroddwch yr un dudalen ar Wi-Fi ac ar y rhwydwaith symudol, gan fod datryswyr y cludwr ac MTU'r llwybr yn wahanol.
Os yw'r pump i gyd yn dal ac mae'r dudalen yn dal i hongian, yr un nesaf dan amheuaeth yw'r anfonwr ei hun: cymharwch gais a ddaliwyd ag ateb a ddaliwyd a chwiliwch am gyfrif beitiau coll neu soced hanner caeedig. Mae cyfeirlyfr VpnService.Builder yn ymdrin â chontractau llwybr, DNS ac MTU, ac mae protect() yn alwad VpnService ar wahân yn hytrach nag opsiwn adeiladydd; dim ond bod y contract cyntaf wedi llwyddo y mae rhyngwyneb cysylltiedig yn ei olygu.