Перейти к содержимому
RU

Главная / Блог / DNS и сеть

Внутреннее устройство TUN — как работают вместе виртуальный адаптер, таблица маршрутизации и перехват DNS

DNS и сеть2026-06-261248 слов3 мин чтения
Внутреннее устройство TUN — как работают вместе виртуальный адаптер, таблица маршрутизации и перехват DNS

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

Поймите эти три вещи — и у любой неудобной проблемы с TUN появится направление для разбора.

1. Создание виртуального адаптера

TUN — это вид виртуального сетевого устройства, предоставляемый операционной системой. С точки зрения системы это обычный адаптер, только на другом конце не физический кабель, а программа в пространстве пользователя — здесь это ядро Mihomo.

Путешествие пакетаПриложениеотправляет IP-пакетМаршрутизация системырешает, через какой адаптер он уйдётВиртуальный адаптер TUNпакет передаётся программе ядраMihomo обрабатываетпо правилам решает: напрямую или переслать
Для приложения это полностью прозрачно, оно считает, что работает в сети как обычно

Реализации по платформам:

ПлатформаРеализацияНужные привилегии
WindowsДрайвер wintunАдминистратор (установка драйвера плюс системной службы)
macOSРасширение ядра utunroot (привилегированный helper)
Linux/dev/net/tunCAP_NET_ADMIN

«Режим службы» в Clash Verge существует именно для того, чтобы не запрашивать повышение прав каждый раз: системная служба ставится однажды и дальше выполняет привилегированные операции сама.

2. Переписывание таблицы маршрутизации

Одного адаптера мало; системе надо сказать отправлять трафик к нему. Это делается изменением маршрутов.

При auto-route: true ядро добавляет маршруты вида:

0.0.0.0/1    → адаптер TUN
128.0.0.0/1  → адаптер TUN

Почему два маршрута /1, а не один 0.0.0.0/0?

Потому что сопоставление маршрутов работает по принципу «самый длинный префикс побеждает». Существующий маршрут по умолчанию — 0.0.0.0/0; если бы TUN тоже заявил 0.0.0.0/0, два маршрута равной длины были бы неоднозначны. Разбитые на два /1 они длиннее по префиксу и надёжно перебивают исходный default — при этом сам default остаётся на месте, так что собственный исходящий трафик ядра по-прежнему выходит нормально.

Приоритет маршрутов, от высшего1Маршруты до конкретных хостов 322Два маршрута 1 от TUN3Исходный маршрут по умолчанию 0
IP сервера-узла обязан идти через физический адаптер, иначе его трафик зациклится обратно в TUN

auto-detect-interface: true позволяет ядру самому определить реальный исходящий адаптер (Wi-Fi или Ethernet), чтобы оно следовало за вами при смене сети.

Что делает strict-route

tun:
  strict-route: true

Это добавляет более строгие маршруты и политику брандмауэра, чтобы ничто не проскользнуло мимо TUN. Побочный эффект — выше вероятность конфликта с другим VPN-софтом.

Выключайте, когда нужно сосуществовать с VPN.

Исключение конкретного адаптера

Для сосуществования с корпоративным VPN:

tun:
  exclude-interface: ["ppp0", "Cisco AnyConnect"]

3. Перехват DNS

tun:
  dns-hijack:
    - any:53

Смысл: любой DNS-запрос на порт 53, какому бы серверу он ни был адресован, перехватывается и обслуживается собственным резолвером ядра.

Почему это необходимо: некоторые программы жёстко прописывают DNS-сервер (например, спрашивают напрямую 8.8.8.8), обходя ваши системные настройки. Без перехвата такие запросы уходят прежним путём, что означает:

  • Неточные ответы (возможно, отравленные)
  • Потерю информации о домене, из-за чего ядру остаётся сопоставлять правила по одному IP
  • Утечку DNS — провайдер видит, какие имена вы запрашивали
С перехватом DNS и без негоПрограмма жёстко спрашивает 8.8.8.8шлёт UDP-пакет на порт 53Без перехватапакет уходит через TUN на 8.8.8.8С перехватомядро перехватывает и отвечает самоИтогпервое может быть отравлено и утекает, второе под вашим
Под TUN параметр dns-hijack по сути обязателен

4. Стек: gvisor, system или mixed

TUN получает сырые IP-пакеты, поэтому ему нужен стек TCP/IP, чтобы собрать из них соединения. Три реализации:

Компромисс между тремя стекамиgvisorстек влучшая совместимостьнемного ниже производительностьрекомендация по умолчаниюsystemпередавысшая производительностьтребователен к настройке системы, совместимость хужедля погони за максимальной пропускной способностьюmixedTCP чесредний путьлучший ответ для большинства случаевобычное умолчание Mihomo
Когда что-то идёт не так, сначала переключитесь на gvisor — он реже всего капризничает

Ориентиры:

