Реализация режимов TUN stack в Keenetic: system, mixed

[nikrays]

Речь идет о сетевом стеке 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-на-закладку-другие-подключения

Изменено 18 часов назад пользователем nikrays

[avn]

18 минут назад, nikrays сказал:

Добавьте пожалуйста поддержку режимов tun: mixed, system. В данный момент доступен gVisor который прожорлив

Прошелся поиском по исходникам ядра линукса. Оно не знает, что такое gVisor. О чем речь?

Изменено Среда в 21:52 пользователем avn

[nikrays]

25 минут назад, avn сказал:

Прошелся поиском по исходникам ядра линукса. Оно не знает, что такое gVisor. О чем речь?

Основные отличия режимов

 

· gvisor: Сетевой стек реализован в пользовательском пространстве (userspace) для полной изоляции трафика. Использует свой собственный стек.

· system: Использует системный сетевой стек ядра операционной системы (kernel-space).

· mixed: Гибридный подход: TCP-трафик обрабатывается стеком system, а UDP — стеком gvisor.

[avn]

14 минут назад, nikrays сказал:

Основные отличия режимов

 

· gvisor: Сетевой стек реализован в пользовательском пространстве (userspace) для полной изоляции трафика. Использует свой собственный стек.

· system: Использует системный сетевой стек ядра операционной системы (kernel-space).

· mixed: Гибридный подход: TCP-трафик обрабатывается стеком system, а UDP — стеком gvisor.

Ядро Линукс ничего не знает о gvisor. Так о чем речь?

[spatiumstas]

Только что, avn сказал:

Ядро Линукс ничего не знает о gvisor. Так о чем речь?

Вам и не скажут, форумчанин не разбирается в том, о чём пишет, поэтому отвечает ИИшными пастами 🤠

[nikrays]

5 минут назад, spatiumstas сказал:

Вам и не скажут, форумчанин не разбирается в том, о чём пишет, поэтому отвечает ИИшными пастами 🤠

Вы серьезно? Может быть кто-то из разработчиков тогда ответит кто понимает о чем я говорю, в userspace то есть gvisor жрет ресурсы роутера, а стек system например нет, вот и прошу реализации на системном уровне по тсп

[wigeance]

Если поднимать в прошивке 5.0+ OpkgTun через стек system, то ndms не дает туда отправлять TCP трафик. При этом UDP трафик проходит в таком сетапе нормально. Проблема только с TCP.

 

Поддержка keenetic сказала, что TCP заблокирован специально, чтобы не лезли во внутреннюю кухню прошивки. А для обсуждения возможности разблокировки этого ограничения, автора послали на этот форум

Изменено 18 часов назад пользователем wigeance

[wigeance]

Поднятие Tun интерфейса в userspace без задействования встроенного TUN в прошивку, например через gvisor (или не дай бог lwip) работает нормально, но кушает очень много ресурсов. При нормальных скоростях, тот же сингбокс будет грузить под 99% даже 1812

[frontend.test]

а чем вас не устраивает режим Redirect + TProxy парень for6to9si пилит проекты как я кофе пью
https://github.com/for6to9si/H-wave
https://github.com/for6to9si/X-wave
https://github.com/for6to9si/S-wave

Изменено 18 часов назад пользователем frontend.test

[wigeance]

7 minutes ago, frontend.test said:

а чем вас не устраивает режим Redirect + TProxy парень for6to9si пилит проекты как я кофе пью
https://github.com/for6to9si/H-wave
https://github.com/for6to9si/X-wave
https://github.com/for6to9si/S-wave

Redirect + TProxy нельзя управлять из веб-интерфейса самого кинетика, нужно пилить сторонние решения, плюс TUN работает лучше под высокой нагрузкой (торренты и т.д.)

[hoaxisr]

20 минут назад, wigeance сказал:

Redirect + TProxy нельзя управлять из веб-интерфейса самого кинетика, нужно пилить сторонние решения, плюс TUN работает лучше под высокой нагрузкой (торренты и т.д.)

1. в контексте Mihomo/Clash и прочих у них есть inbound типа mixed к которому можно настроить подключение из WebUI роутера - в разделе другие подключения. (нужен компонент Прокси клиент) и делайте потом что пожелаете.

2. Откуда вы это берете я не понимаю, но

50 минут назад, wigeance сказал:

без задействования встроенного TUN в прошивку

если в настройках клиентов (mihomo/clash и прочий умеющих в tun) указать не mixed/gvisor, а system, то вполне себе все поднимается и работает.

3. 

55 минут назад, wigeance сказал:

Поддержка keenetic сказала, что TCP заблокирован специально, чтобы не лезли во внутреннюю кухню прошивки. А для обсуждения возможности разблокировки этого ограничения, автора послали на этот форум

Это какое-то фееричное не понимание как устроена маршрутизация и как она настраивается в entware/OPKG. Вы подняли туннель каким-то клиентом, так настройте разрешающие правила для прохождения трафика и маскарадинг. И все работает. У тысяч людей работает, а для вас специально придумали какие-то ограничения? Нет, конечно. 

[hoaxisr]

Рекомендую автору поста прекратить задавать вопросы ИИ и думать, что это истина в последней истанции. В ваших копи-пастах от модельки только галлюцинации - там нет здорового чуть более, чем полностью.