Перейти к содержанию

Карта встраивания: L2/L3, TUN/TAP, bridge/route — чем туннель отличается от прокси на уровне системы

Статус: Confirmed (стабильные сетевые концепты — документация Linux tuntap, RFC; архитектура владельца — keenetic-auto-setup/ARCHITECTURE.md) + Research (детали классификации конкретных коммерческих продуктов)
Область применения: чтение и проектирование схем Keenetic + Entware + Mihomo + WireGuard/AmneziaWG; разбор споров «полноценный VPN / неполноценный прокси»
Проверено на: kernel.org tuntap (2026-09-24), официальная документация Xray (исходник xtls.github.io, 2026-09-24), RFC 9297/9298/9484, docs.amnezia.org (2026-09-24), ARCHITECTURE.md keenetic-auto-setup @ main
Последняя проверка: 2026-09-24
Source of truth: Linux kernel Documentation/networking/tuntap; официальные доки проектов; для архитектуры владельца — код keenetic-auto-setup
Provenance: raw-исследование proxy.md (словарь базовых терминов — в vpn-proxy-terminology.md; эта статья — карта уровней и встраивания)

Что решаем

Спор «это VPN или прокси?» почти всегда смешивает две независимые оси:

  1. что туннелируется — кадры Ethernet (L2), IP-пакеты (L3) или поток конкретного приложения;
  2. как инструмент встраивается в ОС — создаёт сетевой интерфейс с маршрутами или просто слушает порт, к которому клиент должен подключиться явно.

Пока оси не разведены, вопросы вида «почему две вещи обе называются VPN, но интегрируются по-разному?» или «чем Mihomo TUN отличается от ProxyN?» не имеют ответа. Эта статья — практическая карта для таких вопросов.

Уровень 1: что туннелируется

Кадры vs пакеты

  • L2 (канальный уровень) — единица данных: кадр Ethernet (MAC-адреса, и т. п.). Туннелирование L2 объединяет узлы в один broadcast-домен: у участников общее «виртуальное Ethernet», работают ARP, «плоская» сеть.
  • L3 (сетевой уровень) — единица данных: IP-пакет. Туннель L3 переносит пакеты между IP-сетями; объединяет не сегменты, а маршруты.

Примеры (не каталог, а ориентиры):

Уровень Технологии-примеры
L2-туннели L2TP, EoIP/GRETAP, OpenVPN TAP, VXLAN (формально L2-over-L3)
L3-туннели IPsec (ESP), WireGuard/AmneziaWG, OpenVPN TUN, GRE, IP-in-IP
Посредничество на уровне приложения SOCKS5, HTTP CONNECT, VLESS/VMess/Trojan…

TAP vs TUN

Официальная документация ядра Linux разделяет их одной фразой: «TUN works with IP frames. TAP works with Ethernet frames». TUN — виртуальный интерфейс L3 (point-to-point, пакеты, маршрутизация); TAP — виртуальный Ethernet-адаптер L2 (кадры, bridging). Отсюда практическое следствие:

TAP + bridge  = соединить сети на канальном уровне (один L2-сегмент, DHCP/ARP сквозь туннель)
TUN + route   = соединить сети на сетевом уровне (маршруты между подсетями)

bridge vs route

  • Bridge — переключение кадров на L2: порты объединяются в один сегмент, решение по MAC-таблице. У Keenetic это модель сегментов/Bridge-интерфейсов.
  • Route/forwarding — переключение пакетов на L3: решение по таблице маршрутизации, сегменты остаются изолированными подсетями.

Это разные механизмы объединения сетей, и выбор между ними не «стиль», а следствие задачи (нужен общий L2-домен или связность подсетей).

Уровень 2: как инструмент встраивается в ОС

Туннельный интерфейс (модель WireGuard)

WireGuard/AmneziaWG — L3-туннель, который встраивается в систему как интерфейс:

системный сетевой интерфейс (wg0)
    + записи в таблице маршрутизации (AllowedIPs → wg0)
    = ядро само направляет пакеты в туннель, приложения ничего не знают

AmneziaWG при этом — тот же класс: форк WireGuard с тем же крипто-ядром (Noise_IK, Curve25519, ChaCha20-Poly1305), в котором изменены заголовки/рукопожатие и добавлен «мусорный поезд» (Jc/Jmin/Jmax) для маскировки от DPI. Маскировка не меняет уровень: это по-прежнему L3-туннель с интерфейсом и маршрутами (подробно про слои маскировки — proxy-tunnel-protocol-stack.md).

Прокси-listener (модель SOCKS5)

SOCKS5 (RFC 1928) и HTTP-прокси — посредники на уровне приложения:

слушающий порт (например 127.0.0.1:7890)
    + клиент, который ЯВНО подключается к нему и просит соединить с целью
    = ни интерфейса, ни маршрутов; ядро участвует только в доставке до прокси

Прокси-порт никогда не захватывает трафик сам. Пока приложение (или его настройки, или расширение вроде FoxyProxy) не обратится к прокси осознанно — трафик идёт обычным путём. Именно поэтому «поднял прокси — весь трафик пошёл через него» — ошибка.

