Ap Android yn datrys enwau y tu allan i’r VPN: rhestr wirio ar gyfer clymu
Gall Android ddatrys enwau trwy’r rhwydwaith diofyn tra bo VPN yn weithredol. Clymwch y broses i rwydwaith y VPN a gwiriwch pa ddatryswr a ddefnyddiodd yr ap mewn gwirionedd.
Mae ap Android yn methu datrys enw mewnol tra bo porwr y cleient VPN yn ei gyrraedd, ac mae’r un adeiladwaith yn gweithio ar ffôn arall. Nid yr URL yw’r newidyn. Y newidyn yw pa rwydwaith y caniateir i broses yr ap ei defnyddio ar gyfer datrys, ac nid yw Android yn gwarantu mai’r VPN gweithredol yw’r un y mae eich socedi yn ei ddefnyddio. Ewch drwy’r gwiriadau hyn yn eu trefn a stopiwch pan fo ciplun y datryswr yn anghytuno â’ch tybiaeth.
Cam 1: Profi ar ba rwydwaith mae’r ap
Darllenwch olygfa’r ap ei hun yn hytrach na’r bar statws. O ConnectivityManager cymerwch y rhwydwaith gweithredol, ei LinkProperties , y rhestr o weinyddwyr DNS a’r gosodiad DNS preifat. Os yw’r rhestr yn cynnwys datryswr y VPN, mae gan yr ap lwybr ato; os yw’n cynnwys datryswr y Wi-Fi, nid y twnnel yw’r rhwydwaith diofyn ar gyfer y broses honno.
Dim ond dweud bod twnnel yn bodoli y mae eicon VPN. Nid yw’n dweud bod proses yr ap wedi’i chlymu iddo, ac nid yw Android bob amser yn cyfeirio datrys enwau trwy’r rhwydwaith sy’n edrych yn weithredol. Gall apiau VPN lleol sy’n anfon ymlaen i ddyfais arall, rhwydweithiau Wi-Fi heb ryngrwyd ac adeiladwaith gweithgynhyrchwyr adael ap yn gofyn i’r datryswr diofyn yn lle gweinyddwyr y twnnel.
Cam 2: Gofynnwch am gludiant y VPN a chlymwch y broses
Pan fo’n rhaid i’r ap ddefnyddio datryswr y twnnel, gofynnwch am rwydwaith â chludiant y VPN a chlymwch y broses yn y callback, fel nad yw’r cod yn dyfalu pryd mae’r rhwydwaith yn ymddangos:
val request = NetworkRequest.Builder()
.addTransportType(NetworkCapabilities.TRANSPORT_VPN)
.build()
connectivityManager.requestNetwork(request, object : NetworkCallback() {
override fun onAvailable(network: Network) {
val bound = connectivityManager.bindProcessToNetwork(network)
Log.i(TAG, "bound to VPN network: " + bound)
}
})Mae’r alwad yn newid y rhwydwaith diofyn ar draws y broses, felly mae pob soced a grëir wedyn yn ei ddefnyddio. Mae socedi sy’n bodoli eisoes yn cadw’r rhwydwaith y cawsant eu creu arno, a dyna pam y gall pwll cysylltiadau a agorwyd cyn y clymu barhau i ddatrys trwy’r hen lwybr. Boole yw’r gwerth a ddychwelir, ac mae canlyniad false yn golygu na ddigwyddodd y clymu; ceisiwch eto ar ôl oedi byr a chofnodwch y ddau gynnig.
Cam 3: Cyfyngu’r clymu i’r hyn sydd ei angen
Mae clymu ar draws y broses yn fras. Mae telemetreg, gwiriadau diweddaru a SDKau trydydd parti hefyd yn symud i’r twnnel, ac os nad oes rhyngrwyd gan y twnnel maent yn dechrau methu. Ar gyfer un cais, defnyddiwch ffatri socedi’r rhwydwaith a chadwch ddiofyn y ddyfais ar gyfer popeth arall. Dewiswch un model yn fwriadol: clymu cul fesul cysylltiad, neu glymu proses gyda dadglymu penodol pan fo’r VPN yn diflannu.
Gall dwy nodwedd ddatryswr drechu’r clymu heb unrhyw wall. Mae DNS preifat mewn modd llym yn anfon ymholiadau at weinydd DoT a enwir yn lle datryswr y rhwydwaith, ac mae ap sy’n cario ei gleient DNS-over-HTTPS ei hun yn osgoi datryswr y system yn gyfan gwbl. Gwiriwch y ddau cyn casglu bod y clymu wedi methu. Ni fydd ymholiad nad yw byth yn cyrraedd gweinydd DNS y VPN yn ymddangos mewn unrhyw log ar ochr y twnnel.
Cam 4: Peidiwch â rhoi ffydd mewn cyfyngiad CONNECTED
Mae NetworkType.CONNECTED WorkManager yn golygu bod rhwydwaith wedi cysylltu, ac mae cludiant y VPN yn ei fodloni hyd yn oed pan fo’r cyswllt Wi-Fi neu symudol sylfaenol wedi mynd. Mae’r gwaith yn rhedeg, mae pob cais yn methu, ac mae’r polisi ailgynnig yn ei droi’n storm sy’n edrych fel gwall amserlennu. Rhwydwaith yw’r twnnel; ni fu’r cyfyngiad erioed yn wiriad rhyngrwyd.
Gwiriwch y gallu y mae’r gwaith ei angen mewn gwirionedd, megis mynediad rhyngrwyd wedi’i ddilysu, a chadwch bolisi ailgynnig cyfyngedig gyda chilio. Os oes angen enw mewnol ar y gwaith, datryswch yr enw hwnnw yn y rhwydwaith a ddewiswyd cyn gwneud y gwaith, a methwch yn gyflym gyda gwall clir yn lle ailadrodd cais na all lwyddo.
Cam 5: Cofnodi’r dystiolaeth a phrofi’r amrediad eto
Cofnodwch fathau cludiant y rhwydwaith a ddewiswyd, y gweinyddwyr DNS o LinkProperties , a ddychwelodd y clymu true, a methiant union y cais cyntaf. Yna rhedwch enw mewnol ac enw cyhoeddus o dan yr un clymu. Mae’r pâr hwnnw’n dangos a ddefnyddiodd yr ap ddatryswr y twnnel neu a gwympodd yn dawel i ddiofyn y ddyfais, a dyna’r gwahaniaeth y mae’r defnyddiwr yn ei brofi.
Ailadroddwch ar y fersiwn Android hynaf a gefnogwch ac ar un fersiwn gyfredol. Ymddygiad y datryswr sy’n gwneud y llwybr diofyn i edrych yn gywir yw’n union lle mae dyfeisiau a fersiynau’n gwahaniaethu, ac nid yw adeiladwaith sy’n pasio ar y ddyfais brawf newyddaf yn unig wedi’i wirio ar gyfer yr amrediad a anfonwch. adb shell dumpsys connectivityyn ffordd gyflym o gadarnhau pa rwydweithiau a galluoedd y mae’r ddyfais yn eu hadrodd wrth i chi atgynhyrchu’r methiant.