СитуацияВыбирайте
Не уверены / первая настройкаmixed
Странные проблемы с соединениямиgvisor
Софт-роутер, нужна пропускная способностьsystem
Проблемы с UDP на macOSgvisor

5. MTU и фрагментация

tun:
  mtu: 1500

MTU — максимальный размер одного пакета. Задайте MTU адаптера TUN больше, чем выдерживает реальный канал, и пакеты начнут фрагментироваться, теряя производительность; задайте слишком мало — упадёт эффективность передачи.

1500 — стандарт Ethernet, менять его обычно не нужно. Но если ваш узел работает поверх канала, уже несущего накладные расходы инкапсуляции (некоторые транзиты, PPPoE-соединение), полезный MTU меньше 1500, и может понадобиться 1400–1450.

6. Полная конфигурация TUN

tun:
  enable: true
  stack: mixed
  device: Mihomo
  auto-route: true
  auto-detect-interface: true
  auto-redirect: false          # дополнительное перенаправление на Linux
  strict-route: false
  mtu: 1500
  dns-hijack:
    - any:53
    - tcp://any:53
  # исключить адаптеры, чтобы избежать конфликта с VPN
  # exclude-interface: ["ppp0"]
  # исключить конкретные приложения (Mihomo)
  # exclude-package: ["com.example.app"]   # Android

Сопутствующая конфигурация DNS:

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "+.pool.ntp.org"
    - "+.msftconnecttest.com"
    - "+.msftncsi.com"
  nameserver: [223.5.5.5, https://doh.pub/dns-query]

DNS надо настроить одновременно: TUN забрал весь трафик, так что при неверном DNS не разрешается вообще ничего.

Глубинная причина частых проблем

СимптомГлубинная причинаЧто делать
После включения TUN всё умираетМаршруты переписаны, но собственный трафик ядра зацикливаетсяУбедитесь в auto-detect-interface: true; перезапустите
Сеть не восстанавливается после закрытия приложенияПроцесс был убит принудительно, маршруты не откатилисьЗапустите Clash Verge снова и выйдите корректно, либо перезагрузитесь
Устройства в LAN недоступныНет прямого правила для приватных диапазоновДобавьте IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
Не находится NAS или принтерИмена mDNS пойманы fake-ipДобавьте "*.local" и "*.lan" в fake-ip-filter
Конфликт с корпоративным VPNОба переписывают таблицу маршрутизацииВыключите strict-route, используйте exclude-interface
Система сообщает «нет подключения к интернету»Имя для проверки связности прошло через fake-ipДобавьте "+.msftconnecttest.com" в фильтр
Большие загрузки зависаютЗавышенный MTU и потеря фрагментовПоставьте mtu в 1400
Игры на UDP не подключаютсяУзел не поддерживает UDP либо неподходящий стекПроверьте udp: true у узла, переключите стек на gvisor
Высокая загрузка процессораВесь трафик проходит через стек в пространстве пользователяПереключите стек на system либо откажитесь от TUN в пользу системного прокси

Как убедиться, что TUN действительно работает

Посмотрите на адаптер:

# Windows
Get-NetAdapter | Where-Object {$_.InterfaceDescription -like "*wintun*"}
# Linux / macOS
ip link show    # или ifconfig

Вы должны увидеть адаптер с именем Mihomo или utunX.

Посмотрите на маршруты:

# Windows
route print -4
# Linux
ip route show

Должны быть видны два маршрута /1, указывающие на адаптер TUN.

Проверьте, что трафик действительно идёт через него:

Откройте страницу подключений в Clash Verge и обратитесь в интернет программой, которая точно игнорирует системный прокси, — например, консольным curl без заданных переменных окружения. Появившаяся запись на странице подключений означает, что TUN работает.

Коротко

Три вещи, которые делает TUN:

  • Виртуальный адаптер — требует драйвера и привилегий, чем занимается режим службы
  • Таблица маршрутизации — два маршрута /1 забирают всё, а IP узлов закреплены за физическим адаптером
  • Перехват DNS — не даёт жёстко прописанным резолверам обойти ядро

Когда что-то ломается, идите по этим трём слоям: есть ли адаптер → верны ли маршруты → работает ли DNS.

Смотрите также: DNS и fake-ip и раздельное туннелирование на практике.


Смежные документы

Конфигурация DNS в Clash — fake-ip или redir-host?
DNS и сеть Конфигурация DNS в Clash — fake-ip или redir-host?

Как на самом деле работает fake-ip, чем он отличается от redir-host, как делят работу nameserver и fallback, как не допустить утечки DNS и почему перестают резолвиться внутренние имена.

2026-07-131247 слов3 мин чтения
Трафик, число соединений и пропускная способность — ищем корень проблемы на странице подключений
DNS и сеть Трафик, число соединений и пропускная способность — ищем корень проблемы на странице подключений

Что означает каждый столбец и как им пользоваться: поиск программы, съедающей трафик, причины взрывного роста числа соединений, где узкое место скорости и непрерывный мониторинг через API.

2026-05-201102 слов3 мин чтения