TUN mode — это режим, в котором VPN или proxy-клиент создает виртуальный сетевой интерфейс и получает от операционной системы IP-пакеты. Для пользователя это выглядит как «весь трафик идет через приложение», но технически TUN не является отдельным VPN-протоколом. Это локальный способ забрать трафик из сетевого стека устройства, обработать его в программе и отправить дальше через WireGuard, OpenVPN, VLESS, Shadowsocks, Trojan, sing-box outbound или другой транспорт.
Главное отличие от обычного proxy в том, что приложению не нужно уметь SOCKS5 или HTTP proxy. Браузер, мессенджер, игра, системное обновление или DNS-запрос могут попасть в TUN потому, что сама ОС направила пакет в виртуальный интерфейс. Поэтому TUN удобен, когда нужен режим «как VPN для всего устройства», но он же чаще ломается из-за прав, маршрутов, DNS, IPv6, MTU и конфликтов с другими сетевыми программами.
#TUN, TAP и system proxy: в чем разница
В Linux-документации TUN/TAP описывается как виртуальное сетевое устройство для программ пользовательского пространства. Разница важна: TUN работает с IP-пакетами на сетевом уровне, а TAP работает с Ethernet-кадрами на канальном уровне. В потребительских VPN-клиентах чаще нужен TUN, потому что для маршрутизации интернет-трафика достаточно IP-пакетов. TAP встречается в сценариях, где нужна имитация Ethernet-сети, мосты, broadcast/multicast или специфическая корпоративная сеть.
| Режим | Что перехватывает | Когда подходит | Типичный риск |
|---|---|---|---|
| System proxy | Запросы приложений, которые уважают системный HTTP/SOCKS proxy. | Браузер, IDE, отдельные программы, простая диагностика. | Часть приложений идет напрямую, UDP и DNS могут обходить proxy. |
| TUN | IP-пакеты, которые ОС отправила в виртуальный интерфейс. | Весь телефон или ноутбук, приложения без proxy, UDP, системная маршрутизация. | Ошибки маршрутов, DNS leak, конфликт VPN, недоступная локальная сеть. |
| TAP | Ethernet-кадры уровня L2. | Мосты, старые корпоративные схемы, задачи с Ethernet-сегментом. | Сложнее, больше служебного трафика, не всегда поддерживается мобильными ОС. |
Поэтому фраза «TUN лучше proxy» слишком грубая. TUN шире по охвату, но шире и зона последствий. Неверное direct-правило может отправить чувствительный домен мимо туннеля, неверный DNS final может раскрыть запросы провайдеру, а конфликт виртуальных адаптеров может оставить устройство без сети.
#Как проходит трафик в TUN mode
- Клиент создает виртуальный интерфейс. В системе появляется TUN-адаптер или системный VPN-интерфейс с локальным адресом, например из приватного диапазона.
- ОС получает маршруты. Клиент добавляет маршруты: весь трафик, только выбранные подсети или исключения для локальной сети.
- Приложение отправляет обычный пакет. Браузер или мессенджер не знает про proxy; он просто подключается к IP-адресу.
- Пакет попадает в TUN. ОС передает пакет клиенту, потому что маршрут указывает на виртуальный интерфейс.
- Клиент применяет DNS и route rules. Он решает, отправить соединение через proxy/VPN outbound, напрямую, заблокировать или обработать DNS отдельно.
- Исходящее соединение уходит наружу. Клиент должен отправить его через реальный сетевой интерфейс, а не обратно в TUN; иначе возникает routing loop.
В современных proxy-клиентах это особенно заметно. Удаленный протокол может быть VLESS или Shadowsocks, но локально приложение работает как VPN: поднимает TUN, читает IP-пакеты и собирает из них TCP/UDP-соединения для дальнейшей отправки. Пользователь видит одну кнопку «VPN mode», хотя внутри это связка TUN, DNS, routing и конкретного outbound.
От теории к подключению
От понимания к подключению
Если вы уже разобрались, зачем нужен VPN, можно получить данные для подключения и настроить доступ по инструкции.
#Когда TUN действительно нужен
- Нужно покрыть весь телефон или ноутбук. Если трафик должны отправлять через туннель браузер, мессенджеры, почта, игры и фоновые приложения, system proxy обычно недостаточен.
- Приложение игнорирует proxy. Многие мобильные приложения, игры, системные службы и некоторые desktop-программы не используют системный proxy.
- Нужен UDP. Звонки, игры, QUIC/HTTP3 и DNS поверх UDP часто требуют режима, который работает ниже уровня HTTP proxy.
- Нужна маршрутизация по подсетям. Корпоративные сети, домашний NAS, роутер, приватные адреса и split tunneling удобнее описывать маршрутами.
- Нужен kill switch или always-on. На мобильных ОС системный VPN-режим может блокировать прямой трафик вне туннеля, если это поддержано и включено.
#Когда TUN лучше не включать
TUN не стоит включать «на всякий случай», если задача узкая. Для одного браузера, API-теста, парсинга, IDE или отдельного приложения с SOCKS5 проще использовать proxy. Так меньше шанс случайно сломать локальную сеть, DNS, банковское приложение, Docker, VirtualBox, корпоративный агент или другой VPN.
Отдельно осторожно с чужими готовыми конфигами. В TUN-конфиге правила могут направлять часть доменов напрямую, исключать подсети, менять DNS, включать FakeIP, блокировать трафик или подключать удаленные списки правил. Это уже не просто «адрес сервера», а политика маршрутизации устройства.
#Android: VpnService, маршруты и per-app
На Android пользовательские VPN-приложения работают через системный VpnService. Документация Android показывает, что приложение задает локальный адрес TUN-интерфейса через addAddress() и маршруты через addRoute(). Если добавить открытый маршрут 0.0.0.0/0 или ::/0, система отправляет через VPN весь соответствующий IPv4 или IPv6 трафик.
Android также поддерживает per-app VPN: клиент может задать список разрешенных или исключенных приложений. Если список не задан, система отправляет сетевой трафик приложений через VPN. Это полезно для split tunneling, но создает типичные недоразумения: пользователь думает, что TUN включен для всех, а клиент исключил банк, магазин приложений, локальную сеть или captive portal.
- Системное разрешение VPN обязательно. Android показывает диалог, потому что приложение получает право обрабатывать сетевой трафик.
- Одновременно обычно активен один VPN. Другой VPN-клиент, ad blocker или firewall на базе VpnService может конфликтовать.
- Always-on и блокировка без VPN меняют поведение. Если включена блокировка трафика вне VPN, ошибки маршрутов выглядят как полный обрыв интернета.
- Большие route-set могут быть проблемой. sing-box отдельно отмечает, что route address set не работает в Android graphical client из-за ограничений VpnService при большом числе маршрутов.
- Private DNS влияет на диагностику. Системный DoT/Private DNS, DNS внутри клиента и hijack-dns могут конфликтовать или давать неожиданный результат.
#Windows: адаптер, права и DNS
На Windows TUN-режим обычно требует установки или использования виртуального сетевого адаптера и прав, достаточных для изменения маршрутов. Проблемы часто появляются после сна, смены Wi-Fi, обновления клиента, параллельного VPN, VirtualBox/Hyper-V/Docker или корпоративного endpoint-агента.
Отдельная тема — DNS. Windows может иметь несколько активных интерфейсов и сложную логику разрешения имен. В документации sing-box для strict_route прямо указано, что на Windows эта опция помогает предотвращать DNS leak, связанный с ordinary multihomed DNS resolution behavior, но может мешать некоторым приложениям, например VirtualBox. Поэтому «включить strict_route всегда» не универсальный совет: нужно понимать, что важнее в конкретной сети — жесткая изоляция или совместимость.
- Запускайте клиент с правами, которые он сам требует для TUN; без них маршруты и адаптер могут не создаться.
- Проверяйте, что активен только один VPN/TUN-клиент, если симптомы похожи на конфликт маршрутов.
- После сна или смены сети перезапустите подключение: старые маршруты и DNS могут остаться в неконсистентном состоянии.
- Если ломается локальная сеть, проверьте исключения для приватных подсетей, принтера, NAS, роутера и корпоративных адресов.
- Если есть DNS leak, смотрите не только DNS-сервер, но и порядок интерфейсов, split tunneling, IPv6 и strict routing.
#macOS и iOS: Network Extension и Packet Tunnel
На Apple-платформах VPN-клиенты обычно используют системные механизмы Network Extension и Packet Tunnel. Для пользователя это похоже на Android: система показывает VPN-подключение, приложение получает поток пакетов, а правила определяют, какие приложения, домены и маршруты пойдут через туннель. В управляемых устройствах могут использоваться per-app VPN, on-demand правила и профили конфигурации.
На macOS дополнительно возможны конфликты с фильтрами, firewall, корпоративными агентами, Docker/виртуализацией и приватными relay/DNS-настройками. На iOS пользователь не может так же свободно чинить маршруты терминалом, поэтому диагностика чаще сводится к обновлению клиента, проверке профиля, исключений, DNS и системных VPN-настроек.
#Linux: /dev/net/tun, CAP_NET_ADMIN и маршруты
На Linux TUN ближе всего виден «как есть». Программа открывает /dev/net/tun, создает сетевое устройство, получает или пишет IP-пакеты, а маршруты и правила решают, что попадет в этот интерфейс. Документация ядра указывает, что для создания или подключения к чужому сетевому устройству нужны соответствующие права, например CAP_NET_ADMIN.
В практических VPN/proxy-клиентах это означает: контейнеру может не хватать доступа к /dev/net/tun, сервису systemd может не хватать capabilities, а на хосте могут конфликтовать iptables/nftables, NetworkManager, Docker, Tailscale, WireGuard, firewalld или ручные ip rule. На Linux чаще всего приходится смотреть не только лог клиента, но и таблицы маршрутов.
/dev/net/tunдолжен существовать и быть доступен процессу.- Для создания интерфейса и изменения маршрутов нужны root-права или capabilities.
ip route,ip rule, nftables/iptables и policy routing должны соответствовать схеме клиента.- В контейнерах нужны отдельные разрешения на TUN-устройство и сетевое администрирование.
- Если включены Docker, Kubernetes, WireGuard, Tailscale или корпоративный VPN, проверяйте пересечения подсетей и marks.
#sing-box TUN: что означают главные параметры
В sing-box TUN — это тип inbound: "type": "tun". Он принимает трафик из виртуального интерфейса и передает его в router sing-box, где уже работают DNS, route rules и outbounds. Официальный manual описывает virtual interface как способ, через который L4 proxy могут работать как VPN на мобильных платформах, а TUN inbound — как метод transparent proxying.
| Параметр | Смысл | Что проверить при ошибке |
|---|---|---|
address | Адрес виртуального интерфейса. | Нет ли конфликта с локальной сетью или другой VPN-подсетью. |
auto_route | Автоматически добавляет маршруты для отправки трафика в TUN. | Создались ли маршруты и не перехватили ли они лишнее. |
strict_route | Ужесточает маршрутизацию; на Windows помогает против DNS leak, но может снижать совместимость. | Не ломает ли VirtualBox, локальные интерфейсы, ICMP или unsupported network. |
auto_redirect | Linux-механизм прозрачного перенаправления через firewall/nftables. | Есть ли поддержка nftables и нет ли конфликта marks/rules. |
route_address | Явно задает, какие адреса маршрутизировать в TUN. | Не слишком ли узкий или широкий список. |
route_exclude_address | Исключает адреса из маршрутизации через TUN. | Есть ли исключения для LAN, роутера, NAS, корпоративных подсетей. |
include_package / exclude_package | Android-фильтрация по пакетам приложений. | Не исключено ли приложение, которое вы проверяете. |
stack | Выбор TUN stack, например system или gVisor, в зависимости от платформы и клиента. | Не требует ли ваша функция другого stack. |
Для предотвращения routing loop в sing-box важен раздел route. auto_detect_interface помогает автоматически выбрать реальный исходящий интерфейс, а default_interface может явно привязать outbound-соединения к нужной сетевой карте на Linux, Windows и macOS. Если исходящее соединение до proxy-сервера снова попадает в TUN, клиент начинает маршрутизировать сам себя.
#DNS и routing: почему TUN включился, а утечка осталась
TUN сам по себе не гарантирует, что DNS ушел через правильный маршрут. DNS может выполнять система, браузер, Private DNS, DoH в приложении, локальный резолвер или DNS-модуль клиента. В sing-box раздел dns содержит servers, rules, final, strategy, cache и FakeIP, а route решает, куда отправлять соединения. Если эти разделы противоречат друг другу, симптом будет выглядеть как «TUN работает, но часть сайтов идет не туда».
hijack-dnsв route rules перехватывает DNS-запросы и передает их DNS-модулю клиента.dns.finalзадает DNS-сервер по умолчанию, если DNS rule не сработало.route.finalзадает outbound по умолчанию для соединений.- IPv6 должен быть либо корректно включен, либо осознанно отключен; частичная IPv6-схема часто дает утечки или недоступность.
- FakeIP помогает некоторым proxy-сценариям, но требует согласованной маршрутизации и понимания, как клиент сопоставляет домены и подставные IP.
Практический минимум проверки: после включения TUN посмотрите внешний IP, DNS leak test, доступ к локальному роутеру, IPv6 test и несколько приложений, а не только один браузер. Браузер может использовать собственный DoH, а мобильное приложение — системный DNS или другой сетевой API.
#Риски TUN mode
- Ложное чувство защиты. TUN перехватывает маршрутизируемые пакеты, но не доказывает, что сервер надежный, протокол настроен правильно, а DNS не утекает.
- Прямые исключения. Split tunneling, direct rules и excluded apps могут намеренно отправлять часть трафика мимо туннеля.
- DNS leak. Особенно вероятен при нескольких интерфейсах, Private DNS, браузерном DoH, IPv6 или неполном hijack-dns.
- Routing loop. Клиент может попытаться подключаться к своему proxy/VPN-серверу через собственный TUN.
- Недоступная локальная сеть. Роутер, принтер, NAS, Chromecast, AirDrop, SMB или корпоративная подсеть могут попасть в чужой маршрут.
- Сломанные приложения. Банки, антифрод, игры, стриминг, корпоративные агенты и виртуализация могут блокировать или плохо переносить VPN/TUN.
- MTU и фрагментация. Слишком большой MTU вызывает зависания, медленную загрузку или сайты, которые открываются частично.
- Зависимость от версии клиента. sing-box и клиенты вокруг него активно меняют поля; старый клиент может не понимать новый конфиг.
#Troubleshooting: что проверять по симптомам
| Симптом | Вероятная причина | Что сделать |
|---|---|---|
| TUN включился, интернета нет | Нет прав, не создался маршрут, routing loop, конфликт с другим VPN. | Отключить другой VPN, проверить обычный proxy-режим, перезапустить клиент с нужными правами, проверить route/auto_detect_interface. |
| Работает браузер, но не приложения | На самом деле включен system proxy, TUN не активен или приложение исключено. | Проверить режим клиента, per-app списки, allowed/disallowed apps, системный VPN-индикатор. |
| Есть DNS leak | DNS идет через систему, другой интерфейс, браузерный DoH или IPv6. | Проверить DNS rules/final, hijack-dns, Private DNS, strict_route на Windows, IPv6 strategy. |
| Не открывается локальный роутер или NAS | Приватные адреса попали в туннель или заблокированы strict routing. | Добавить direct/exclude для LAN-подсетей, проверить route_exclude_address и private IP rules. |
| После сна Windows/macOS сеть пропала | Старые маршруты, зависший адаптер, смена Wi-Fi, конфликт DNS. | Переподключить TUN, перезапустить клиент, проверить виртуальный адаптер и DNS-интерфейсы. |
| На Linux ошибка /dev/net/tun | Нет TUN-устройства, модуля, capabilities или доступа в контейнере. | Проверить существование /dev/net/tun, права процесса, CAP_NET_ADMIN, настройки контейнера. |
| Сайты открываются частично | MTU, IPv6, QUIC/UDP, фрагментация или неправильный DNS. | Снизить MTU, проверить IPv6, временно отключить HTTP/3/QUIC для теста, сравнить proxy-режим. |
| Некоторые домены идут напрямую | Сработало direct-правило, rule-set, excluded app или bypass. | Читать route rules сверху вниз, проверить final outbound, rule-set и split tunneling. |
#Практический чеклист перед включением TUN
- Проверьте профиль без TUN. Убедитесь, что сервер, ключи, outbound и базовый proxy-режим работают.
- Определите область действия. Весь трафик, только выбранные приложения, только IPv4 или IPv4+IPv6.
- Проверьте DNS-план. Где резолвятся домены, нужен ли hijack-dns, что будет с Private DNS/DoH.
- Добавьте исключения. LAN, роутер, принтер, NAS, captive portal, банк или корпоративные подсети при необходимости.
- Проверьте конфликтующие клиенты. Другой VPN, ad blocker, firewall, Docker, VirtualBox, Tailscale, WireGuard.
- Включайте сложность постепенно. Сначала auto_route, затем strict_route, затем rule-set/FakeIP/IPv6-изменения.
- После включения тестируйте не только IP. Проверяйте DNS, IPv6, локальную сеть, несколько приложений и поведение после смены сети.
#FAQ
#TUN mode — это VPN?
Не совсем. TUN mode — локальный режим виртуального интерфейса. Он часто используется VPN-клиентами и может давать поведение «как VPN для всего устройства», но удаленный протокол и уровень защиты зависят от конкретного клиента, сервера и конфигурации.
#Почему TUN просит системное VPN-разрешение?
Потому что приложение получает возможность обрабатывать сетевой трафик устройства. На Android это делается через VpnService, на Apple-платформах через системные VPN/Network Extension механизмы, на desktop — через виртуальный адаптер и маршруты.
#Нужно ли включать TUN для браузера?
Если задача только в браузере и он нормально работает через proxy, TUN не обязателен. Он нужен, когда браузерный proxy недостаточен, когда нужен UDP/QUIC или когда требуется одинаковая маршрутизация для всего устройства.
#TUN защищает от DNS-утечек?
Только если DNS настроен вместе с маршрутизацией. Нужны согласованные DNS rules, hijack-dns или системная настройка клиента, корректный IPv6 и отсутствие обхода через другой интерфейс или браузерный DoH.
#Почему включенный TUN ломает локальную сеть?
Потому что маршруты могут отправлять приватные адреса в туннель или strict routing может запрещать неподдерживаемую сеть. Обычно нужны direct/exclude правила для роутера, принтера, NAS и локальных подсетей.
#Что лучше: TUN или system proxy?
Для всего устройства и приложений без proxy — TUN. Для одного браузера, разработки, тестов и понятной выборочной задачи — system proxy или явный SOCKS/HTTP proxy. Выбор зависит от области действия, а не от того, какой режим звучит «серьезнее».
#Итог
TUN mode — мощный, но требовательный режим. Он переносит работу клиента с уровня «приложение само знает proxy» на уровень «операционная система направляет IP-пакеты в виртуальный интерфейс». Благодаря этому TUN покрывает больше трафика, но требует аккуратной настройки DNS, маршрутов, исключений, прав и платформенных особенностей.
Надежная схема начинается с простого: сначала проверить профиль без TUN, затем включить виртуальный интерфейс, потом отдельно проверить DNS, IPv6, локальную сеть, split tunneling и поведение разных приложений. Если относиться к TUN как к системе маршрутизации, а не как к магическому переключателю приватности, большинство ошибок становится объяснимым и исправимым.