-
Постов
10 -
Зарегистрирован
-
Посещение
Converted
-
Интересы
DPI, VPN, WEB, SMART HOME
Оборудование
-
Устройства
Hopper SE KN-3812
Посетители профиля
282 просмотра профиля
Достижения nikrays
Пользователь (2/6)
1
Репутация
-
Вы серьезно? Может быть кто-то из разработчиков тогда ответит кто понимает о чем я говорю, в userspace то есть gvisor жрет ресурсы роутера, а стек system например нет, вот и прошу реализации на системном уровне по тсп
-
Основные отличия режимов · gvisor: Сетевой стек реализован в пользовательском пространстве (userspace) для полной изоляции трафика. Использует свой собственный стек. · system: Использует системный сетевой стек ядра операционной системы (kernel-space). · mixed: Гибридный подход: TCP-трафик обрабатывается стеком system, а UDP — стеком gvisor.
-
Речь идет о сетевом стеке 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-на-закладку-другие-подключения
