Прыкладанне Android не можа развязаць унутранае імя, хоць уласны браўзер VPN-кліента адкрывае яго, і той жа зборнік працуе на іншым тэлефоне. Зменная не URL. Зменная ў тым, якую сетку працэсу праграмы дазволена выкарыстоўваць для развязання, і Android не гарантуе, што актыўны VPN гэта менавіта тая сетка, якую выкарыстоўваюць вашыя сокеты. Выконвайце гэтыя праверкі па парадку і спыніцеся, калі здымак рэзалвера не супадае з вашым меркаваннем.

Крок 1: Дакажыце, у якой сетцы знаходзіцца праграма

Чытайце ўласны выгляд праграмы, а не радок стану. З ConnectivityManager атрымайце актыўную сетку, яе LinkProperties , спіс DNS-сервераў і наладу прыватнага DNS. Калі спіс змяшчае рэзалвер VPN, праграма мае шлях да яго; калі ён змяшчае рэзалвер Wi-Fi, тунель не зяўляецца сеткай па змаўчанні для гэтага працэсу.

Значок VPN кажа толькі, што тунель існуе. Ён не кажа, што працэс праграмы быў прывязаны да яго, і Android не заўсёды накіроўвае развязанне імёнаў праз сетку, якая выглядае актыўнай. Лакальныя VPN-праграмы, якія перасылаюць на іншую прыладу, сеткі Wi-Fi без інтэрнэту і зборкі вытворцаў могуць прымусіць праграму пытаць рэзалвер па змаўчанні замест сервераў тунелю.

Крок 2: Запытайце транспарт VPN і прывяжыце працэс

Калі праграме патрэбен рэзалвер тунелю, запытайце сетку з транспартам VPN і прывяжыце працэс у callback, каб код не здагадваўся, калі сетка зявіцца:

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)
    }
})

Выклік змяняе сетку па змаўчанні для ўсяго працэсу, таму кожны сокет, створаны пасля, выкарыстоўвае яе. Сокеты, якія ўжо існуюць, захоўваюць сетку, у якой былі створаны, таму пул злучэнняў, адкрыты да прывязкі, можа працягваць развязанне праз стары шлях. Вяртаемае значэнне boolean, і вынік false азначае, што прывязка не адбылася; паўтарыце спробу з кароткай затрымкай і запішыце абедзве спробы.

Крок 3: Абмяжуйце прывязку тым, што яе патрабуе

Прывязка на ўвесь працэс грубая. Тэлеметрыя, праверкі абнаўленняў і SDK трэціх бакоў таксама пераходзяць у тунель, і калі ў тунеля няма інтэрнэту, яны пачынаюць падаць. Для аднаго запыту выкарыстоўвайце фабрыку сокетаў сеткі, а для ўсяго астатняга пакіньце прыладу па змаўчанні. Свядома выберыце адну мадэль: вузкая прывязка на кожнае злучэнне або прывязка працэсу з яўным адвязаннем, калі VPN знікае.

Дзве функцыі рэзалвера могуць перамагчы прывязку без любой памылкі. Прыватны DNS у строгім рэжыме адпраўляе запыты на названы сервер DoT замест рэзалвера сеткі, а праграма з уласным кліентам DNS-over-HTTPS цалкам абыходзіць сістэмны рэзалвер. Праверце абодва, перш чым заключыць, што прывязка не ўдалася. Запыт, які ніколі не дасягае DNS-сервера VPN, не зявіцца ні ў якім журнале з боку тунелю.

Крок 4: Не давярайце абмежаванню CONNECTED

У WorkManager NetworkType.CONNECTED азначае, што сетка падключана, і транспарт VPN задавольвае яго нават тады, калі асноўнае злучэнне Wi-Fi або сотавае знікла. Заданне выконваецца, кожны запыт падае, і палітыка паўтораў ператварае гэта ў шторм, які выглядае як памылка планавання. Тунель гэта сетка; абмежаванне ніколі не было праверкай інтэрнэту.

Праверце магчымасць, якая сапраўды патрэбна заданню, напрыклад пацверджаны доступ да інтэрнэту, і трымайце абмежаваную палітыку паўтораў з адыходам. Калі заданню патрэбна ўнутранае імя, развяжыце гэтае імя ў выбранай сетцы перад выкананнем працы і хутка падзіце з яснай памылкай замест паўтору запыту, які не можа ўдацца.

Крок 5: Запішыце доказы і пераправерце дыяпазон

Запішыце тыпы транспарту выбранай сеткі, DNS-серверы з LinkProperties , ці вярнула прывязка true, і дакладную памылку першага запыту. Затым запусціце ўнутранае імя і публічнае імя пад адной прывязкай. Гэтая пара паказвае, ці выкарыстала праграма рэзалвер тунелю, ці моўчкі вярнулася да прылады па змаўчанні, і менавіта гэтую розніцу адчувае карыстальнік.

Паўтарыце на самай старой версіі Android, якую вы падтрымліваеце, і на адной актуальнай версіі. Паводзіны рэзалвера, якія робяць шлях па змаўчанні правільным, менавіта тое, чым адрозніваюцца прылады і версіі, і зборка, якая праходзіць толькі на найноўшай тэставай прыладзе, не праверана для дыяпазону, які вы пастаўляеце. adb shell dumpsys connectivityхуткі спосаб пацвердзіць, якія сеткі і магчымасці паведамляе прылада, пакуль вы аднаўляеце збой.

Падобныя артыкулы