Le ecureuil

Именно автодобавления согласно политикам не наблюдаю, и кода такого тоже не нашел. Но сочетание с bird это, конечно, отдельный пласт. Даже не знаю что посоветовать.

C'est la vie. Все больше народу приходит в поддержку по подобным вопросам, после изучения ситуации у которых можно только лишь констатировать "действия внешних сил". Просьба всем сперва проверять такую гипотезу перед обращением.

Вам проще watchdog просто в cron на раз в минуту поставить. Скрпиты в ndm неправильно делать длящимися, они через 240 секунд принудительно завершаются.

Нет, такое поведение поменять невозможно.

Проверил вашу схему, все работает нормально в целом, но есть много тонкостей. Всегда проверяйте настройки firewall на XFRM-интерфейсах, иначе трафик не будет идти вообще. Учитывая, что у вас приватный интерфейс и нет NAT, то везде нужны обратные роуты, даже на самом роутере с XFRM. Поскольку он видит обратные адреса из удаленных сетей без трансляции, то нужно добавлять руками роуты в эти сети через XFRM-интерфейсы на каждом шагу. Плюс на внешних устройствах навроде gpon-роутера тоже обязателен будет обратный маршрут в удаленную подсеть через Keenetic.

Сейчас проверил конфигурацию hub-and-spoke, и все работает хорошо. Для теста сделал hub с адресом 192.168.6.26 и локалкой 192.168.5.0/24, а также два spoke-клиента: 192.168.6.26 с подсетью 192.168.25.0/24 и 192.168.6.33 с подсетью 192.168.26.0/24. При этом транзит через hub работает отлично, сеть 25.0/24 отвечает на 6.33, а сеть 26.0/24 отвечает на 6.27. Настройка на клиентах-инициаторах: Настройки на hub для каждого из пиров:

Так он с самого начала открытый: https://github.com/keenetic/sstp-client/commit/6119c6ef283b77450c93a8b89209ab42c944b88a

У вас там десяток WG, какой именно? И нужен аналогичный лог, но с заранее включенным interface debug.

А зачем вы вообще в mtu лезете?

Сборка прошла удачно, версия 4.3.6.2 успешно выложилась в draft. Почему вы ее не видите - понятия не имею.

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

Очень странные у вас ошибки, они устойчиво воспроизводятся при каждом рестарте?

"...со злом, допустим, надо бороться!"

Значит последующий трафик не распознается как TG.

Не занимайтесь ерундой, в cli сделайте > components list draft > components commit

Добрый день, да, уже несколько лет как можно. Начиная с версии 4.1 поддерживаются несколько подсетей во вторых фазах в IKEv2, потому вы можете в краевых узлах указать по 2 подсети - центрального узла и хаба.

Поставил ki_ra/ki_rb 4.3.6.2 в draft.

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

Успех в этом направлении - купить нормальный модем.

У вас вообще не работает этот proxy? В логах я не вижу проблем с нашим клиентом. Он отлично авторизуется на сервере и посылает ему команду connect (к удаленному узлу, на который мы хотим пойти через proxy), на которую не приходит ответ вообще и соединение затем рвется по таймауту. Есть подозрение, что вмешиваются посторонние силы и блокируют сессию. Попробуйте проверить на более старой версии ПО, и, очень желательно, снять аналогичный дамп трафика.

Спасибо, но это не то. Нужен дамп на ПОДЛЕЖАЩЕМ интерфейсе, в вашем случае это ISP - тот, через который вы к провайдеру соединяетесь.

Для устаревших моделей такой разницы нет, из одной бочки все наливается.

Покажите дамп трафика на подлежащем соединении, посмотрим.

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

У вас слишком сильно заполняется conntrack, срабатывает защита от переполнения. Если вы в этом не подозреваете действий злоумышленников, то поднимите порог повыше, с 80 до 98%: > ip conntrack lockout threshold public 98 Или как альтернативу, можете поднять число conntrack-записей до 24 тысяч скажем.