Noksa

Как вариант. Я бы конечно предпочёл вариант по системным часам. Появился интернет, синхронизация прошла - учли этот момент. Нет интернета, нет синхронизации - используем время которое уже установлено. В таком случае мы можем гарантировать что когда всё штатно - ребут произойдёт именно в желаемое время. В случае же полной недоступности интернета на роутере с самого старта его работы - как минимум он перезагрузится один раз в сутки.

Здравствуйте! Прошу пересмотреть логику кнопки «Перезагрузить модем» и последующего автоматического восстановления USB-модема. Использую Keenetic Giga KN-1012, KeeneticOS 5.1.8, USB-модем Intel L850 / Fibocom L850-GL. Иногда после перезагрузки модема либо самого роутера модем не определяется. В веб-интерфейсе отображается «Модем не подключён», хотя он физически подключён и его индикатор продолжает гореть. Ранее фиксировали такое состояние интерфейса: plugged: no connected: no link: detached ipv4: detached ipv6: detached ctrl: detached После попадания в это состояние модем самостоятельно не восстанавливается. Повторных попыток отключить и включить его питание со стороны роутера не наблюдаю. Интернет отсутствует, но роутер продолжает работать. На момент последнего такого случая Ping Check был настроен, а для интерфейса уже присутствовала команда: interface UsbLte0 usb power-fail 60 reboot Хотелось бы, чтобы операция «Перезагрузить модем» включала проверку результата: появился ли модем обратно после перезагрузки. Если он не появился за отведённое время - повторить физическое отключение и включение питания соответствующего USB-порта, с ограничением количества и частоты попыток. Здесь так же надо предусмотреть вариант когда роутер перезагружается сам - в этом случае модем "появляется" первый раз и может так же зависнуть в таком неопределившемся состоянии, еще до выполнения операции "Перезагрузить модем". Из-за этой проблемы пришлось добавить собственный watchdog через Entware, который при длительном отсутствии интернета перезагружает весь роутер. Но для удалённого объекта хотелось бы иметь штатный механизм восстановления самого модема. Подскажите: Проверяется ли появление модема после выполнения перезагрузки модема? Почему в состоянии plugged=no восстановление может прекращаться, несмотря на настроенный usb power-fail? Можно ли доработать этот сценарий, чтобы не требовались ручное вмешательство или собственный watchdog?

Здравствуйте! Хотелось бы добавить опцию, позволяющую выполнять штатную перезагрузку по расписанию до первой успешной синхронизации времени с NTP после загрузки. Столкнулся с этим на удалённом объекте: Keenetic Giga KN-1012, KeeneticOS 5.1.8, интернет через USB LTE-модем. Была настроена ежедневная перезагрузка в 04:00. После очередного старта интернет через модем не восстановился (Модем просто не определился роутером, питание при этом на нём было - кинетик просто перестал его перезагружать по питанию потому что он не определился как модем, что бывает не так уж и редко). Когда приехал на место, uptime составлял около трёх суток - ежедневные перезагрузки не выполнялись, хотя настройка расписания сохранилась. Веб-интерфейс показывал неверную дату и время. Ручная перезагрузка восстановила соединение. Поддержка Netcraze подтвердила, что выполнение расписания зависит от синхронизации времени с NTP и до её успешного завершения расписание не выполняется. Получается замкнутый круг: Нет интернета → нет синхронизации времени → не выполняется перезагрузка, которая могла бы восстановить интернет. Предложение: добавить для system reboot schedule явно включаемый режим, условно force / «Выполнять без синхронизации времени». Желаемое поведение: расписание выполняется по текущим системным часам роутера независимо от наличия синхронизации с NTP. Понимаю, что при неверных часах перезагрузка произойдёт не в реальные 04:00. Для аварийного восстановления удалённого объекта это приемлемо: важнее, чтобы ежедневный ребут вообще состоялся. Если системные часы продолжают идти, неправильная дата или смещение времени не должны полностью лишать устройство этого способа восстановления. Текущее поведение можно сохранить по умолчанию, а такой режим включать осознанно, с предупреждением о возможном несовпадении с реальным временем.

