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-а изузета апликација може једноставно да изгуби повезивост, зато тестирајте ту комбинацију пре него што обећате да ради.

Након сваке промене поновите тест времена из првог корака, потврдите да апликација ради и да све остале апликације и даље користе тунел. Затим вратите претходну конфигурацију и проверите да ли се квар враћа, јер поправка коју не можете да репродукујете је случајност коју ћете поново срести.