Jump to content
Официальное хранилище ПО в виде файлов
  • 7

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

avn

Asked by avn,

 Share

Question

avn Honored Flooder

avn

Posted
Posted (edited)

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

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

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

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

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

 

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

Edited by avn
  • Upvote 6

14 answers to this question

Recommended Posts

  • 1
Ground_Zerro Advanced Member

Ground_Zerro

Posted
Posted (edited)

@Denis P

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

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

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

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

Edited by Ground_Zerro
  • 0
Le ecureuil NetFriend

Le ecureuil

Posted
Posted

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

  • 0
avn Honored Flooder

avn

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

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

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

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

  • 0
Le ecureuil NetFriend

Le ecureuil

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

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

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

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

  • 0
Ground_Zerro Advanced Member

Ground_Zerro

Posted
Posted (edited)

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

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

Edited by Ground_Zerro
  • Confused 1
  • 0
Denis P Honored Flooder

Denis P

Posted
Posted (edited)
8 часов назад, Ground_Zerro сказал:

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

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

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

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

 

Edited by Denis P
  • Upvote 1
  • 0
krcv002 Newbie

krcv002

Posted
Posted

@Le ecureuil

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

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

Спасибо!

  • Thanks 1
  • Upvote 1
  • 0
Le ecureuil NetFriend

Le ecureuil

Posted
Posted
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 нужно пересобирать, обычно нет никакой проблемы аккуратно запатчить.

  • 0
Alex T Member

Alex T

Posted
Posted (edited)

Перечитал темы и так и не понял, как должны взаимодействовать создаваемые в 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"
                }
            }
        }

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

Edited by Alex T
  • 0
Alex T Member

Alex T

Posted
Posted

Методом тыка что-то получилось.
Если сначала создать интерфейс в прошивке, потом поднять в 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 байт не доходят.

  • 0
Le ecureuil NetFriend

Le ecureuil

Posted
Posted
В 29.08.2025 в 13:26, 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)  

  Показать контент

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

Создаём интерфейс руками и выдаём ему адрес, по примеру из темы 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 всё работает.

  Показать контент

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

Потому что есть команда show interface system-name, именно ее вывод нужно подставлять в usque в регистрозависимом виде.

  • Thanks 1
  • 0
Le ecureuil NetFriend

Le ecureuil

Posted
Posted
В 30.08.2025 в 15:27, 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 байт не доходят.

Включите interface ip tcp adjust-mss pmtu.

  • Thanks 1
 Share
Go to question listing

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...

Important Information

This site uses cookies. By clicking "I accept" or continuing to browse the site, you authorize their use in accordance with the Privacy Policy.

  I accept