keenet07

А как иначе диагноз поставить? )) Я не экстрасенс. И не нахожусь на месте, чтоб без лишних вопросов всё проверить. Просто задал направления. Только так. Или гадать. Нужно дать пациенту рассказать больше.

А вблизи кинетика устройства ловят? Какой уровень сигнала? Может быть что-нибудь с антеннами или проводами от них. Вблизи нет других источников WIFI? Не использовано ли в стенах помещения чего-нибудь, что может дополнительно экранировать сигнал? Какой роутер у провайдера? И хорошо бы понимать на сколько с ним сигнал лучше.. Или тоже на грани, но немного ловит? Можно попробовать пофиксировать ТД на разных каналах.

Если вы ничего не перепутали, то даже и не знаю. Время в ЛК провайдера местное? Не имеет ли аккаунт возможности множественного входа. Т.е. нельзя ли под ним работать с разных устройств.

Ну можно и частями конечно. )) И что у вас эта цифра за сутки не совпадает с тем что на верхнем скрине?

На верхнем да. По идее весь, во всяком случае не меньше точно. Только если вы устройство перезагружаете, он сбрасывается. Чтоб свериться с провайдером нужно месяц без перезагрузки роутера.

Монитор трафика Топ-5 это не весь трафик который проходит с модема. Это только Топ-5 подключенных зарегистрированных устройств. Интернет ещё может потреблять сам роутер, по служебным целям. Обновления и прочие. А ещё какие-то незарегистрированные устройства. Или если у вас их вообще (устройств) вообще работает больше 5 шт. В Монитор трафика это не попадает. Это только Топ-5 самых активных. Добавьте все устройства по отдельности в новые вкладки и просуммируйте трафик по ним.

Странно, непонятно. Что-то там у вас все хосты в перемешку. И локалка и внешка. Не уверен что так должно быть. Кстати, она у вас похоже показывает всё на бридже br0 судя по заголовку окна на скрине. Она у вас не сконфигурирована.

Вы ведь как-то darkstat запускали. Если в ручную, то интерфейс в этой команде указывается. Если он у вас в автозагрузке, то в файле. А текстовую статистику помимо графиков то вы видите? Там вообще есть что-то похожее на то что вы по WAN получаете/передаете? Имею в виду хосты. https://www.lissyara.su/articles/freebsd/traffic_count/darkstat/ https://openwrt.org/docs/guide-user/services/network_monitoring/darkstat

Тогда, как вариант, попробуйте запустить с параметром eth2.2

Я не в курсе соответствия интерфейсов из конфига роутера (то что я назвал) и тех что в OPKG. Если вы знаете, то наверное правильно говорите. )

Где-то там у вас в файлах конфиг должен быть. Если его нет, то наверное нужно его создать с учетом синтаксиса программы и куда-то положить на кинетике. (понимаю, что инструкция так себе, но что есть.. ) В нем выбор интерфейса. В инструкции выше стоит eth3, но на Кинетике у меня, например WAN это eth1 (GigabitEthernet1) На каком у вас WAN можете в файле настроек роутера увидеть, если выгрузить его. Или в CLI по команде show interface Нужно посмотреть и поменять в конфиге этой программы.

На графиках понятно. 75 Мбайт передано, причем скорее всего в обоих направлениях. И виден наблюдаемый период 17 часов. Надеюсь вы в конфиге darkstat верно указали сетевой интерфейс своего модема. А то может быть он у вас и считает чего-нибудь не то. А на Кинетике информация за какой период? И ещё, не забывайте, что Кинетик скорее всего показывает не трафик модема с оператором 3G/4G, а весь трафик от модема к роутеру. Если я не ошибаюсь.

Вновь поднимаю вопрос и прошу проголосовать. На странице маршрутизации нужны группы для объединения нескольких маршрутов и простого переключения их на любой выбранный VPN. Предположим у меня настроена работа некоторых сайтов через какой-либо VPN на кинетике. Это выглядит как множество правил маршрутизации настроенных на выход через этот VPN. Если VPN по какой-то причине вдруг временно не работает, для того чтобы переключить все эти правила на другой VPN придётся либо редактировать само неработающее VPN подключение (менять адрес сервера, шифрование и прочие настройки). А часто резервное VPN соединение вообще может работать на другом протоке (OpenVPN, L2TP и другие), тогда вообще придётся вручную изменять каждое правило маршрутизации, меняя в нем VPN подключение на новое. В общем, проще было бы иметь возможность в одно действие поменять выходящий VPN сразу для всей группы маршрутов.

