dchusovitin

Тогда включить - 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]

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

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

... треть интернета отвалилась в М/МО, не говоря уж про указанный сервис Оживет с параметрами из более свежих версий awg, если повезет (мне да).

Софт (shadowsocks-rust, -libev) поднимает локальный socks. Через компонент прошивки "Клиент прокси" создается подключение, сетевой интерфейс доступен и можно делать роутинг. Доступно в 4 версии прошивки. В 5 версии прошивки немного проще, благодаря OpkgTun. Создаем tun интерфейс через cli, софт/прошивка его использует. ss-rust умеет в tun режим. Есть более удобные инструменты - mihomo. Поддерживает ss и оба режима (прокси/tun).

Ошибка какая? Порт нужно указывать, плюс дебаг режим включить. Прошелся по истории комманд, как минимум консольному sstpc нужен флаг "--tls-ext". sstpc --user admin --password pass --tls-ext --log-level 4 --log-stderr domain.netcraze.link:port Плюс настройка ppp, но его настроек не сохранилось. Через плагин в NetworkManager просто поднимается, его легче использовать. И подсмотреть примерные аргументы для pppd у процесса. Но я отказался от sstp, в пользу openconnect, с ним все проще

Или так, по сути одно и тоже Большинство работает в 1080p, так что заметно будет.

У кого-то стоит плагин в браузере для обхода, либо способ через "днс", либо из-за ipv6 (неправильного определения геолокации). PS. Или сообщение выше, от spatiumstas =) Рандом и с другими доменами случается, но заметить сложнее.

Чтобы появился 1080p, т.к. он выключен для РФ. Нормальный пример, суть теста в частом смене адресов и большом пуле. Один (или два) домен добавить для теста в маршрутизацию - usher.ttvnw.net (+ gql.twitch.tv) Желательно обновлять страницу (чтобы поймать рандом и увидеть), или смотреть на наполнение ip (лучше). Если прыгать по трансляциям, то разницу можно заметить (пропадет 1080p). Сначала все работает, идет наполнение. Потом начинаются странности, описанные в пред. сообщении. С большинством сайтов нет особых проблем, если ip редко меняются. Я жду обновления, потом проверю и кину сценарий в поддержку. Если использовать альтернативные способы маршрутизации, то работает стабильно.

Заметно на cdn с гео ограничениями. Можно устроить тест на твиче (для работы 1080p), пустив два домена по маршрутам. Там вообще какие-то чудеса творятся. Бывает, что добавляется в object-group/ipset только один IP из четырех. Точнее практически всегда В object-group/ipset накопилось несколько десятков (под сотню) IP (т.к. все за CDN). Вроде корректно. Но тот добавленный (указанный выше) IP исчезает из списков через несколько секунд. Магия

Месяц уже ждем

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

Хотя бы один из вариантов исключили Я с нечто похожим тоже сталкиваюсь. На одну и туже конфигурацию (и ip сервера, схожей с вашей), вижу случайные проблемы. То не "подключается" (хэндшейки режутся) 5+ минут, то в один момент все начинает работать. С приложением не сравнивал, но скорее это проделке фильтров у прова.