dimon27254

@eralde @Anna_ @Test Pilot Если полностью отключить один из диапазонов Wi-Fi (выключить все связанные с ним сети сегментов), то при обращении на страницу Сегменты или Точки доступа появляется оповещение: Оно не пропадает с экрана, пока соответствующий диапазон выключен. Даже при переходе на другие страницы в рамках одной сессии. Оповещение выглядит немного незаконченным. Должно ли оно вообще отображаться? Проверял на NC-2312 с 5.1 Beta 0.1.

@eralde @Anna_ @Test Pilot 1. Здесь не помешало бы также убрать все упоминания о 6 ГГц на роутерах, где этого диапазона пока нет - что в селекторе FT, что в меню выбора Band Steering. 2. В продолжение сообщения: Настройки FT действительно не отображаются: Однако, если кликнуть по любому диапазону, то ранее введенные параметры роуминга появятся. 3. Поле "ключ мобильного домена" теперь оформлено как обычное текстовое, значение более не скрывается. 3.1. Не помешало бы для данного поля исключить ввод кириллицы, чтобы не получилось вот так: Проверял на NC-1812.

Веб-интерфейс и так минималистичен и скуден на цвета, а тут даже в названии бренда этот цвет "забрали")

Может быть, через годик-другой все таки появится лоадер 🥲

Добрый день. Да, по моему мнению стало хуже. Раньше отчётливо цветом выражался фирменный цвет компании, который визуально добавлял "красок" в интерфейс. А теперь выглядит как-то "обыденно".

Геоблокировка не накапливает адреса. Она использует загруженные списки и по ним ограничивает доступ. Просмотр загруженных списков геоблокировки недоступен, так не имеет смысла - там может быть до 100 тысяч адресов, смотреть на которые в консоли или ещё где-либо точно не будет удобно.

Пришлите, пожалуйста, в личные сообщения self-test. Попробую посмотреть, в чем у вас может быть дело.

Как вы проверили, что у вас действительно eth3? Может быть, там будет eth2.2 или что-то другое.

Геоблокировка тоже не работает? Маловато вводных. Может быть, не выбран правильный интерфейс, или же у вас серый IP-адрес.

К сожалению, в 5.1 Alpha 7 каких-либо положительных изменений не увидел. Включил dns-proxy debug, и, кажется, NDMS решила новые IP домена просто пропустить, отдав только клиенту. Ниже self-test с включенным dns-proxy debug. Время запроса 18:56:16, на сервере 18:56:17. @admin может быть, все-таки рассмотрите вариант сделать обработку запросов, как это реализовано в dnsmasq? По сути, входной и выходной точкой всех запросов является ndnproxy, в том числе в политиках. Нельзя ли его "научить" извлекать IP-адреса из ответов upstream и загружать в object-group fqdn налету? Чтобы избавиться от всего того, что сделано сейчас и работает не совсем хорошо. Я ранее пользовался dnsmasq, сейчас в основном MagiTrickle - там все работает идеально. Хотелось бы видеть, что также идеально все работало и "в стоке". Текущая реализация, к сожалению, очень далека от идеала.

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