Создание tun+ из интерфейса

[avn]

Прошу добавить возможность добавлять/ или использовать интерфейс tun+.

Реализация. Сделать новый раздел в интерфейсе vpn - tun.  Дать возможность добавлять, удалять tun интерфейс или использовать уже созданный из entware интерфейс.

При добавлении нового интерфейса tun, при загрузке роутера создавать его в системе.

Если tun интерфейс создан как настройка к существующему tun интерфейсу, то создавать его не нужно.

Для чего это необходимо. Что бы в политиках использовать этот tun интерфейс.

 

Это своеобразная связь entware с текущим web-интерфейсом.

Изменено 18 сентября, 2024 пользователем avn

[busy10]

+

[Le ecureuil]

Создание интерфейса - это только вершина айсберга. Еще нужно выставить флаги о том, что он подключен или нет, поставить на него адрес и прописать роуты. И все это нужно будет сделать посредством NDM, иначе политики работать не будут. Вы точно уверены, что сможете все это реализовать?

[avn]

49 минут назад, Le ecureuil сказал:

Создание интерфейса - это только вершина айсберга. Еще нужно выставить флаги о том, что он подключен или нет, поставить на него адрес и прописать роуты. И все это нужно будет сделать посредством NDM, иначе политики работать не будут. Вы точно уверены, что сможете все это реализовать?

А ядро не может отслеживать состояние/изменение tun интерфейса? И если такое изменение произошло, синхронизировать ndm.

Мы же не знаем когда от упал, поднялся интерфейс, ип адрес изменился и т.д. У нас нету этой информации. Она есть, только у самих приложений, которые поднимают tun интерфейс.

[Le ecureuil]

2 часа назад, avn сказал:

А ядро не может отслеживать состояние/изменение tun интерфейса? И если такое изменение произошло, синхронизировать ndm.

Мы же не знаем когда от упал, поднялся интерфейс, ип адрес изменился и т.д. У нас нету этой информации. Она есть, только у самих приложений, которые поднимают tun интерфейс.

Вот в этом и особенность. При интеграции разных протоколов в NDM мы добавляем в них обработку всех этих настроек и событий. Свободно-болтающийся интерфейс можно сделать теоретически, но на него нужно будет руками вешать статический адрес через команды, роуты тоже. Динамический адрес вообще возможен будет в виде костыля с внешним управлением.

[Ground_Zerro]

В 5.0 Alpha 1 добавлено: "Реализовано обнаружение и интеграция OpkgTun и OpkgTap интерфейсов, созданных в среде OPKG — это позволяет использовать их в Приоритетах подключений и статических маршрутах."

Можно попросить немного подробностей как с этим работать, учитывая ЭТОТ комментарий.

Изменено 6 июля пользователем Ground_Zerro

[Denis P]

8 часов назад, Ground_Zerro сказал:

В 5.0 Alpha 1 добавлено: "Реализовано обнаружение и интеграция OpkgTun и OpkgTap интерфейсов, созданных в среде OPKG — это позволяет использовать их в Приоритетах подключений и статических маршрутах."

Можно попросить немного подробностей как с этим работать, учитывая ЭТОТ комментарий.

Нужно прочитать и другие ответы в теме, кроме одного.

Вот эту тему изучить, как вариант, особенно последние страницы

 

Изменено 6 июля пользователем Denis P

[Ground_Zerro]

@Denis P

Согласен. Как-то не догадался.

Это же более чем логично - читать про добавленные в прошивку возможности на последних страницах темы Sing-Box'а.

И действительно "в этой теме", куда ведет линк со страницы changelog целых 7 сообщений, вместе с последними двумя. Перечитаю тоже, может между строк чего найдется.

Спасибо камрад! Дай бог тебе здоровья.

Изменено 7 июля пользователем Ground_Zerro

[krcv002]

@Le ecureuil

Эх, OpkgTun — шаг вперёд, но всё равно остаются костыли. Можно ли добавить флаг dontspawn_system_adapter (или просто dontspawn)?

Вместо того чтобы насильно создавать системный интерфейс, можно отлавливать событие появления нового tun через netlink (ndm вроде бы уже мониторит это). Почти весь софт, работающий через TUN/TAP (VPN-клиенты и т.п.), в первую очередь рассчитывает на то, что он сам создаёт интерфейс — поэтому лучше дать опцию не форсить создание адаптера со стороны OpkgTun и реагировать на события от пользователейpace-приложений.

Спасибо!

[Le ecureuil]

13 часов назад, krcv002 сказал:

@Le ecureuil

Эх, OpkgTun — шаг вперёд, но всё равно остаются костыли. Можно ли добавить флаг dontspawn_system_adapter (или просто dontspawn)?

Вместо того чтобы насильно создавать системный интерфейс, можно отлавливать событие появления нового tun через netlink (ndm вроде бы уже мониторит это). Почти весь софт, работающий через TUN/TAP (VPN-клиенты и т.п.), в первую очередь рассчитывает на то, что он сам создаёт интерфейс — поэтому лучше дать опцию не форсить создание адаптера со стороны OpkgTun и реагировать на события от пользователейpace-приложений.

