Pop70

Питанием USB порта передёрнуть?

Ага. И при старте кинетика, когда на его часах 01.01.1970 (емнип). Если дело в этом, то, возможно, поможет добавление команды типа ip host... В которой прописать ip адрес, соответствующий одному из ntp серверов. Ну, или напрямую в список адресов NTP вписать сервер по ip адресу, а не по доменному имени.

Я может правда полный идиот, но чем сломана "системная логика"? У меня от таких чудес уже у самого крыша едет.... Ниже селфтест.

Traceroute и ping. Я чтоли эти пакеты создаю? Или "логика" у устройства какая-то "слишком системная"

И вот эти 2 картинки. Даже с нормальным резолвом, с мобильника, через 2 ВПН. (Мобилка к роутеру, роутер к внешнему впн-серверу) Ip адреса идентичные, разница во времени - на время смены поддомена в строке запуска. Воспроизводится 100% Один поддомен сразу летит в локалку, второй гуляет хз где, хотя, оба должны по идее прилететь на роутер, на внешний ip. Для Вас этот момент явен? А я впринципе такого не понимаю.

Тогда, объясните мне поведение traceroute на этой картинке. Все 30 хопов звёздочек... На "локальный адрес"

И работает через раз. Иначе бы эта тема не возникла. После перезагрузки роутера, локальные сервисы то доступны через ВПН, то не доступны, то доступ прерывается, то возобновляется, то на другой стороне ВПН (где роутер - клиент) адреса резольвятся по-нормальному, то на "локальный" публичный левый адрес (если Вы утверждаете, что это работает независимо от днс, прописанного на клиенте, хотя, честно говоря, этот ip для моего домена выдавал только сам роутер в качестве днс-сервера - скорее всего, "независимо" будет только для CrazeDNS поддоменов, а вот роутерный днс зачем-то всю таблицу резолвит туда.) Имея нескольких провайдеров - вполне логично периодически проверять доступ через них, запуская коннект к ресурсам "по большому кругу", а эта схема, когда работает, впринципе не позволяет этого сделать. Никакого велосипеда. Это нормальная практика создавать записи на локальные адреса на собственном днс-сервере (он для того и нужен, в основном). "Велосипед" - это публичный адрес в качестве "локального", и нерабочий ping/tracert из админки, ломящийся непонятно куда, и падающее/поднимающееся рандомно подключение.

И разве нельзя для этих доменов создать А-записи с локальным(и) ip самого кинетика, вместо глобального "левого" адреса, совсем неявно зачем-то присутствующего в системе (маршрутизировать как-то трафик на самого себя по этому адресу роутер же должен?). Впрочем, что там для доменов 4го уровня CrazeDNS делается - по большому счёту, безразлично. Другие домены из таблички - не трогать - и всё.

Какое отношение к этому имеют домены третьего уровня, совсем НЕ CrazeDNS?

Блиииннн! Опять этот волшебный my.keenetik... Представляете какая каша творится с учётом всевозможных ВПН... Клиент подключается к кинетику, получает днс, резолвит адрес странички, которая крутится в локальной сети, и через другую ВПН (в opkg, например) лезет по этому адресу... в Германию! Я вообще не понимаю почему оно хоть иногда, хоть кииво, но работает...

Заметил неустойчивое поведение страничек, использующих поддомены моего личного зарегистрированного домена. Стал разбираться. Выяснилось очень интересное... Оказывается! Все домены и поддомены, указанные на страничке keendns, включая те, которые не имеют отношения к кинетиковским доменам, резольвятся на кинетиковские сервера. Т.е., прописав своё собственное доменное имя на страничке keendns (цель - доступ через встроенный веб-сервер, ssl сертификат...), я хожу на них через кинетиковский прокси. Ребята! Это баг! Не надо переопределять днс-записи для не кинетиковских доменов!

Хм... А подскажите зачем роутеру-то эта фишка (поиск сервисов в сети)? Разве не хосты в сети этим должны заниматься?

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

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

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

У меня на всех интерфейсах, и на 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 в имя, которое хочет видеть приложение, потом, поднимаем соединение в приложении, и переименовываем интерфейс обратно. Не уверен, что это сработает с любым приложением.