Почему обе модели называются «VPN»

У пользователя за TUN-интерфейсом приложения видят обычную IP-сеть — поведение «как VPN». У пользователя за явно настроенным прокси — только те приложения, которые про прокси знают. Названия совпадают, интеграция разная. VLESS не становится VPN от того, что его запустили через TUN: TUN-интерфейс — это вход в прокси-цепочку, а не свойство протокола.

Две разные точки решения: routing policy vs proxy selection

Policy routing (ОС) Proxy selection (движок)
Кто решает ядро/роутер (Keenetic ip policy, Linux ip rule) прокси-движок (правила Mihomo)
Что решает какой трафик в какой интерфейс/таблицу какое соединение через какой outbound
Входные данные адреса/метки/сегменты клиента домены/IP/процессы из правил
Где стоит до туннеля/прокси — решает, куда вообще попадёт трафик внутри движка, после того как трафик уже попал

Типичная ошибка — ждать от policy routing семантики правил прокси-движка (или наоборот). В архитектуре владельца оба уровня работают вместе: Keenetic/MagiTrickle решает, какой трафик попадёт в ProxyN/mitun0, а Mihomo уже внутри решает, через какой outbound его отправить.

Почему Mihomo умеет и listener, и TUN

Mihomo — прокси-движок, а его входы и выходы независимы. Входов два:

  • mixed/SOCKS-порт (:7890) — классический прокси-listener: подключаются явно (браузер с FoxyProxy, ProxyN у Keenetic);
  • TUN-интерфейс (mitun0) — прозрачный IP-вход: ядро направляет пакеты в виртуальный интерфейс, Mihomo читает их оттуда.

Один и тот же движок, одни и те же правила/outbound — разные способы попадания трафика. Это не «два режима Mihomo», а два разных способа интеграции с системой при одном ядре решений.

Почему в архитектуре владельца законно сосуществуют ProxyN и mitun0

По ARCHITECTURE.md keenetic-auto-setup (Confirmed):

ProxyN mitun0
Что это прокси-интерфейс KeeneticOS (SOCKS5 → 127.0.0.1:7890) TUN-устройство, созданное самим Mihomo
Как трафик входит как SOCKS-проксирование на уровне приложения как обычный IP-трафик через интерфейс
Где виден в политиках/правилах Keenetic как полноценный интерфейс в Keenetic как обычный интерфейс, на который тоже можно навести политику
Сильная сторона явная точка назначения для правил по клиенту/сегменту прозрачный путь без клиентских настроек

Оба ведут в один Mihomo — но это разные уровни встраивания (приложение-посредник vs интерфейс L3).Поэтому «зачем вам и Proxy0, и mitun0?» — это один и тот же вопрос, что «зачем вам и прокси-порт, и VPN-интерфейс»: они закрывают разные сценарии попадания трафика в движок.

Что подтверждено, а что нет

Confirmed:

  • «TUN works with IP frames. TAP works with Ethernet frames» — документация ядра Linux (tuntap); TAP применим к bridging, TUN — к туннелированию/маршрутизации.
  • bridge = L2-переключение кадров, routing = L3-форвардинг пакетов — базовые сетевые концепты (документация Linux/Keenetic).
  • WireGuard — UDP-based L3-туннель с интерфейсом и маршрутами AllowedIPs; AmneziaWG — форк WireGuard-Go с тем же крипто-ядром и обфускацией рукопожатия (Jc/Jmin/Jmax, H1–H4), без обфускации совместим со стандартным WireGuard (docs.amnezia.org).
  • SOCKS5 (RFC 1928) — посредник на уровне приложения; захват трафика требует явного клиента.
  • Разделение policy routing vs proxy selection и таблица ProxyN/mitun0 — по ARCHITECTURE.md keenetic-auto-setup @ main.
  • Mihomo: mixed-порт и TUN — независимые входы одного движка (документация MetaCubeX; ARCHITECTURE.md).

Research / зависит от среды:

  • отнесение конкретных коммерческих продуктов (Cisco AnyConnect, FortiGate, MPLS L3VPN, SoftEther-режимы) к L2/L3-классам — не проверялось по их документации; в этой карте они сознательно не каталогизируются;
  • нюансы производительности TUN-стеков (gvisor/system/mixed/mips) — см. mihomo-keenetic-routing.md.

Источники и provenance

  • Linux kernel, Documentation/networking/tuntap (TUN/TAP, bridging) — проверено 2026-09-24.
  • RFC 1928 (SOCKS5).
  • docs.amnezia.org — AmneziaWG (крипто-ядро, Jc/Jmin/Jmax), проверено 2026-09-24.
  • saymer-alt/keenetic-auto-setup → ARCHITECTURE.md (ProxyN/mitun0, policy routing, mixed-порт).
  • Raw-материал: proxy.md — исследовательский диалог, из которого извлечена карта уровней; сам по себе не доказательство.

Связанные материалы