Вот пример настройки для актуальной прошивки. Для вашей старой делайте соответствующие поправки, если на ней вообще работает multi-wan. https://help.keenetic.com/hc/ru/articles/360016262100-Пример-настройки-доступа-определенных-устройств-через-разные-интернет-подключения

Вы спрашиваете, как поменять IP адрес для резервного подключения? Если да, о расскажите какие подключения у вас есть.

На самом роутере такая возможность вряд ли появится. В чипе нет режима ожидания. Можно только перезагрузить. Но если сильно хочется, можно купить умную розетку, подключить через неё роутер, а потом отключать её из приложения умный дом с мобильника через облако.

Скорее всего для реализации данной возможности понадобятся группы(списки) адресов. Для того чтобы на уровне конфига и в веб-интерфейсе это не выглядело как множество повторяющихся правил блокировки с разными IP. Достаточно будет одного правила где вместо адреса будет список из IP адресов. А блокировка самого списка это уже внутренняя кухня самого устройства. Так же нужно подумать каким образом из этих списков вычищать когда-то добавленные, но больше не используемые IP адреса для доменов. Иначе в конечном итоге их там может накопиться много, но какие-то из адресов уже потеряют актуальность. Возможно для каждого адреса в списке понадобится такой параметр, как время активности/не активности. Т.е. если при резолвинге домена какой-то из IP адресов больше не попадается уже какое-то продолжительное время, то его можно удалить из списка, как возможно больше не используемый. Про необходимость механизма периодического обновления/пополнения списка IP адресов я вроде упоминал. Но можно привязать его к обычному штатному DNS запросу. Т.е. когда пользователь обращается к сайту, происходит DNS запрос через роутер, а он уже исходя из DNS ответа дополняет список для этого домена (если он создан) новыми IP адресами. При удалении последнего правила где список используется удаляется и сам список.

Может быть это есть в CLI?

Согласен, но только если это будет опционально. Как владелец единственного устройства, не хотелось бы видеть перегруженность CLI какими дополнительными надписями. И для шапки тоже, ничего больше не выводить, если routername не задан.

1. Сделайте пожалуйста какие-нибудь значки показывающие тип подключения устройства (проводное или Wi-Fi) в интерфейсе Монитора трафика в правом столбце со списком устройств и в контекстных информационных окошках на графике. 2. А также нужна какая-то возможность при клике на название устройства в Мониторе трафика переходить к нему в Списке устройств. Там дополнительной информации о нем побольше. Иначе он какой-то такой абстрагированный получается.

Вроде всё давно выделено. Разве данная просьба не реализована? Поперемещал бы кто-нибудь не актуальные и реализованные темы. Чтоб на старье не натыкаться при просмотре.

Да даже и в таком DNS сервере нет необходимости, когда можно обращаться к любому существующему через VPN.

Я об этом сразу и написал. А можно просто фильтровать трафик где есть ESNI и нет SNI. Как? ПО списку известных DOH/DOT DNS серверов? И фильтру по слову DNS в доменном имени? А как оно неизвестный безымянный DOH DNS сервер опознает. По моему - никак.

Нет, не одно и то же. А как вариант хоть как-то управляться с HTTPS трафиком. (как-нибудь по простому заблокировать какой-то сайт на устройстве. А не для всех граждан страны.). Остальное другими методами. Подход нужен комплексный. Про внедрение в защищенный HTTPS трафик я здесь вообще и не говорю. Это совсем кардинальные метод. И он не без очевидных минусов. А панацеи в URL-фильтрации вообще не существует. Её всегда можно обойти. А что такого для DNS-фильтров есть нужного в SNI на данный момент?

Видимо данная тема будет висеть в топе вплоть до появления устройств во всей линейке продуктов с процами достаточно мощными для беспросадочного переваривания фильтрации хотя бы по SNI с актуальными на тот момент скоростями. Функционал DPI. А значит процы должны быть с большим запасом, выполнены по достаточно мелкому техпроцессу, низкой ценой. Т.е. дело за прогрессом. Но когда всё это ещё будет. К тому времени может быть уже смирятся с ESNI или уже окончательно будут его запрещать и игнорировать. В текущий момент данное пожелание скорее всего не реализуемо.