Как читать состояние VPN и прокси управляемого рабочего приложения

Рабочее приложение сбоит на управляемом телефоне, кто-то проверяет переключатель 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 как разрешение убрать управление или обойти утверждённый маршрут; это превращает случай поддержки в инцидент политики.

Договор о прокси по умолчанию короток и заслуживает одного прочтения, потому что он точно определяет, о каком прокси сообщает вызов, и каждое чрезмерное прочтение этого снимка начинается с допущения, что он сообщает больше.