dchusovitin

5.1 Alpha 6 актуально. Добавил один пукт, убрал один. @Anna_ наверно не видели, если ориентироваться на баг с "перейти к закачкам"

Опять cloudfront Через скрипт в entware проще сравнивать ответы dns и ipset, более странные результаты получаются. Только он потерялся после переноса, попробую в бэкапах найти, может сейчас пригодится.

Если проверять, то только с WPA3 режимом (без комбинированного, как на скрине).

То же самое. Домен нужен только для отображения на главной странице (кажется только после исправления добавили), толку от него особого нет. Отсутствие валидации и "out of memory", намекает на оставшуюся проблему.

Еще куда-то символ потерялся в конце i параметров. После 0x должно быть четное кол-во символов. Удалите последний символ в каждом i (перед ">"). У меня прогрузилось, все подхватилось. PS. Но вот настройки не сохранились после импорта, вроде на форуме писали про этот баг =)

Куда-то потерялся закрывающий элемент у i параметров? Начинается с "<" и должен заканчиваться ">". Может просто ошибка копи-пасты на форум, вроде все верно.

Два разных сервиса. Экспортируете необходимую конфигурацию (совместимые протоколы), добавляете на роутер, используете любой способ маршрутизации (по доменам, из прошивки, entware). У них даже есть статья в faq - "Installation on Keenetic routers".

Пользователи и доступ - Порт управления по HTTPS Меняется вместе с портом админки (если заходить удаленно по домену), как и sstp.

Ссылка "Перейти к закачкам" (виджет "Приложения" на главной странице - Transmission) не активна, пишет "У текущего пользователя не хватает прав". В разделе "Приложения" (переход из левого меню) - ссылка активна и работает. У пользователя есть доступ к Transmission. Изменение (вкл/выкл) прав доступа не помогает. Появилось с 5.1 Alpha 3 Исправили -- Загружаем Wireguard конфигурацию через файл. Подключение создается, соединение выключено, но переключатель состояния - "вкл". Обновляем страницу и отображается правильно - "выкл". Возможно дело в том, что новое подключение встает в списке между двумя активными. -- Создаем два подключения Wireguard. Первое выключаем, второе включаем. Удаляем первое. Переключатель у второго меняется на "выкл". После обновления страницы отображается правильно. Два последних пункта воспроизводились с 5.0.3 (preview), приблизительно. Вроде никто не писал, либо не увидел. -- Сервер SMB. Добавляем первую папку в секции "Общий доступ". Она отображается в списке. Добавляем вторую папку, она не появляется в списке. Повторяем добавление второй папки, вылезает ошибка "Эта папка уже открыта для общего доступа". Полный список папок отображается только после сохранения. Если повторить действия (добавление новой папки), то будет такая же проблема. -- Иногда, при первом открытии сегмена страница может не прогрузиться и в консоли след. ошибка. Редко появляется (еще с 5.0), способа воспроизвести не нашлось. Что-то связанное с подгрузкой данных и иконками портов. # 5.1 Alpha 5 main-0C9DEBE.js:39 ERROR TypeError: Cannot read properties of undefined (reading 'style') at SVGRectElement.<anonymous> (main-0C9DEBE.js:208:8534) at SVGRectElement.<anonymous> (main-0C9DEBE.js:46:48932) at a.invokeTask (polyfills-0C9DEBE.js:4:62047) at Object.onInvokeTask (main-0C9DEBE.js:39:24976) at a.invokeTask (polyfills-0C9DEBE.js:4:61968) at B.runTask (polyfills-0C9DEBE.js:4:56927) at o.invokeTask [as invoke] (polyfills-0C9DEBE.js:4:63158) at g (polyfills-0C9DEBE.js:4:69934) at y (polyfills-0C9DEBE.js:4:70235) at SVGRectElement.m (polyfills-0C9DEBE.js:4:70501) handleError @ main-0C9DEBE.js:39

Так же, только ошибки добавлю. Фев 28 18:56:39 ndm Ntce::Database: invalid type set. Фев 28 18:57:05 ndm Core::Syslog: last message repeated 15 times. [19:00:56:229] [RCI error]: { "status.0": { "message": "invalid type set.", "code": "13632488" } }

Тогда включить - interface Proxy0 debug Там хотя бы видна будет информация в логе, куда подключается и что примерно происходит.

Больше похоже на то, что прокси выплевывает мусор на CONNECT запрос (не поддерживает). Банально конечно, но через работоспособность проверялась (через настройки браузера или прокси-плагины).

