Речь идет о сетевом стеке TUN/TAP драйвера в контексте VPN-клиентов типа Clash Meta / Mihomo, которые поддерживают несколько режимов работы TUN интерфейса через параметр stack.
Техническая суть вопроса:
В конфигурации Clash Meta существует параметр:
tun:
stack: gvisor | system | mixed
Как я понял:
1. gvisor - Использует gVisor netstack (userspace TCP/IP стек от Google)
· Реализация в пользовательском пространстве
· Полная изоляция от ядра
· Высокое потребление CPU, так как каждый пакет обрабатывается в userspace
· Используется в Clash через tun_gvisor сборку
2. system - Использует системный сетевой стек ядра
· Пакеты передаются напрямую в системный сетевой стек (/dev/net/tun)
· Низкие накладные расходы, высокая производительность
· Использует стандартный Linux TUN драйвер
3. mixed - Гибридный режим
· TCP: через системный стек (kernel)
· UDP: через gVisor (userspace)
· Компромисс между производительностью и функциональностью
Причины по которым было бы неплохо реализовать:
· Текущая реализация (если используется gvisor): высокая нагрузка на CPU, особенно на роутерах со слабым железом
· Реализация system/mixed: позволила бы снизить нагрузку на 30-50% за счет использования аппаратного ускорения сетевого стека ядра
· Например WireGuard (использует системный стек), OpenVPN (может использовать либо kernel, либо userspace)
Конкретные реализации:
· Clash Meta с stack: system: использует стандартный /dev/net/tun + системные вызовы ядра
· gVisor stack: требует компиляции с -tags=gvisor, реализует свой TCP/IP стек в Go
Если кратко:
Добавить поддержку режима stack: system в реализацию TUN интерфейса в Keenetic для VPN-клиентов, что позволит:
1. Снизить нагрузку на CPU роутера
2. Увеличить пропускную способность VPN
3. Улучшить поддержку современных VPN-протоколов
Доки:
· Clash Meta TUN реализация: https://github.com/MetaCubeX/mihomo/blob/master/docs/tun.md
· gVisor netstack: https://github.com/google/gvisor/tree/master/pkg/tcpip
· Linux TUN/TAP: https://www.kernel.org/doc/html/latest/networking/tuntap.html
Ответ техподдержки кинетик из ТГ:
По поводу OpkgTun и OpkgTap.
Вопрос касается открытых пакетов. По какой причине это сделано? У нас нет точной информации, мы можем предполагать.
Возможно это связано с тем, что *OpkgTun/*TAP* = далее TUN/TAP*, имеет прямой доступ к сетевому стеку ядра.
В *KeeneticOS 5.0* ужесточена модель безопасности открытых пакетов OPKG.
3. *`system`* режим даёт opkg-процессу *root-доступ к сети* → это риск:
- обхода firewall,
- поломки маршрутизации,
- вмешательство в NDMS.
4. *`mixed`* непригоден для TUN/TAP: нужен *полный доступ к netns*.
5. Поэтому для *OpkgTun разрешён только `gvisor`* как единственный безопасный вариант. Потеря производительности — *осознанный компромисс* ради изоляции.
Вы можете уточнить вопрос в специализированных теме https://forum.keenetic.ru/topic/17455-sing-box-универсальный-набор-прокси-инструментов-shadowsocks-vmess-vless-trojan/page/4/#comment-208868https://forum.keenetic.ru/topic/2905-экспресс-вопрос/page/157/#findComment-208942 и https://forum.keenetic.ru/topic/23610-добавить-opkgtun-на-закладку-другие-подключения
