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

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