Le ecureuil

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

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

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

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

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

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

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

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

Как только поясните зачем вообще может быть нужен конфиг в текстовом виде, в котором явно стоит keepalive = 0.

В этом случае (если во внешнем конфиге было == 0) удаляется совсем. Это аналог комнады no keepalive. Если же в конфиге роутера было какое-то значение, хоть и 0, то при импорте конфига с пустым все равно будет перезаписано в 15 независимо ни от чего.

Да, это исправлено в последних версиях 5.0, до этого всегда лезло в DNS-серверы.

1. Посмотрю. 2. Есть вероятность, что не успевает наполнится ipset, и тут мало что можно будет сделать, кроме как "предпрогрев" (который, кстати, все дружно высказали как бестолковый, только зря молотящий).

То, что это неприоритетный баг, который в основном только в логе пишет, а на работу не влияет.

Self-test где?

Это нормально, можете не обращать внимания.

А вы уверены, что MacOS понимает маршруты, которые приходят от сервера по DHCP INFORM?

Всем спасибо за репорты и терпение, проблема с неотдачей маршрутов в серверах IKEv1 и IKEv2 поправлена, исправление появится в следующих выпусках.

1. Это единственное узаконенное исключение, еще есть Dslite и MAP-T в этом списке. 2. Нет, а если все же расщепляется - давайте поправим. 3. Никак, такие хотелки не реализованы.

А на аналогичный интерфейс, который не основной, в ipv4-режиме curl не ругается?

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

Для ndmc они тоже вам понадобятся, не бывает чудес.

4.3 - только значимые и важные фиксы. А без этого можно месяц прожить.

В таком виде это бесполезная настройка, лучше даже и не задавать. Скорость обязательно должна быть или равна тарифной, или процентов на 5-7 ниже (это еще лучше), только тогда работает правильно. Если ставить скорость больше тарифной или вообще на интерфейс, то лучше вообще не ставьте - кроме бесполезной нагрузки на CPU вы ничего не получите.

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

Не должен. Сейчас существует консенсус, что основное v4 и v6 соединение должно быть одно и то же, расщепление не допускается. То есть default route в обоих протоколах должен вести в один и тот же интерфейс. WG работает только потому, что это L3-only интерфейс, и в него можно пихать пакеты не зная адреса gateway. С L2-интерфейсами так не прокатит, обязательно нужен gateway.