На KeeneticOS 5.1.6 словил странную вещь. Добавил netcraze.pro в группу доменных имён и отправил эту группу через провайдера напрямую (чтобы точно не попасть в какой-нибудь туннель!). После этого стали плохо открываться совсем другие сайты, которых в группе нет. Страница висит, потом само проходит, потом снова повторяется. Дело в том, что роутер берёт не только само имя, но и поддомены (что конечно же вполне ожидаемо и правильно). Но облачное имя самого роутера как раз такое: <имя>.netcraze.pro. Оно указывает на внешний адрес самого роутера (прямой доступ), и этот адрес попадает в список группы. Дальше ломается уже весь интернет. Ответ сайта приходит на внешний адрес роутера. Роутер видит его в списке группы и метит ответ. А в таблице этой группы нет пути в домашнюю сеть, там только провайдер. Поэтому ответ компьютеру уходит обратно провайдеру и до компьютера не доходит. Проверить легко: если внешний адрес роутера есть в списке группы, причина в этом. ipset test _NDM_OGDN_4_@имя-группы <внешний-адрес-роутера> Сайтов, которые не открываются, в этом списке при этом нет. Адрес роутера появляется там, когда резолвится его облачное имя, и потом сам исчезает по ttl. Отсюда и ощущение, что интернет то есть, то нет. Я убрал netcraze.pro из группы и удалил внешний адрес роутера из списка не дожидаясь его автоматического удаления и всё снова открывается. Было бы хорошо, если прошивка сама не добавляла адреса самого роутера (публичные, при прямом доступе по крайней мере) в такой список. И ещё - было бы здорово если в таблице DNS-маршрута была домашняя сеть, как она уже есть у обычной политики подключений. В целом это касается не только netcraze.pro конечно же, а любого домена который вы можете выбрать в CrazeDNS. Вот такой вот интересный опыт

Добрый день. В целом, уже ответили выше. Я лишь добавил бы, что UI версия давно не обновлялась и была написана еще до выхода даже 5.1 версии ОС в Keenetic/Netcraze. Поэтому если Вы будете загружать через неё например AWG v2 конфигурационный файл, то с бОльшей долью вероятности он либо не загрузится совсем, либо загрузится как v1. В cli версии уже есть поддержка AWG v2 файлов, как и многое другое, о чём я тут просто не писал. К сожалению у меня нет времени поддерживать UI версию, она создавалась скорее исключительно как быстрый вариант загрузки AWG файлов в роутер и не более того.

Отключение IPv6 помогло. DNS маршрутизация сейчас работает только с IPv4. IPv6 идёт напрямую.

Если по кабелю, то в "Кабель Ethernet" во вкладке "Интернет":

Отложилось на 5.0.5?

Есть две KN-1012, все 5.х.х версии работают без проблем, сейчас на 5.0.4

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