Спасибо!

Невозможно - KeeneticOS рассчитывает, что systemindex интерфейса никогда не изменится и что интерфейс создается в момент загрузки из конфига и его статус полностью под контролем KeeneticOS.

Пересоздание под тем же именем меняет этот самый systemindex, потому он уже не тот же самый.

Вы там можете по 5 раз в секунду пересоздавать этот интерфейс, будут слетать все маршруты и правила в netfilter, а как про должна KeeneticOS узнавать?

Ну и все равно для того, чтобы запустить в Opkg нужно пересобирать, обычно нет никакой проблемы аккуратно запатчить.

[Alex T]

Перечитал темы и так и не понял, как должны взаимодействовать создаваемые в entware tun интерфейсы и OpkgTun интерфейсы прошивки.
Насколько я понял, необходимо совпадение резистрозависимое, нет? имени поднятого приложением в entware интерфейса и созданного руками в прошивке.
Этого, похоже, не достаточно.
Giga (KN-1010) EAEU Прошивка 5.0 Alpha 13

Пробовал поднимать usque по мотивам соседней темы. Замечательно поднимается, параметром вида  --interface-name OpkgTun0 можно указать, как должен называться tun интерфейс. Средствами entware с этим интерфейсом отлично работается.
Работает и без ключа --no-tunnel-ipv6, но периодически спамит ошибками в лог прошивки о том, что не может поднять тоннель ipv6 (у меня нет ipv6)  

Спойлер

./usque --interface-name OpkgTun0 --config /opt/etc/usque/usque.json nativetun --no-tunnel-ipv6

ifconfig OpkgTun0
OpkgTun0  Link encap:UNSPEC  HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
          inet addr:172.16.0.2  P-t-P:172.16.0.2  Mask:255.255.255.255
          inet6 addr: fe80::9695:d150:e0fb:b1a3/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1280  Metric:1
          RX packets:16 errors:0 dropped:0 overruns:0 frame:0
          TX packets:23 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:500
          RX bytes:6037 (5.8 KiB)  TX bytes:3198 (3.1 KiB)

В прошивке интерфейс сам не появляется, вроде бы, и не должен.

Создаём интерфейс руками и выдаём ему адрес, по примеру из темы sing-box.
Без выставления адреса тоже пробовал.

interface OpkgTun0
	Network::Interface::Repository: "OpkgTun0" interface created.  
interface OpkgTun0 ip address 172.16.0.2 255.255.255.25
	Network::Interface::Ip: "OpkgTun0": IP address is 172.16.0.2/32.

Пробовал сначала создавать интерфейс в прошивке, потом поднимать usque - разницы не заметил.

Интерфейс в прошивке мёртв  и никак с тёзкой из entware не взаимодействует.  На стороне entware всё работает.

Спойлер

"OpkgTun0": {
            "uptime": 0,
            "id": "OpkgTun0",
            "index": 0,
            "interface-name": "OpkgTun0",
            "type": "OpkgTun",
            "description": "",
            "traits": [
                "Ip",
                "Ip6",
                "OpkgTun"
            ],
            "link": "down",
            "connected": "no",
            "state": "down",
            "mtu": 1500,
            "tx-queue-length": 150,
            "admin-only": false,
            "global": false,
            "security-level": "public",
            "ipv6": {},
            "summary": {
                "layer": {
                    "conf": "disabled",
                    "link": "disabled",
                    "ipv4": "disabled",
                    "ipv6": "disabled",
                    "ctrl": "disabled"
                }
            }
        }

Что я делаю неправильно или не делаю? 

Изменено Пятница в 11:24 пользователем Alex T

[Alex T]

Методом тыка что-то получилось.
Если сначала создать интерфейс в прошивке, потом поднять в entware usque на одноимённый интерфейс (не case sensitive), то они связываются.
конкретно у меня срабатывает следующая последовательность:
 

Спойлер

#shell
interface OpkgTun0
interface OpkgTun0 description usque
interface OpkgTun0 ip global auto
#entware
usque --config /opt/etc/usque/usque.json nativetun --interface-name opkgtun0 --mtu 1280 --no-tunnel-ipv6 --no-iproute2
#shell
interface OpkgTun0 ip address 172.16.0.2 255.255.255.255
interface OpkgTun0 ip mtu 1280
interface OpkgTun0 up

 

после этого интерфейс виден в WEBUI, статус, подсчёт трафика (т.к. выставил ip global) 

--no-iproute2 здесь позволяет не управлять адресом и линком, отдавая это прошивке
В итоге можно заворачивать трафик в него средствами entware, тут проблем не возникло.

А вот через dns-proxy route object-group прошивки у меня сейчас, насколько я понял, пролезают только пакеты, которые умещаются в mtu (1280 байт). Из entware тот же curl тащит и большие странички, при запросе с внешних хостов, ответы на ping и curl крупнее 1280 байт не доходят.