Le ecureuil

Спасибо за репорт, будет исправлено в следующей версии.

Можно, но учитывая количество ботов и мусорного трафика в интернете не очень понятна репрезентативность этого всего.

Можете все сами сделать через скрипт который по rci все сделает.

Будет исправлено в следущей сборке - пользователю admin поставить этот тег будет нельзя.

В Keenetic нет RTC, а также прецизионных таймеров, потому мы не можем гарантировать высокую точность, о чем честно в stratum и в поле precision предупреждаем. Более того, сам Keenetic получает время с удаленных серверов тоже по упрощенному протоколу SNTP раз в неделю, и не делает постоянный контроль с подстройкой - во имя сокращения трафика и нагрузки на пулы NTP. Сейчас системные часы на всех устройствах подогнаны так, чтобы в среднем за неделю не накапливалось более десятка секунд разницы, что составляет по точности примерно 10^-4. Однако от экземпляра к экземпляру, а также в зависимости от модели, температуры и прочих условий может быть и чуть больше. Этот SNTP сервер (упрощенный) нужен чтобы устройствам в локалке навроде видеокамер или свитчей не было необходимости лезть в интернет за временем и им можно было бы совсем заблокировать доступ в интернет. Если вам нужна высокая точность, то вам однозначно лучше использовать настоящий NTP.

Случайно нет в сети WiFi-экстендера или репитера? А вообще self-test бы куда лучше все показал, но автор морозится.

Подавляющую часть приложений добавляет поставщик как есть, но есть приложения которые добавляем сами. Это как раз тот список, который добавлен нами.

Основная проблема, что приложений 2500, протоколов больше сотни. Как должен выглядеть интерфейс с подобными списками - непонятно.

Этот тег никому трогать не надо, он служебный в основном. Перевод подправим.

Пока выглядит как ненужная фишка для полутора калек. Я не могу себе представить именно такой сценарий с простукиванием для массового юзера разумным. Намного проще поставить мобильное приложение и через него безопасно включать/выключать приложения.

Сделать еще один изолированный сегмент с security-level protected, и привязать сервер к нему.

Нифига себе, а чем эта жрущая жесть лучше nextcloud?

Webdav работает на запись даже из проводника Windows, куда уж еще проще?

Нужны self-test с экстендеров.

Нужны self-test с экстендеров.

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

1. По внутреннему устройству из соображений безопасности не положено. Поскольку пиры создаются чуть ли не быстрее, чем редактируются, то предполагается что в случае смены настроек проще создать новый чем ковыряться с хранением приватных ключей. 2. См пункт 1 - непонятно, зачем это нужно. 6. Индивидуальный нат для каждого клиента? Так у нас в других VPN-серверах такого нет, а была мысль именно что "максимально выровнять пользовательский опыт". То, что слетает - репортуйте как баг, так быть не должно. 7. Уже можно, указывайте через запятую: "1.2.3.4/32,1.2.3.5/32".

На сервере нужно сделать (при условии что у интерфейса название OpenVPN0): interface OpenVPN0 security-level private ip nat OpenVPN0 И затем на клиенте пускайте все через него.

Если резолв идет не через dns-proxy на кинетике, или хост в политике, то работать не будет.

Дока все пишет верно, но только для cli. Для rci все посложнее, и некоторые детали неочевидны.

show нужен если сущестувет какая-то допинформация, неочевидная из конфига. В случае с object group ip такой нет, object group fqdn - есть. В случае с nat зависит от команды, если просто ip nat Home - то нету нее, а если нужен conntrack - есть show ip conntrack.

show running-config или в RCI через GET /rci/

Покажите self-test с включенным interface debug.

Даже на 7628 вы разницы не заметите. Это для BRAS, обслуживающих 10 MPPS важно, а дома оба варианта ок.

show всегда показывает только runtime-информацию, а не конфиг, они не взаимозаменыемы. Если она есть, то show мы делаем. Если все понятно из конфига, то не делаем.