dimon27254

И это, к сожалению, проблема. Предположим, роутер получил от провайдера белый IP 1.2.3.4. В него же резолвится домен. Пока само подключение работает, все хорошо - из локальной сети можно успешно зайти по домену на роутер, никаких проблем не возникнет. Однако, как только это самое подключение отвалится, или же сменится внешний IP-адрес (вместо 1.2.3.4 провайдер выдаст 4.5.6.7), доступ к вебу из локальной сети окажется невозможен, потому что домен ссылается на старый IP, который больше доступен. Приходится ждать некоторое время, пока обновятся DNS-записи у резервного провайдера, чтобы я смог зайти в веб именно по домену. Простой пример, как можно себе "выстрелить в ногу" из локальной сети при "текущем положении дел": зайти в веб-интерфейс по домену, и выключить основное подключение с белым IP. Веб-интерфейс сразу же перестанет работать, потому что внешний IP оказывается недоступным. Другой пример: Спокойно пользуемся интернетом, "ничего не предвещает беды". По какой-то причине провайдер с белым адресом отваливается. Я через облако получаю уведомление, что подключение недоступно. Хочу быстренько сразу же зайти в веб из локальной сети по домену и посмотреть, что произошло, а не получится - домен ссылается на недоступный IP. Можно, конечно, просто заходить в веб из локальной сети по локальному IP, но я с самого момента перехода на Кинетики привык заходить в веб-интерфейс даже из локальной сети по домену. Поэтому данное изменение не считаю корректным.

Да, так запись возвращается. Это ожидаемое поведение в последних 5.0 и 5.1? Раньше я помню, что из локальной сети CrazeDNS-домен всегда возвращал 78.47.125.180, вне зависимости от режима доступа.

В таких условиях, думаю, лучше ответить, что запрос обработает первый, кто перехватит запрос на IP 78.47.125.180.

Откроется главный, через который вы выходите в интернет.

Да, у меня тоже начало возвращать 78.47.125.180. Значит, подправили после моего сообщения 🙂 Спасибо!

И этот вариант не корректен 😁 Везде в инструкциях и на коробках Неткрейзиков пишется my.netcraze.net. А значит, должно работать по нему 🙂

Я не считаю это полноценным решением. Если вдруг у пользователя просто в браузере или на устройстве будет стоять публичный DNS вместо Неткрейзика - он уже не попадет по my.netcraze.net. В Кинетиках же можно использовать хоть какой DNS - все равно гарантировано будет работать my.keenetic.net.

78.47.125.180 в роутере "вшит", однако чтобы устройство на него могло попасть, нужно как-то ему подсказать, что за доменом my.netcraze.net числится тот самый 78.47.125.180. Домен my.keenetic.net с любого DNS, даже публичного, всегда разрешается в 78.47.125.180. А в my.netcraze.net при использовании сторонних DNS можно увидеть, что там оказываются IP-адреса серверов Selectel, используемых Netcraze.

В 5.0 и 5.1 гиперссылка уже работает. Мы её долго ждали, но когда-то дождались. Спасибо 🙂

@Anna_, нет ли каких-нибудь новостей по возвращению "цвета" в кнопки удаления?

@Anna_ В 5.1 Alpha 6 все еще актуально.

@admin @hlnw В 5.1 Alpha 6 актуально.

@hlnw @admin По каким-то причинам NDMS в процессе загрузки удаляет статическую A-запись на CrazeDNS-домен. [I] Mar 15 19:12:21 ndm: Dns::Manager: added static record for "*.netcraze.link", address 2001:2:7847:1251:feee:ed78:4712:5180. [I] Mar 15 19:12:21 ndm: Dns::Manager: deleted record "*.netcraze.link", address 78.47.125.180. В результате домен из локальной сети начинает резолвиться не в 78.47.125.180, а во внешний IP-адрес. При этом, AAAA-запись остается на месте. Проверял на NC-1812 с 5.1 Alpha 6.

В 5.1 Alpha 6 на NC-1812 удалось воспроизвести ситуацию, когда object-group fqdn не успевает пополнять собственный список IP-адресов новыми, но dns-proxy эти новые уже успешно отдает клиенту. В качестве DNS-сервера использовал AdGuardHome на VPS, где мог посмотреть статистику запросов. Проверяемый домен - tr.rbxcdn.com. На нем очень быстро меняются A-записи. 0. Очищен DNS-кэш на устройстве, а также перезапущен роутер для очистки runtime-кэша в object-group fqdn. 1. Сделал несколько попыток ping с устройства на данный домен. Запрос успешно прошел через роутер и VPS. Все IP из ответа DNS успешно попали в object-group fqdn. На скриншоте привел время запроса и ответ. 2. Спустя ~40 секунд сделал повторный ping. Windows выполнила перерезолв домена и получила новый IP. Запрос снова прошел через роутер и VPS, однако здесь как раз и появилось расхождение между object-group fqdn и отдаваемым dns-proxy IP-адресом. Скриншот 1 - пинг по новому IP и просмотр записей в object-group fqdn. Скриншот 2 - детали запроса, сделанного клиентом через роутер, где уже видны новые IP, один из которых получил клиент. 3. Через некоторое время сработал авторезолв, и список накопленных IP обновился теми, которые получил клиент ранее, потому что прошивка сделала повторный запрос. На практике вот такие "подтормаживания" логики NDMS приводят к тому, что реальный HTTP-запрос клиента уже давно проскользнул мимо туннеля, потому что актуальный IP не успел попасть в object-group fqdn. Приходится по несколько раз перезагружать страницу, или же ждать по минуте-две, пока браузер сам не попытается что-то предпринять.

В 5.1 Alpha 6 исправление подтверждаю. Спасибо!

Выглядит непривычно. И никакой "изюминки" цветовой теперь нет 😅

@eralde @Anna_ @Test Pilot В Alpha 6 название бренда и модели теперь выводится одним шрифтом: Это какая-то ошибка, или так и задумано? Вариант из 5.1 Alpha 5 и ниже был более заметным:

В прошивке 5.0.6 и выше появилось WSD-сканирование (WS-Discovery), сделанное с целью более точного обнаружения устройств, подключенных к ретрансляторам Mesh-системы. Некоторые камеры на него не очень адекватно реагируют, ожидается исправление данной ситуации:

Подтверждаю исправление в 5.1 Alpha 5. Спасибо! Еще бы сделать не IPV4/IPV6, а IPv4/IPv6, чтобы все было совсем красиво 🙂

Отправил вам на изучение свою "жертву WSD". Через недельку-полторы доберется до московского офиса. В тикете поддержки описал, как попасть в веб-интерфейс и что для этого потребуется.

Проблеме подвержены только прошивки 5.0.6 и выше, где включен WSD. Поэтому откат на стабильную 5.0.4 полностью решает проблему.

Возможно ли реализовать проверку вводимых пользователем значений со стороны NDMS? Чтобы система принимала только значения, соответствующие или синтаксису ASC, или пустую строку. Сейчас в I-параметры можно вводить что угодно, и ни NDMS, ни ядро каких-либо ошибок не отобразят, а у пользователя (который не знаком с "внутренней кухней", а просто на руки получил или создал себе конфиг) может сложиться ложно-положительное ощущение, будто введенные им параметры корректны и работают.

В 5.1 Alpha 3 исправлено. Спасибо!

В 5.1 Alpha 3 исправлено. Спасибо!