TUN и системный прокси представляют два разных способа ввода трафика: захват IP-пакетов и сотрудничество приложения. Интерфейс TUN получает пакеты, выбранные маршрутами операционной системы, а системный прокси остаётся настройкой, которую программа может учитывать, переопределить или игнорировать; обход возникает, когда поток вовсе не входит в выбранный механизм.［1］［2］［3］

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

Ключевые выводы

TUN работает с маршрутизируемыми IP-пакетами, а системный прокси — с приложениями, которые его поддерживают.

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

TUN охватывает больше, но зависит от маршрутов, IPv4/IPv6, исключений приложений, DNS и сетевых пространств.

Публичный IP надо проверять несколькими программами и для обоих семейств адресов.

Исправляйте установленный слой отказа, а не меняйте одновременно протокол, сервер и прокси.

Как TUN и системный прокси получают трафик?

TUN — виртуальный интерфейс третьего уровня. Операционная система направляет туда выбранные IP-пакеты по действующей политике. Android описывает, как VPN-приложение читает исходящие пакеты, переносит их через защищённый сокет и возвращает расшифрованные входящие пакеты в интерфейс.［1］

Системный прокси — это конфигурация, которую читает программное обеспечение. Браузер или сетевая библиотека может узнать прокси для URL, пройти аутентификацию и отправить поддерживаемый запрос. PAC способен вернуть цепочку прокси или DIRECT. Настройка не перехватывает физически каждый сокет компьютера.［3］

Вопрос	Режим TUN	Системный прокси
Кто выбирает трафик	Маршруты и VPN-политика	Приложение или его сетевая библиотека
Что поступает на вход	Выбранные IP-пакеты	Поддерживаемые запросы и соединения
Прямой сокет	Обычно подчиняется маршруту	Может полностью игнорировать прокси
UDP	Возможен при поддержке туннеля	Зависит от прокси и клиента
IPv6	Нужны IPv6-маршруты и реализация	Зависит от разрешения имени и пути приложения
DNS	Может маршрутизироваться или назначаться отдельно	Бывает локальным, проксируемым или встроенным
Исключения	Маршрут, приложение, адрес или политика платформы	PAC `DIRECT`, список исключений прокси либо собственная настройка программы

Почему приложения обходят системный прокси?

Чаще всего программа просто не читает системный параметр. Она может открыть TCP- или UDP-сокет напрямую, использовать собственную среду выполнения, брать переменные окружения вместо настроек рабочего стола либо продолжать ранее установленное соединение. Поэтому успешная страница в браузере ничего не доказывает о другой программе.

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

Ещё одна причина — намеренные исключения. PAC возвращает DIRECT для совпавших URL, а системные параметры часто исключают локальные имена или диапазоны. Кэш PAC, приоритет профиля и ошибка учётных данных могут дать различный результат в программах с одинаково отображаемым адресом прокси.［3］

Какой трафик чаще показывает эту границу?

Голосовые приложения, игры, обнаружение устройств и клиенты реального времени часто используют UDP. Обычный HTTP-прокси автоматически его не переносит. Некоторые реализации SOCKS поддерживают проброс UDP (UDP ASSOCIATE), но это должны уметь клиент и сервер, а DNS всё ещё может идти другим путём.

Не-HTTP TCP иногда работает через CONNECT, если клиент запрашивает туннель и сервер разрешает назначение. Программа, рассчитанная на прямые сокеты, не научится работать через прокси после включения системного флажка. Это граница интеграции, а не доказательство отказа шифрования.

Почему режим TUN тоже может пропустить поток?

Захват TUN определяется маршрутами. Если профиль добавил лишь отдельные префиксы, прочие назначения останутся на обычном интерфейсе. Microsoft показывает, что специфичность и метрика маршрутов влияют на выбор VPN, а принудительная и раздельная схемы устанавливают разные маршруты по умолчанию.［2］

Частая причина — неполное семейство адресов. Маршрут IPv4 через TUN не захватывает IPv6 автоматически. Двухстековый сервис может поэтому показывать разные пути между программами или попытками. Проверьте активные таблицы маршрутов IPv4 и IPv6 и адрес, который фактически был выбран для соединения.

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

Может ли DNS обойти TUN?

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

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

Как диагностировать обход приложения?

Начните с воспроизводимой пары: одна программа выглядит защищённой, другая — прямой. Используйте одинаковое назначение, время, семейство адресов и сеть. Разные сайты не позволяют изолировать механизм захвата.

Для прокси проверьте источник активной настройки, переопределения в самом приложении, результат PAC, список исключений, аутентификацию и необходимость перезапуска. Для TUN проверьте интерфейс, префиксы, метрики, исключения приложений, оба семейства адресов и исключение сокета туннеля из рекурсии.

Классифицируйте поток: TCP или UDP, IP и порт назначения, путь DNS, локальная или удалённая область, новое или повторно используемое соединение. Ситуацию, когда VPN работает в браузере, но не в программе, легче объяснить после фиксации этих данных.

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

