Маркер VPN на устройстве или адрес выхода: что что доказывает?
Сетевой маркер, прочитанный на устройстве, и адрес, который видит сервер, — разные доказательства. Решите, какое нужно вашему вопросу.
Приложение на телефоне и удалённый сервер начинают с разных фактов, и ни одно не может позаимствовать факты другого. Приложение может спросить операционную систему о сети, которую использует, тогда как сервер знает только то, что приходит по соединению. Запуск собственной конечной точки переписывает второе и оставляет первое нетронутым. Какое из них ответит на ваш вопрос, зависит от самого вопроса.
Две точки наблюдения, два вида доказательств
Локальные доказательства описывают устройство. Они охватывают интерфейс, несущий трафик, транспорт, о котором сообщает платформа, и то, что вызывающее приложение вправе запросить. Удалённые доказательства описывают соединение: адрес источника, протокол, время и всё, что приложение решит отправить. Ни одна точка наблюдения не является надмножеством другой.
Смешение двух даёт утверждения, которые звучат точно и не поддаются проверке. Маркер доказывает нечто о сетевом объекте на устройстве, а не о том, как удалённая служба классифицирует запрос.
Прежде чем спорить об обнаружении, запишите, какой точки касается вопрос. Речь о том, может ли конкретное приложение заметить, что туннель активен, или о том, может ли служба сделать вывод, откуда пришёл запрос? Это отдельные исследования, и ответ на одно ничего не говорит о другом.
Что может сообщить локальный интерфейс платформы
Android предлагает определённый маркер. Объект NetworkCapabilities может сообщать о TRANSPORT_VPN, а hasTransport проверяет, присутствует ли этот транспорт на объекте. Приложение получает объект от службы подключений и читает его с учётом разрешения на состояние сети.
Результат — локальная информация платформы, а не поиск по диапазонам адресов провайдера. Она описывает сеть, которую использует вызывающее приложение.
Важны два ограничения. Правило раздельного туннеля, исключающее приложение, может дать на том же телефоне иной ответ, чем видит коллега, потому что приложение может быть привязано в другом месте. Маркер существует ещё и потому, что ОС моделирует интерфейсы VPN, а не потому, что его собирает какое-то приложение. Читает ли приложение это поле, передаёт его дальше или игнорирует — это свойство самого приложения. Его манифест и документация — единственные надёжные источники по этому вопросу.
adb shell dumpsys connectivity | grep -i -m5 vpnЧто может видеть удалённая служба
Сервер видит адрес источника соединения, транспорт и время, и он может обогатить адрес данными реестра или маршрутизации. Он также может получить всё, что отправляет приложение, включая местоположение, когда приложение просит об этом, а пользователь соглашается. Эти каналы раздельны, и только один похож на поиск адреса.
Адрес, зарегистрированный на хостинг-провайдера, наводит на мысль о туннеле, а адрес, зарегистрированный в жилой сети, — о домашнем подключении. Оба — статистические подсказки, а не факты об устройстве.
Жилой адрес не помещает человека по этому адресу, а хостинговый адрес не называет оператора или страну. Служба, которая принимает вывод за уверенность, иногда будет ошибаться, не имея возможности это обнаружить. Если требуется надёжность, а не эвристика, данные адресов её не дадут, и проект, который это признаёт, честнее того, который скрывает догадку.
| Доказательство | На что отвечает | Чего не может показать |
|---|---|---|
| Локальный маркер транспорта | Является ли этот сетевой объект VPN | Кто управляет выходом или где находится устройство |
| Удалённый адрес источника | Какой адрес достиг службы | Несёт ли устройство также туннель |
| Полезная нагрузка приложения | Что приложение решило отправить | Всё, что приложение не отправило |
Почему самостоятельно размещённый выход меняет только одну сторону
Запуск собственной конечной точки меняет адрес источника, который видит удалённая служба, и это может вывести его за пределы диапазонов, которые служба связывает с коммерческими провайдерами. В локальной модели сети ничего не меняется, потому что туннель остаётся туннелем, и ОС по-прежнему сообщает о нём.
Одна сторона доказательств движется, другая остаётся неподвижной. Разрыв между ними — место, где ломаются ожидания.
Браузер — третий случай со своими интерфейсами и ограничениями. Веб-содержимое не может прочитать нативный объект возможностей, и считать функцию мобильной ОС доступной веб-странице — категориальная ошибка. Если вопрос касается сайта, изучите, что сайт действительно может получить, вместо того чтобы дословно переписывать API платформы.
Решайте, исходя из заданного вопроса
Если вопрос в том, может ли конкретное приложение наблюдать состояние туннеля, интерфейс платформы — правильное место для поиска, и ответ лежит в коде и разрешениях этого приложения. Если вопрос в том, что может вывести служба, доказательством служат метаданные соединения. Правовой или договорный вопрос не решает ни то, ни другое.
Назовите вопрос одним предложением, прежде чем что-либо собирать. Это предложение определяет, какая точка наблюдения важна, и не даёт исследованию уйти в другой спор.
Помечайте каждое наблюдение по его источнику, когда сообщаете о нём, потому что утверждение без пометки нельзя проверить. Локальный маркер и вывод из адреса оба полезны, и ни один не является окончательным, поэтому сливать их в один вердикт — ошибка.
Когда служба отклоняет авторизованное соединение, используйте поддерживаемый ею путь пересмотра, а не меняйте локальную настройку, чтобы скрыть сигнал. Удаление одного наблюдения никогда не доказывает, что остальные исчезли.