Режим SOCKS в NetGuard покрывает TCP, а не каждый протокол

NetGuard занимает VPN-интерфейс Android, чтобы фильтровать трафик, и может передавать поддерживаемые соединения в конечную точку SOCKS. Эти два факта часто читают как «телефон в VPN», хотя такой вывод механизм не поддерживает. Фильтр видит пакеты; прокси видит только те соединения, которые ему действительно передали. Между этими двумя утверждениями и стоит весь вопрос о покрытии.

FAQ исходного проекта документирует и ограничение одной службой, и возможность SOCKS. Наличие возможности не доказывает, что её использует каждый разрешённый пакет, и вопросы о покрытии возникают именно из этого разрыва.

Два пути пересылки внутри одного приложения

В TCP-стороне реализации есть обработка соединений SOCKS, поэтому разрешённое TCP-соединение можно согласовать с прокси и провести через него. У UDP-стороны отдельный путь сокета, и её обработка отправки и приёма не зависит от этого согласования TCP. Поэтому датаграмма, которую фильтр разрешает, может попасть в обычную сеть, ни разу не пройдя через прокси. Ничто в этом не является дефектом приложения; это просто то, что реализуют два пути.

У этого различия есть следствие, которое люди неверно описывают в обе стороны. Называть каждую UDP-датаграмму утечкой — значит игнорировать правила блокировки, потому что отклонённая датаграмма никогда не выходит. Называть всю схему VPN — значит игнорировать разрешённый прямой путь, потому что часть трафика действительно выходит без прокси. То, что у вас есть, — это фильтруемое устройство с частичным прокси, и честное описание — матрица, а не ярлык.

Заявлять UDP — не значит реализовать его

SOCKS-сервер, который заявляет поддержку UDP, не добавляет соответствующую клиентскую обработку в приложение на вашем телефоне. Теоретические свойства протокола и поведение установленной сборки — разные темы, и только вторая описывает ваш трафик.

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

DNS — третий путь, а не деталь

Разрешение имён добавляет в матрицу собственную ветвь. Локальный DNS-форвардер, обычный UDP-запрос, имя хоста назначения, разрешаемое самим прокси, и зашифрованный резолвер в браузере — это четыре разные схемы. Они различаются тем, кто видит запрос и какой сетевой путь его несёт, и их смешение даёт тест, который ничего не доказывает об остальных.

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

Транспорт через прокси не становится приватным автоматически

Обычный SOCKS — это не зашифрованный канал от телефона до прокси. Если конечная точка достигается по другому защищённому пути, назовите этот путь и его политику отказа, потому что откат в открытую сеть без предупреждения делает приватную схему публичной. Важна и собственная аутентификация прокси: открытый слушатель на общем устройстве — это служба, за которую никто не отвечает.

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

Проводите аудит покрытия матрицей, а не загрузкой страницы

Для авторизованной оценки выберите безвредные примеры, представляющие каждый важный для вас класс: требуемый TCP, разрешённый UDP и DNS в обоих семействах адресов. Для каждого запишите, прошёл ли он через прокси, был ли заблокирован или отправлен напрямую. Эта единственная таблица и есть результат, и она гораздо полезнее скриншота загруженной страницы.

Если требование в том, чтобы весь выбранный трафик приложений проходил через удалённый туннель, выберите реализацию с явно поддерживаемыми совместными фильтрацией и туннелированием. Схема только с TCP-прокси остаётся полезной для узких задач при условии, что остальной трафик обрабатывается намеренно, а не забыт.