Апликацијата за Android одбива да работи преку VPN: кој слој одлучува
Апликацијата може да одбие 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, исклучена апликација може едноставно да ја загуби поврзаноста, затоа тестирајте ја таа комбинација пред да ветите дека работи.
По секоја промена повторете го временскиот тест од првиот чекор, потврдете дека апликацијата работи и потврдете дека сите други апликации сè уште го користат тунелот. Потоа вратете ја претходната конфигурација и проверете дали дефектот се враќа, бидејќи поправка што не можете да ја репродуцирате е случајност што повторно ќе ја сретнете.