Что включить в надёжную матрицу тестов?

Создайте строки для браузера, клиента командной строки, фоновой службы и контролируемого UDP-инструмента. Столбцы: системный прокси, TUN, отключённое состояние, IPv4, IPv6, результат DNS, внешний адрес и ожидаемый локальный доступ. Неподдерживаемую комбинацию отмечайте отдельно, а не как сбой.

До и после теста сохраняйте локальные доказательства: маршруты, интерфейс, источник параметра прокси, решение PAC и очищенные журналы приложения. Серверный журнал подтверждает получение запроса, но отсутствие записи может означать более раннюю ошибку DNS или маршрута.

Условие успеха формулируйте как политику: «все управляемые приложения используют туннель, кроме разрешённой службы обновления». Фраза «VPN работает» непроверяема. Также задайте поведение при отказе: разрешён ли прямой путь при сбое, остаются ли локальные сервисы и должны ли закрываться старые сокеты.

Когда использовать каждый способ?

TUN подходит, если правило относится к нескольким программам, клиентам без поддержки прокси, UDP или устройству целиком. За широкий охват приходится управлять маршрутами, DNS, жизненным циклом интерфейса, MTU и безопасным отказом.

Системный прокси подходит для явно ограниченного набора совместимых программ, когда прямой путь остальных допустим и полезны решения на уровне запроса. Если модель угроз требует блокировки при сбое (fail closed), документируйте запрет тихого перехода на DIRECT.

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

Описывает ли модель TUN и системного прокси AethoVPN?

Для контролируемого теста с AethoVPN подключитесь с включённым глобальным режимом и отдельно проверьте три вещи: тест утечек в браузере, резолвер, который показывает тест утечки DNS, и консольную утилиту или приложение, игнорирующее системный прокси. Если все три выходят через выбранную локацию, вы наблюдали охват всей системы, но документация AethoVPN не уточняет, достигается ли он через TUN-интерфейс, прокси или их сочетание, поэтому записывайте результат, а не механизм. Начните 3-дневный бесплатный пробный период, чтобы выполнить эти три проверки.

Итоги

Режим TUN захватывает маршрутизируемые IP-пакеты, а системный прокси зависит от того, использует ли его конкретная программа.
Прямые сокеты, собственные настройки приложений, ограничения UDP и правила DIRECT часто объясняют обход прокси.
Область TUN зависит от маршрутов, адресных семейств, исключений, пространств имён и DNS.
Сравнивайте одинаковые назначения в нескольких программах и меняйте одну переменную за раз.
Прежде чем считать результат успехом или обходом, запишите явные правила охвата и поведения при сбое.

Часто задаваемые вопросы (FAQ)

Гарантирует ли TUN, что ни одно приложение не обойдёт VPN?

Нет. Исключения платформы, пробелы в маршрутах, другое сетевое пространство имён, IPv6, локальные маршруты или привилегированное поведение могут создать иной путь. Гарантию нужно оценивать по фактической политике платформы и состоянию маршрутов.

Почему браузер использует прокси, а игра — нет?

Браузер умеет работать через прокси, а игра может открывать прямые TCP- или UDP-сокеты. Проверьте, какие настройки прокси поддерживает сама игра и какие типы трафика ей нужны, а не предполагайте, что она наследует конфигурацию браузера.

Системный прокси — это split tunneling?

Нет. Системный прокси — лишь один механизм входа трафика. Он может дать разделённый результат, потому что одни приложения его используют, а другие подключаются напрямую, но раздельное туннелирование может строиться также по приложениям, маршрутам, адресам назначения или доменам.

Можно ли использовать TUN и прокси вместе?

Да. Клиент может захватывать IP-пакеты через TUN и преобразовывать подходящие потоки в прокси-стек. Захват, протокол прокси, транспорт, маршрутизация и DNS остаются разными слоями.

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

Профиль может захватывать только IPv4, либо приложение иначе разрешает имя и соединяется по IPv6. Изучите обе таблицы маршрутов и проверьте одно и то же двухстековое назначение, записывая полученные адреса.

Надо ли перезапускать программу после смены прокси?

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

Всегда ли прямой обходной путь при сбое является утечкой?

Утечкой он является только тогда, когда нарушает заявленную политику. Прямой доступ может быть намеренным решением ради доступности исключённых приложений или локальных сервисов. Требование «при сбое блокировать» (fail closed) должно явно запрещать такой обход и проверяться тестами.

Отказ от ответственности: Материал содержит общую информацию о сетях. Соблюдайте правила сетей, устройств и сервисов, которыми вы управляете.

Источники:

Android Developers, “VpnService”: https://developer.android.com/reference/android/net/VpnService
Microsoft Learn, “VPN routing decisions”: https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/vpn/vpn-routing
MDN Web Docs, “Proxy Auto-Configuration file”: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file

Sources checked 12 сентября 2026 г.

Рекомендуемые статьи:

TUN и системный прокси: почему приложения обходят VPN