Почему трафик беспроводной отладки не доказывает утечку VPN

Вы включили беспроводную отладку, подключили ноутбук, и сессия продолжала работать, пока VPN был включён. Это выглядит так, будто что-то проскользнуло мимо туннеля. Почти наверняка нет. Сессия отладки и запрос приложения к сайту — разные сетевые отношения, и только одно из них должно пересекать туннель.

Я сталкивался с этим неверным прочтением дважды: один раз, когда телефон и ноутбук были в одной Wi-Fi, и один раз после перезагрузки, когда сопряжение сохранилось. В обоих случаях VPN делал именно то, для чего был настроен.

Назовите наблюдение, прежде чем называть ошибку

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

Обнаружение — это обычно mDNS или сканирование портов. Сопряжение — решение о регистрации, принятое на телефоне и подтверждённое кодом, который вводит пользователь. Живая сессия означает, что трафик шёл между двумя сопряжёнными конечными точками. Ничто из этого не описывает, куда идёт HTTPS-запрос приложения.

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

Почему два пути никогда не встречаются

Беспроводная отладка — это входящее соединение к устройству. adbd слушает порт, привязанный к Wi-Fi интерфейсу, а рабочая станция подключается к нему после сопряжения. Направление важно: ваш ноутбук дотягивается до телефона, а не наоборот. Это противоположность утечке на выходе.

Интернет-трафик приложения выходит через туннельный интерфейс, который устанавливает VpnService, с сопоставлением по UID и правилам маршрутизации. adbd — системный демон, работающий от пользователя shell, а не приложение внутри этого набора маршрутизации. Он остаётся на нижележащем Wi-Fi канале, даже когда каждое приложение привязано к туннелю.

Режим блокировки применяет туннель к охваченным приложениям. Он не превращает слушающий сокет в путь выхода.

Поэтому работающая сессия ADB и работающий выключатель существуют вместе без противоречия. Чтобы доказать утечку, нужно наблюдать направление, которое должно быть заблокировано.

Как на самом деле выглядит тест выхода

Тестируйте охваченное приложение, а не канал отладки. Намеренно создайте условие отказа, затем сделайте один новый запрос и запишите, что произошло.

1. Подтвердите, что VPN — единственный путь: включите постоянно включённый VPN с блокировкой соединений без VPN.
2. Остановите VPN поддерживаемым способом и подтвердите, что приложение сообщает об отсутствии подключения.
3. Отправьте один безобидный запрос из этого приложения и отметьте, завершается он неудачей или успехом.
4. Повторите с включённой, а затем выключенной беспроводной отладкой, чтобы изолировать переменную.

Заблокированный запрос в таких условиях — это доказательство. Успешная сессия ADB — нет, как и один ping из терминального приложения.

Если запрос всё же успешен при включённой блокировке, зафиксируйте UID приложения и его разрешение VPN, активную сеть и версию клиента. Такое сочетание — настоящая находка.

Сопряжение переживает сессию

Сопряжение — это постоянное состояние, а не рукопожатие, о котором можно забыть после теста с кабелем. Документация Android по отладке описывает беспроводной рабочий процесс и отмечает, что отношение сохраняется, пока о нём явно не забудут или пока разрешения не будут отозваны.

Проверьте, что ещё авторизовано, прежде чем винить туннель. Откройте Беспроводную отладку, посмотрите на Сопряжённые устройства и забудьте всё, что больше не узнаёте. Запустите adb devices с рабочей станции, чтобы увидеть, какие записи ещё отвечают, и adb disconnect, чтобы сбросить устаревшую. Выключение беспроводной отладки полностью закрывает слушающий порт.

В общей или недоверенной сети оставьте её выключенной. Постоянная авторизация в сети, которую вы не контролируете, — большая проблема, чем гипотетический обход TUN.

Прежде чем сообщать об этой ошибке

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

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

Если ваше единственное доказательство — то, что ADB подключился при включённом VPN, вы измерили не тот путь. Сначала повторите тест на уровне приложения; ответ обычно приходит там.