Чому трафік бездротового налагодження не доводить витік 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 був увімкнений, ви виміряли не той шлях. Спершу повторіть тест на рівні застосунку; відповідь зазвичай приходить там.