Побочный эффект (в теме по ссылке был об этом разговор), если хочется чтобы встроеная dns машрутизация и adh работали вместе. Значит заработало. Либо adh на своем порту (не 53) + "no opkg dns-override" и работает с dns маршрутизацией. Либо adh на 53 порту + "opkg dns-override" и не работает (с некоторым исключением) dns марштутизация. Выбрать надо одно. Не надо указывать dns в свойствах подключения к провайдеру (ethernet, pppoe, ...), "игнорировать" поставили и хватит. Указывайте в одном месте - "интернет-фильтры" - "настройка dns" - "системный". Как выше написал Denis P. Возможно еще указаны dns в настройках сегмента (dhcp - dns), после игр с настройками, тоже можно убрать (хотя не должно мешаться, если там 53 указан).

"opkg dns-override" включен? Раз adh заводится на 53 порту. Значит надо отключить, чтобы все вместе работало.

Время синхронизируется раз в 7 дней (по умолчанию), только для небольшой корректировки. Опциональное действие. Перезагрузка -> Отвалился DNS -> Не может подключиться к серверам кинетика -> Нет доступа через облако. Примерно так, скорее всего. Снять галку с игнорирования DNS провайдера и/или хотя бы добавить один-два сервера в секцию dns (кинетика). Должен ожить, если хоть кто-то есть рядом с роутером

Настройки надо показать, хотя бы. Какой ip:port указан в кинетике (adgh), какой ip:port слушает adgh, какие bootstrap сервера указаны в adgh. В логе кинетика, либо само adgh должна быть видна причина. Скорее дело в кэше (из-за этого временно работает). Больше похоже на то, что они висят на одном порту и после перезагрузки adh не полностью стартует, а кин обращается к метрвому adg. Хотя не все объесняет Так примерно надо сделать:

Немного покапался, ntce не виноват (изначально была идея), ndnproxy тоже (судя по трейсам). Но задержки видно. strace у процесса ndnproxy и у dig (из entware), один запрос, одновременно. Апстрим dns на 65053 (adgh), домен gosuslugi. adgh и ndnproxy быстро обрабатывают запрос (в пределах нескольких миллисекунд). Ответ до клиента доходит через 150+ мс. Где-то застревает в недрах ndm, хотя бы видно разницу. strace-gos-ndnproxy-3.txt strace-gos-dig-3.txt

Тоже самое, +100-200 мс на любой запрос, при наличии одного правила с пустым списком.

Это интерфейс админки роутера, у нее авторизация работает по другому. В один запрос там не авторизоваться. Раз, два Здесь используется 79 порт (не 80, как выше), на котором вообще нет авторизации. И сверху добавлена http basic авторизация (отличается от пред. пункта). Обращение по домену rci должно работать из локальной сети. Если надо закрыть доступ из внешней сети, то чуть сложнее (и могут быть некоторые проблемы, насколько помню). В локалке открыть доступ можно через перенаправление портов, но без авторизации (так что не надо так делать). И через софт в entware.

И кстати, на первом скрине ошибка в настройках. У doh домена в поле "домен" вписали значение, оно для другого нужно. Поле нужно очистить. Если заполнено, то этот сервер обслуживает запросы только на указанный домен. Из-за этого использовались провайдерские DNS. У DoT можно указывать "Домент TLS".

Тут к владельцу надо обращаться, на его стороне проблемы. dig/kdig отказываются подключаться, ошибка на уровне tls. Только пару утилит принимает его, которые не используют системные библиотеки. Если изменить на DoT, то сразу заработает. Гугл скорее по причине блокировки отвалился, там нечто другое. * поддерживает только http1.1 и из-за этого tls (alpn) фэйлится у части клиентов.

Изменить пароль админа, поставить более сложный. https://blog.keenetic.ru/pre-keeneticos-43-update/ Версия 4.3.6.3: Публичный доступ к веб-конфигуратору теперь блокируется на устройствах со слабыми паролями администратора, что снижает риск несанкционированного доступа. [NDM-4097]

Использовать доп. софт, поднять прокси и указать с какого интерфейса отправлять трафик. Либо, вариант проще. Использовать mihomo (вместо awg-go), там из коробки есть возможность запуска прокси. Генератор конфигурации умеет это делать.

Со временем починят, когда побольше людей напишут. Я наблюдал схожее, хоть сразу и не написал. На меньшем кол-ве доменов, и на ultra 1811/1812. Т.е. (возможно) производительность cpu не особо имеет значение. Как будто, где-то очередь, которая разбирается последовательно. Adguard тоже помогал (за встроенным dns), с включенным optimistic caching (отвечать всегда из кэша) и увеличинным ttl.

Не могу особо утверждать, но отключение немного странно работало (5.0.3). Убирались правила/маршруты, но наполнение ipset и/или опрос доменов продолжал крутиться в фоне (еще может от галочек зависеть, оба варианта). Надо было удалить правило полностью (список можно оставить), и лучше перезагрузиться. dns-proxy debug может помочь в определении, но вывода отладочной информации в журнал там будет много.