Як читати стан VPN і проксі керованого робочого застосунку

Значок VPN на керованому телефоні доводить дуже мало. Прочитайте активну мережу, її можливості й чинний проксі, а потім читайте кожен null таким, яким він є.

Робочий застосунок збоїть на керованому телефоні, хтось перевіряє перемикач VPN, бачить, що він увімкнений, і оголошує шлях здоровим. Тут зупиняється більшість таких діагностик, і це занадто рано: активний транспорт VPN не каже, що запити цього застосунку йшли через нього, а проксі, який реально застосовується, може бути для окремого застосунку або обраний файлом PAC, а не показаний у Налаштуваннях. Почніть із конкретного застосунку й профілю, які ви налагоджуєте, потім прочитайте власний погляд платформи на шлях.

Почніть із застосунку та його профілю

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

У Налаштуваннях перелічіть налаштовані записи VPN і позначте, кому належить кожен. У збірках Samsung підписи меню зміщуються між випусками, тому описуйте запис, а не шлях до нього. Сірий або керований запис належить тому, хто адмініструє пристрій; його вимкнення як експеримент змінює те, що ви намагаєтеся виміряти, і може суперечити політиці.

Прочитайте стан, який повідомляє платформа

Усередині наявної активності у ваших засобах підтримки, на API 23 або новішому, стан мережі можна прочитати, не надіславши жодного байта. Виклику потрібен звичайний дозвіл маніфесту ACCESS_NETWORK_STATE для читання можливостей.

val cm = getSystemService(android.net.ConnectivityManager::class.java) ?: return
val network = cm.activeNetwork
val caps = network?.let { cm.getNetworkCapabilities(it) }
val hasVpn = caps?.hasTransport(android.net.NetworkCapabilities.TRANSPORT_VPN)
val proxy = cm.defaultProxy

Кожне значення відповідає на вузьке питання. Активна мережа — це мережа за замовчуванням для процесу, що викликає, у той момент. Перевірка можливостей повідомляє, чи підтримується ця мережа за замовчуванням VPN. Виклик проксі повідомляє чинний проксі HTTP за замовчуванням, а повернутий об'єкт може описувати або статичний проксі, або скрипт PAC.

Якщо вам потрібен огляд за кожною мережею замість стандартного, прочитайте властивості з'єднання тієї ж мережі та порівняйте з cm.getLinkProperties(network)?.httpProxy. Проксі, встановлений керуванням пристрою, з'являється у виклику проксі за замовчуванням і не з'являється у властивостях з'єднання, і це швидкий спосіб відрізнити проксі, заданий політикою, від наданого мережею.

Тримайте вивід у своєму каналі підтримки, а не в публічному звіті. Імена вузлів проксі, адреси PAC і внутрішні суфікси розкривають, як ваша організація спрямовує трафік, і ніщо з цього не потрібне для опису збою.

Тлумачте кожне поле вузько

Нульова мережа або нульовий об'єкт можливостей означає, що стан мережі того, хто викликає, був недоступний або змінився під час читання. Це не означає, що VPN немає. Вважайте це невідомим і прочитайте знову після того, як застосунок вийшов на передній план, а не негативним результатом.

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

Нульовий проксі за замовчуванням означає, що цей API не повідомляє жодного проксі HTTP за замовчуванням для чинної конфігурації. Він виключає дуже мало: застосунок може мати власне налаштування SOCKS, реалізовувати власний клієнт HTTP або керуватися проксі на шлюзі, про який пристрій ніколи не дізнається.

PAC — це випадок, який перемагає відповідь з одним значенням. Скрипт може спрямувати одне призначення через проксі, а інше надіслати напряму, тож два запити одного застосунку протягом секунди можуть піти різними шляхами. А застосунок, що прив'язує свої сокети до вибраної мережі або викликає bindProcessToNetwork, зовсім не зобов'язаний дотримуватися значення за замовчуванням.

Чого цей знімок не може вам сказати

Це не історія. Тут ніщо не записує, яким шляхом ішов збійний запит, а успішне читання після збою не є доказом про збій. Це й не опис: ви отримуєте мережу за замовчуванням процесу, що викликає, а не список приватних з'єднань кожного застосунку.

Він також нічого не каже про те, що відбувається над сокетом. Рукостискання TLS, що збоїть на керованому пристрої, може бути проблемою сховища довіри, невідповідністю закріплення або іменем, яке проксі відхиляє, і ніщо з цього не з'являється в читанні зв'язності.

Тому обидві половини важливі разом: знімок звужує, де шукати, а власна діагностика застосунку каже, що саме збійло.

Повідомте це у формі, яку адміністратор зможе використати

Укажіть уражений застосунок, профіль, позначку часу й точний етап, що збій: розв'язання імен, з'єднання TCP, рукостискання TLS або статус HTTP. Додайте значення знімка такими, якими їх прочитано, записавши нулі як нулі, а не як слово нічого. Позначте, чи інші застосунки в тому ж профілі збоять так само, що відокремлює проблему застосунку від проблеми шляху в усьому профілі.

Потім зупиніться і дайте власникові шляху відповісти. Не сприймайте корпоративний сертифікат, адресу проксі або запис VPN як дозвіл прибрати керування чи обійти затверджений маршрут; це перетворює випадок підтримки на інцидент політики.

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

Схожі статті