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) если интерфейс не "точка-точка"

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