В 5.0.3 ощущение что вообще немного сломалась маршрутизация DNS, если сравнить с 5.0.2. Обновился 4 дня назад. И вот сегодня некоторые маршруты просто не работают. А возможно это и раньше было, просто не обращал внимания show object-group fqdn показывает следующее (на примере конкретного домена): { "group-name": "work", "enabled": true, "ipv4-addresses-count": 114, "ipv6-addresses-count": 111, "fqdn-count": 46, "entry": [ { "fqdn": "cloud.elastic.co", "type": "runtime", "deadline4": 17, "deadline6": 78, "fail-counter4": 0, "fail-counter6": 3, "last-external": 294, "last-list-changed": 294, "parent": "elastic.co", "ipv4": [ { "address": "151.101.1.94", "ttl": 60, "last-updated": 43 }, { "address": "151.101.65.94", "ttl": 60, "last-updated": 43 }, { "address": "151.101.129.94", "ttl": 60, "last-updated": 43 }, { "address": "151.101.193.94", "ttl": 60, "last-updated": 43 } ], "ipv6": [] }, Вроде бы наполнение IP адресами есть. Но трафик не идёт через настроенный туннель, в итоге получаем отлуп от серверов если открыть в браузере cloud.elastic.co: Галочки соответственно все стоят в "Правила маршрутизации" как и стояли раньше для этого списка: Т.е. сейчас такое ощущение что маршрутизация по DNS в моём роутере полностью отвалилась, как минимум для конкретного домена и его поддоменов и трафик идёт напрямую. Могу приложить ещё какую-нибудь информацию, если подскажите какую, надеюсь это поможет пролить свет на причину.

Всем привет. В связи с ближайшим релизом 5.x версии добавил поддержку добавления\удаления маршрутизации через DNS домены. Релиз: https://github.com/Noksa/gokeenapi/releases/tag/v1.6.0 Краткий пример конфига: dns: routes: groups: - name: social-media domain-file: - domains/social-media.txt interfaceId: Wireguard0 - name: streaming domain-url: - https://example.com/streaming-domains.txt interfaceId: ISP Запускаем команды: # Добавляем gokeenapi adddnsrouting --config <config>.yaml # Удаляем gokeenapi deletednsrouting --config <config>.yaml После добавления всё автоматически включится и начнёт работать сразу же. Есть возможность подгружать домены через ссылки (поле domain-url) - чтобы не нужно было вручную их держать и обновлять локально в файлах, при желании.

Добрый день! В последней версии был добавлен встроенный планировщик, чтобы не было нужды оборачивать запуск утилиты через такие вещи как ansible/crontab/что-либо ещё если необходимо запускать команды для нескольких роутеров. Простой случай: Есть 6 кинетиков в разных местах. На всех них хочется поддерживать одну и ту же маршрутизацию. Для этого надо либо обернуть всё скриптом, кроном или ещё как чтобы утилита запускалась для каждого роутера отдельно, а в случае если хочется выполнить chain из нескольких команд - ещё и несколько раз для конкретного роутера. Со встроенным планировщиком эта проблема решается - он позволяет запускать задачи по интервалам, в заданное время, а так же делать chain из команд. Подробная инструкция на русском тут: https://github.com/Noksa/gokeenapi/blob/main/SCHEDULER_RU.md

Добрый день! В целом, выше уже ответили, но немного расширю. Удаление и добавление статичных DNS записей в gokeenapi это именно сами DNS записи. Я сомневаюсь, что это очень полезная фича для многих людей, но сделать её было нетрудно и поэтому она появилась. Основная её цель, это дать возможность добавления одной и той же записи вроде такой local.keenetic но чтобы она вела в разные IP адреса, в зависимости от того, к какой Wi-Fi Вы подключены. Простой пример: Есть 5 роутеров, которые раскиданы по разным квартирам, дачам. У всех у них разные подсети без пересечений (чтобы можно было установить VPN между роутерами и попадать в локальные сети друг друга). В то же время есть утилиты типа iplist которые позволяют автоматически резолвить нужные домены в IP адреса и так же автоматически подготавливать bat файлы для загрузки в роутер напрямую через ссылку. Так вот, если эта утилита (iplist) работает на локальном ноутбуке и вы перемещаетесь между квартирами-дачами-кинетиками, не хочется постоянно менять её конфигурацию (прописанный айпи роутера как днс сервер через который надо всё резолвить). Вместо этого хочется занести в конфигурацию утилиты просто dns запись которая всегда ведёт в роутер. В итоге, если вы подключены к Wi-Fi дома, то запись local.keenetic ведёт в 192.168.1.1. Если подключены на даче, то в 192.168.2.1 и так далее. В итоге всё работает одинаково без нужды править конфигурацию других утилит, которым нужен адрес роутера.

Добавлена GUI версия для Windows amd64: https://github.com/Noksa/gokeenapiui

Всем привет! Давненько написал утилиту для своих собственных нужд, которая работает по REST API с Keenetic роутерами. Т.е. с любым роутером из коробки, т.к. это всё сразу работает как только вы настроили WiFi сеть. Утилита умеет работать как с локальными роутерами (через внутренний IP адрес и http протокол), так и с роутерами в интернете через KeenDNS и https протокол. Репозиторий: https://github.com/Noksa/gokeenapi Основные вещи, которые умеет делать утилита: * Добавление маршрутов к конкретному интерфейсу через список локальных BAT-файлов * Добавление маршрутов к конкретному интерфейсу через список BAT-ссылок - т.е. утилита скачивает BAT-файлы по указанным ссылкам и после загружает их в Keenetic автоматически * Удаление маршрутов только у конкретного интерфейса (а не всех сразу) * Добавление AWG соединения, добавление ASC параметров из conf файла, подъем интерфейса и ожидание его готовности к работе * Добавление и удаление статичных DNS записей Всё это очень удобно особенно если у вас много кинетиков, а настроить их хочется одинаково и быстро по нажатию одной кнопки Учитывая, что это CLI утилита, можно настроить cronjob или какую угодно автоматизацию вокруг неё и например обновлять маршруты во всех своих кинетиках в разных уголках планеты в автоматическом режиме. Если кому-то тоже пригодится, буду рад

Достаточно добавлять нужные маршруты через интерфейс впн и никакие политики и галки выхода в интернет не нужны в таком случае. Куда лучше определять места для доступа через впн, нежели чем «куда без»