Le ecureuil

Нифига себе, а чем эта жрущая жесть лучше 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 мы делаем. Если все понятно из конфига, то не делаем.

В object group fqdn можно добавить ip-адреса.

Как появится реализация в kernel module, тогда и поговорим.

Потому что ключ аргумента должен быть не domain, а revoke: curl -s "localhost:79/rci/ip/http/ssl/acme/revoke" --request POST --header "Content-Type: application/json" --data-ascii "{\"revoke\": \"my.domain.com\"}" Лайфхак - смотрите на подсказку в cli: (config)> ip http ssl acme revoke Usage template: revoke {revoke} То, что в фигурных скобках - таков должен быть ключ аргумента в json.

Для object group ip нет show, так как в этом нет никакого смысла. Состояние полностью соответствует тому, что настроено в конфиге.

Спасибо за репорт, в следующем выпуске 4.03 и 5.0 будет поправлено.

Есть какая-то проблема с ipset похоже, добавлю побольше отладочной информации чтобы было понятнее.

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

Конечно будем исправлять если вы будете прикладывать log с включенным interface debug и описывать в каких именно строках как вам кажется был реконнект, но не было обновления.

Этого вам и хватит. Обычная команда для среднего юзера будет выглядеть как (при условии, что object-group у вас называет GROUP, а ваш интерфейс это Wireguard0): > dns-proxy route object-group GROUP Wireguard0 auto Если вы хотите, чтобы при отключении Wireguard0 трафик, который должен йдти в Wireguard0 вообще дропался, вместо того, чтобы по другим рабочим маршрутам идти, то добавьте в конце reject: > dns-proxy route object-group GROUP Wireguard0 auto reject Вот примерно так советую всем и использовать.

Покажите полный self-test.

Если коротко, то это нормально. Два gateway на самом деле означают gateway IPv4 и gateway IPv6. В cli можно было бы сделать так, чтобы была красивая подсказка, но тогда в RCI это будут два разных поля, что не хотелось бы. В других случаях тоже есть сходные мотивы.