Pop70

Вопрос снимается. "Дело было не в бобине..."© Эти змеи ещё и по синезубу... в своё приложение лезут. Хотя... Почему в приложении их трафик показывается?

Уточнение. Спокойно ходят не все устройства, а туевские выключатели. Уж чего там китайцы намудрили... Селфтест ниже

Создан профиль, по задумке дублирующий "без доступа к интернету". Т.е., галки со всех подключений сняты. Устройства с этим профилем спокойно идут в интернет по основному. Это баг или фича?

У меня на всех интерфейсах, и на dhcp прописаны гугловские ДНС (нешифрованные), и игнор провайдерских включен.

P.s. А если появится настоящее резервное соединение с интернет, то эти маршруты не будут мешать резервированию?

Да. Пингчек на OpkgTap0. Добавлен через CLI дефолтный профиль. Маршрут по умолчанию добавлен на OpkgTap0 через cli, и на opkgtap0 в opkg. А! Я понял! Добавить ещё маршруты до сервера впн через ethernet?

Пингчек уже был добавлен, маршрут был добавлен и в cli, и в opkg. Можно бы было исключать из профиля по умолчанию "резервные" подключения, зависимые от других, такого бы не было. Хотя, это всеголишь моя теория того, что происходило. Думаю, что спецы посмотрят селфтест, и разберутся.

Попробую ещё раз объяснить. Вначале - общая ситуация. Иногда, после софтовой перезагрузки, мой пров долго выдаёт ipадрес по dhcp. Бывает вообще приходится провод передёрнуть, чтобы получить ip, или звонить прову, чтобы порт перезагрузил. В чём проблема - не знаю, но не суть. Тут, удалённо решил обновиться до 5.0.4. После обновления никак не мог дождаться ни через приложение, ни через облачное доменное имя, звонил прову, тот несколько раз перезагружал порт - по барабану! Решил попробовать зайти напрямую, по своему доменному имени (ip статический, домен зарегистрирован). Как ни странно - зашёл. И что вижу? Eternet подключение, естественно, поднято, ip получен, на вкладке "доменное имя" висит надпись "не могу соединиться с сервером", подключение через softether и OpkgTap0 тоже не активно. Т.е., интернет на роутере есть, но ни облачная служба, ни приложение в opkg его не видят. Скорее всего, пытаются идти по маршруту через ВПН (softether), которое в профиле по умолчанию стоит резервным (а убрать из него его невозможно впринципе), и само зависит от ethernet подключения. Отключаю OpkgTap0 в веб интерфейсе - тут же кинетик появляется и в приложении, и через облачный домен. Снова включаю - softether поднимется, и дальше всё работает штатно. По прибытию домой, повторяю ситуацию, подключившись в веб-интерфейс из локалки. Делаю софтовую перезагрузку, и наблюдаю. Снова небольшая задержка в получении ip (пару минут), и снова всё то же самое - ethernet поднят, облако недоступно, клиенты без интернета, softether подключиться не может. Делаю приложенный здесь селфтест, потом передёргиваю в вебе резервное подключение - всё снова работет штатно. Т.е., при отсутствии основного подключения, система переходит на резервное, которое тоже не готово, и не будет, пока не поднимется основное, а при поднятии основного, перехода на него не происходит, пока резервное не отключить ручками.

А Adguard на этот интерфейс подключается? Или ещё какой-нибудь создаёт? Если на этот, то ip адрес на интерфейсе появляется? Если да, то задай вручную в opkg маршрут по умолчанию на этот адрес, и пинг, трасерт хоть 8.8.8.8 из веб-интерфейса. Если нет, то задай адрес вручную. Я же говорю, что не уверен, что это всегда сработает. Зависит от реализации приложения. Тот же NDM, когда пытается создать opkgtun(tap)0 интерфейс, в случае уже имеющегося, к нему не цепляется, а выдаёт ошибку. Как себя ведёт Adguard - вообще х.з.

