dimon27254

Кажется, "по многочисленным просьбам" появился тот самый долгожданный oldstable в виде ветки lts_4.3: Однако, переход на него пока недоступен. При обновлении NDSS возвращает ошибку 403:

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