Праграма Android адмаўляецца працаваць праз VPN: які ўзровень вырашае

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

Крок 1: высветліце, калі праграма адмаўляе

Час — першы адрознівальнік. Ачысціце буфер журнала, узнавіце збой і паглядзіце, што праграма рабіла перад тым, як паскардзілася:

adb logcat -c
# reproduce the failure in the app
adb logcat -d | grep -iE 'vpn|network|connect|http' | tail -60

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

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

Крок 2: прачытайце ўласны погляд тэлефона на сетку

Android паказвае стан VPN як магчымасць сеткі, таму праграме не патрэбны спіс камерцыйных правайдэраў, каб заўважыць актыўны тунель. Яна пытае службу злучэнняў, якая зараз сетка, і адказ змяшчае біт транспарту VPN:

val cm = context.getSystemService(ConnectivityManager::class.java)
val caps = cm.getNetworkCapabilities(cm.activeNetwork)
val onVpn = caps?.hasTransport(NetworkCapabilities.TRANSPORT_VPN) == true

Гэтая праверка лакальная і танна, і яна тлумачыць цэлы клас справаздач «гэтая праграма не працуе праз VPN» без усялякай аддаленай класіфікацыі. Тое, што праграма бачыць, усё яшчэ залежыць ад яе ўласнага сеткавага кантэксту, таму не думайце, што кожная праграма правярае кожны профіль на прыладзе.

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

Крок 3: прачытайце, што насамрэч бачыць сервер

Другі назіральнік — гэта служба. Яна бачыць адрас крыніцы, які прыходзіць, і можа дзейнічаць па адрасе, сетцы хостынгу за ім, рэгіёне, аператары або сігналах, звязаных з уліковым запісам і прыладай. Нішто з гэтага не з’яўляецца ўнікальнай асобай, а агульная адрасацыя робіць пабочныя блакіроўкі звычайнай справай: адзін абмежаваны адрас можа вывесці з ладу незвязаных карыстальнікаў за тым жа перакладам.

Атрымайце адрас тым жа шляхам, якім карыстаецца праграма, а не з браўзера на ноўтбуку. На тэлефоне просты запыт да службы рэха адрасу паказвае, што атрымлівае далёкі бок, а параўнанне з запытам праз мабільную сетку скажа вам, ці змяніўся адрас наогул.

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

Крок 4: суаднясіце доказы з адным з трох выракаў

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

Запішыце вырак разам з доказам, які яго спарадзіў. Каштоўнасць гэтага кроку ў тым, што ён спыняе цыкл, дзе хтосьці чатыры разы мяняе выхадныя вузлы, каб выправіць праверку, якая выконваецца на самім тэлефоне.

Гэта таксама трымае сцвярджэнні сумленнымі. Уласны хостынг змяняе канчатковы пункт і яго выхад у інтэрнэт; ён не прымушае Android забыцца, што сетка VPN актыўная, і не гарантуе прыняцця службай, якая класіфікуе адрасы. Лакальны фільтр можа спрацаваць на вашай уласнай сетцы VPN гэтак жа лёгка, як і на камерцыйнай.

Крок 5: ідзіце падтрыманым шляхам і праверце яго

Пачніце з дакументаванай палітыкі прадукту і яго ўладальніка падтрымкі. Дашліце версію кліента, дакладнае паведамленне і вузкае акно збою; не адпраўляйце поўныя запісы трафіку або ўліковыя даныя толькі каб даказаць, што памылка існуе.

Калі служба дазваляе прамы доступ і палітыка прылады гэта дазваляе, то выключэнне для асобнай праграмы — гэта падтрыманы механізм, і ён наўмысна выводзіць гэтую праграму з тунеля, а не хавае тунель. Тады трафік праграмы ідзе сваім шляхам, што з’яўляецца рашэннем палітыкі, якое нехта павінен узяць на сябе. У канфігурацыі, якая блакуе без VPN, выключаная праграма можа проста страціць злучэнне, таму праверце гэтую камбінацыю, перш чым абяцаць, што яна працуе.

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