Тоже 5.0.4. Но проблема с маршрутизацией вообще. если ethernet сразу не поднялся, то облачный сервис и приложения opkg долбятся в резервное подключение (зависимое от основного), пока его не отключишь. Даже после поднятия основного. Селфтест на всякий тут продублирую.

Точно! Пока не отключишь OpkgTap соединение, системный профиль переключен на него (приоритеты подключений). И нет доступа к интернету ни у клиентов, ни даже у облачной службы. Это баг или фича? 5.0.4 селфтест ниже.

Кстати, заметил странное поведение облачного сервиса, возможно, связанное с маршрутом по умолчанию, задаваемым скриптом при запуске. Последнее время, стал долго получать от прова ip адрес по dhcp после софтовой перезагрузки кинетика. Соответственно, подключение ethernet висит в "не готово", softether клиент никуда подключиться не может... Когда появляется подключение по ethernet, кинетик не видит облачных служб, пока не поднимется softether соединение и OpkgTap0. Доступ в админку напрямую уже есть, через облако нет. Такое ощущение, что, в облачные сервисы он просится через впн. Впн, кстати, тоже поднимается только после передёргивания подключения в вебе, как будто пытается через свой шлюз подключаться до этого. В скрытом сообщении ниже - кинднс-овский домен. Посмотрите, кто может, он в облаке с каким айпишником?

Вот, как раз, на этот случай, я и нашёл решение. При запуске кинетика выполняем скрипт, в котором переименовываем opkgtap(tun)0 в имя, которое хочет видеть приложение, потом, поднимаем соединение в приложении, и переименовываем интерфейс обратно. Не уверен, что это сработает с любым приложением.

Или ip route default шлюз OpkgTap(Tun) если интерфейс не "точка-точка"

Кстати, это подключение прекрасно отображается и в системном мониторе, и его даже можно "включить/выключить" (как я понял только в логике прошивки, на состояние приложения это конечно не влияет, хотя, через обработчики событий, можно, наверное, организовать и управление приложением). Не хватает его только на странице "Другие подключения", хотя ссылка из монитора состояния ведёт туда. Видимо, на будущее...

В общем, спасибо @hoaxisr за идею, подсказанную в другой теме. Получилось, хоть и с бубном и костылями, но достаточно просто подружить интерфейсы. ip link set opkgtap0 down ip link set opkgtap0 name vpn_vpn ip link set vpn_vpn up vpncmd localhost /client /CMD AccountConnect MyConnectionName ip link set vpn_vpn down ip link set vpn_vpn name opkgtap0 ip link set opkgtap0 up ip addr add 192.168..../24 dev opkgtap0 ip route add default via 192.168..1 dev opkgtap0 Это добавлено в один из скриптов, срабатывающих при запуске кинетика. Перед этим, нужно создать и настроить интерфейс OpkgTap в CLI. interface OpkgTap0 description Имя security-level public ip address 192.168..254 255.255.255.0 ip global auto ip tcp adjust-mss pmtu up ! ip route default 192.168..1 OpkgTap0 system configuration save Смысл состоит в том, чтобы дважды сменить имя интерфейсу, созданному NDM. Первый раз переименовываем в имя, которое ожидает увидеть приложение, предоставляющее интерфейс, Потом, переименованный интерфейс скармливаем приложению. (устанавливаем подключение, или запускаем сервис) А потом переименовываем обратно, чтобы NDM этот интерфейс не потеряло, когда будет к нему обращаться, и рулить им.

Спасибо за идею! Правда, всё оказалось чуть сложнее, но принцип подошёл идеально. ip link set opkgtap0 down ip link set opkgtap0 name vpn_vpn ip link set vpn_vpn up vpncmd localhost /client /CMD AccountConnect MyConnectionName ip link set vpn_vpn down ip link set vpn_vpn name opkgtap0 ip link set opkgtap0 up ip addr add 192.168..../24 dev opkgtap0 ip route add default via 192.168..1 dev opkgtap0 Т.е, приходится дважды его переименовывать при старте. Вначале в имя, которое должен создать клиент при поднятии подключения, чтобы познакомить клиента с интерфейсом, а потом обратно, чтобы NDM не теряла этот интерфейс.

