Мы провели своё расследование. Айфонам приготовиться!

Формулировка «на iPhone VPN не отслеживается» технически неверна. Правильнее говорить так:

на iPhone обычному приложению сложнее получить жёсткий и официальный признак VPN, чем на Android, но сделать достаточно надёжный вывод о наличии VPN во многих случаях всё равно можно.

CFNetworkCopySystemProxySettings() сам по себе не «читает TUN-пакеты» и не «сканирует VPN как отдельное приложение».

Он делает более приземлённую вещь: возвращает системные сетевые настройки, в том числе настройки прокси. А уже по устройству сетевого стека, по списку интерфейсов и по косвенным признакам в этом словаре приложение может понять, что трафик идёт через туннель, то есть через виртуальный сетевой интерфейс VPN.

Это не прямое «я увидел VPN-процесс», а сетевой вывод по конфигурации ядра и маршрутизации.

Когда приложение само является VPN-клиентом или имеет соответствующие права через NetworkExtension, оно может официально управлять VPN-конфигурацией и знать её состояние через NEVPNManager и NEVPNConnection. Но такой доступ не у всех приложений, а у тех, кому он реально выдан и кто работает с VPN-функциями легально.

Обычное приложение может не видеть «название VPN-приложения», но способно посмотреть на состояние сетевых интерфейсов и понять, что поверх обычного Wi‑Fi или мобильной сети появился туннельный интерфейс.

Есть ещё более низкоуровневый путь. На Apple-платформах доступна стандартная функция getifaddrs(), которая возвращает список сетевых интерфейсов процесса. Это уже не CFNetwork, а более базовый уровень BSD-сетей.

На Android ситуация грубее и прямолинейнее. У Google это почти официально признанный сценарий: приложение может через ConnectivityManager получить NetworkCapabilities и проверить TRANSPORT_VPN.

То есть на Android система прямо даёт разработчику более удобный признак: текущая активная сеть относится к типу VPN.

Для обычного приложения на Android сам факт VPN действительно виден довольно легко, а вот IP самого VPN-сервера, то есть удалённого шлюза, обычно не выдаётся напрямую обычному приложению через публичные API.

У Android есть очень удобный для разработчика механизм: NetworkCapabilities.hasTransport(TRANSPORT_VPN). Это означает буквально следующее: система умеет сообщить приложению, что данная сеть использует транспорт VPN. Кроме этого, у Android есть LinkProperties. Это объект, который хранит свойства сетевого канала.

Если VPN поднят как системная сеть, приложение часто может увидеть саму сеть типа VPN. Но если конкретное приложение выведено в обход VPN, то его собственный трафик может идти по обычной сети, а не по туннелю.

Если VPN использует не чистый TUN-туннель, а ещё и задаёт HTTP-прокси через VpnService.Builder.setHttpProxy(), тогда приложение может через LinkProperties.getHttpProxy() получить ProxyInfo. А в ProxyInfo уже может быть виден конкретный хост и порт прокси.

Короче говоря split tunneling даёт понять что:
- понять, что VPN на устройстве вообще поднят
- понять, идёт ли его трафик через VPN или напрямую
- увидеть внешний IP, с которого пришёл запрос на сервер
- увидеть DNS или прокси-настройки в некоторых сценариях