Le ecureuil

Этого вам и хватит. Обычная команда для среднего юзера будет выглядеть как (при условии, что 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 это будут два разных поля, что не хотелось бы. В других случаях тоже есть сходные мотивы.

Покажите self-test ы в обоих случаях

self-test выполняется только по-запросу этого файла, и потому "стоит" ровно ноль, пока вы его не скачиваете. syslog записывается только в ОЗУ, и пока вы не скачиваете его в виде файла или не смотрите в вебе, он тоже очень дешев.

Network manager не советую использовать, премерзейшее багованное изделие. Только sstpc в cli.

Сейчас DTLS отключается при использовании облачного режима. Попрбуйте пока в нем проверить. Если все нормализуется, то сделаем команду в cli для сервера.

Все хорошо, только при чем тут Keenetic?

Подсказку подправил, спасибо за репорт.

В следующей версии 5.0 будет поправлено.

Появится в следующей сборке 5.0.

В версии 5.0 появится маршрутизация по доменам, на всех моделях.

Вы так и не ответили, куда именно вы его вставляете и как на него направляется трафик. По self-test ничего кроме пары неработающих DoH-апстримов не видно.

Только на IP-адреса пытаетесь зайти, или по доменным именам?

А где именно вы видите эти записи по резолву servfail.invalid? Еще нужен лог после включения dns-proxy debug в моменты, когда появляются эти записи. По коду мне непонятно, как они могут просачиваться куда-то "выше".

Сейчас я вижу, что у вас уже просто проблемы с тонкой настройкой. Во-первых, у вашего текущего endpoint https://api.dynu.com/ нет записей AAAA (об этом говорит лог), а значит обновление всегда будет идти через IPv4. А таком случае полагаться на автоматическую интерполяцию данных нельзя. Вам нужно создать кастомный URL, в который будут интерполированы только нужные вам значения (а именно ${ip} для адреса IPv4 и ${ip6} для IPv6), и не будет ненужных, согласно dynu.com API reference: https://www.dynu.com/DynamicDNS/IP-Update-Protocol Для варианта в IPv6-only он будет выглядеть так: dyndns profile _WEBADMIN type custom username testuser password testpass no send-address url https://api.dynu.com/nic/update?myipv6=${ip6} Очень важно не задавать домен, и не включать send-address, поскольку у api.dynu.com все равно нет IPv6 AAAA-записей. Если вам нужен IPv4 + IPv6, то конфиг будет выглядеть так: dyndns profile _WEBADMIN type custom username testuser password testpass no send-address url https://api.dynu.com/nic/update?myipv6=${ip6}&myip=${ip} В таком случае все будет работать правильно. Я постараюсь в 5.0 добавить правильный пресет для dynu.com.

Как всегда нужен лог с включенным interface debug, без него бесполезно.

Это нормально, мы таким образом делаем hearteat-check для наших DoT/DoH-фронтендов и для recursive resolver. Однако странно что оно вылезает дальше, не покажете свой конфиг?

Нет, не будет.

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

Политика такова, что в stable не вносятся неважные исправления. Данная ошибка по сути не является ошибкой, скорее назойливой строчкой в логе, которая никому не мешает если в него не смотреть. В stable вносятся исправления по массовым проблемам, когда у тысяч пользователей что-то перестает работать или находится уязвимость. Все остальное на этапе stable признается неважным. Ради вашей никому не создающей проблем строчки в логе никто не будет менять кирпичи в фундаменте, потому что могут пойти трещины у тысяч в неожиданном месте. Именно потому критически важно чтобы вы все проверили на этапе draft или preview - потом уже может быть поздно.

Сделал чтобы любое значение кроме из интервала 3...3600 трактовалось как 15. Будет только в версии 5.0, в 4.3 останется как есть.

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

Из коробки никто не обещал - ни в одном месте. Не знаю, почему вы решили, что могут добавить.

Все неважные фиксы, а также те, которые требуют сильной переработки внутри попадают только в draft, и никогда в stable. Потом, со временем, они дойдут до stable естественной эволюцией.