Приложение за 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, изключено приложение може просто да загуби свързаност, така че тествайте тази комбинация, преди да обещаете, че работи.

След всяка промяна повторете теста за време от първата стъпка, потвърдете, че приложението работи, и потвърдете, че всяко друго приложение все още използва тунела. След това възстановете предишната конфигурация и проверете дали отказът се връща, защото поправка, която не можете да възпроизведете, е съвпадение, което ще срещнете отново.