Скорее всего, так и есть. Тогда, wan-бридж, вместо OpkgTap решил бы и проблему "неподдреживаемого интерфейса". С opkgtun - аналогично напрашивается возможность задавать имя интерфейса, чтобы не страдала совместимость с приложениями в opkg. Кстати, не подскажете как можно "смаршрутизировать" один интерфейс в другой? Если уж мостом не получается, так, может быть, на третьем уровне их соединить... "Носом чую" что так можно, но знаний не хватает...

Имелось в виду как-то соединить opkgtap0 и tap интерфейс, созданный приложением в opkg. Очевидное решение - бридж - не работает. Видимо, из-за особенностей реализации opkgtap0. Не понятно, почему бы не.., либо разрешить задавать имя создаваемого в opkg интерфейса (хотябы, брать его из "описания"), либо создавать и выпускать в opkg полноценный wan-бридж, как это сделано для лан-сегментов, к которым tap-интерфейс приложения из opkg подключается без каких-либо проблем - проверено - создаётся лан-сегмент, в opkg появляется соответствующий бридж (br0-br(n)), и в него добавляется tap интерфейс приложения - всё - приложение в этом сегменте как дома. Если не жалко одного-двух лан-портов, то можно и в wan тупо кабелем запустить, и настроить ещё одного ethernet провайдера, без танцев с бубном.

Ну естественно.

И нет. При Interface OpkgTap ip addres dhcp Вылетает ошибка, что dhcp не поддерживает тип интерфейса OpkgTap. Я, наверное, туплю дико - базовых знаний не хватает в этой области.

Да. Без ошибок, но в бридж я пихаю подключение от приложения и opkgtap0 в entware. У меня проблема в том, чтобы подключить интерфейс, созданный приложением, к этому интерфейсу. Ну и не понимаю как прописать шлюз интерфейсу OpkgTap0 в NDM. Я вообще плохо понимаю как оно должно работать с этим интерфейсом.

С этого начал, но... проблемы: 1. "Мой любимый софт" создаёт tap интерфейс. 2. Интерфейс он создаёт с префиксом к тому, что указывается в настройках, и изменить это поведение невозможно. Попытки объединть тот интерфейс с префиксом, с OpkgTap0 мостом ни к чему не привели. (объединяются, но результата нет) 3. dhcp (которым вполне себе логично было бы воспользоваться на tap интерфейсе в качестве клиента удалённого доступа) OpkgTap не поддерживает. Пример применения OpkgTun интерфейса разбросан по всей теме, относящейся к конкретному приложению, примеров по Tap вообще не нашёл. Идея понятная, и очень замечательная. Реализация, пока, для не специалиста, занимающегося сетями вплотную, не совсем очевидная. А отсутствие источников информации... Вам, за пример по OpkgTun, спасибо огромное. Тему создал, чтобы сложить в одну кучу разрозненную информацию по применению этих новых, и очень полезных фич.

Очень хочется примеров их использования для интеграции приложений entware с "экосистемой" NDM. Базовых примеров, демонстрирующих основные принципы их использования, с максимально возможным "разжёвыванием" этих принципов "для чайников".

А могу я в entware его в мост, например, запихнуть? А по dhcp он может настройки получать (ip, шлюз, днс, другие), как "другие"? "Приложение вообще не настраивает". А прочитать настройки оно может? А почему ему нельзя системное имя поменять? Из cli? Из приложения? Или можно? Например, задать системное имя в "описании" интерфейса в cli? Почему я не могу с тем же успехом в любой другой интерфейс (коих в системе дофига) так же поток данных направить? Забриджевать с приложением или созданным в приложении интерфейсом?