Le ecureuil

Если вы все время сидели на 2.07, то у вас только одна проблема: ваш диск фрагментировался до такой степени, что просто не может больше работать со сколько-либо приличной скоростью. Подключите его к ПК и дефрагментируйте, или же удалите на нем вообще все файлы.

Достаточно отключить.

MAC-адреса точно не будет, а так можете в cli на сервере набрать: > show crypto map

Вот именно. Сейчас конфиги практически полностью совместимы при любых перешивах в пределах от 2.06 до 2.09 и выше. А вот при возврате на 2.05, 2.04 и ниже ваш конфиг будет сброшен на "дефолтный". Однако прямая совместимость все равно есть - конфиг от 2.04, 2.05 и даже 2.03 и раньше нормально подхватится в 2.06 и выше.

Можно, в web-интерфейсе размонтируете диск, и все. Для особых перестраховщиков можно еще и галочку снять "Включить OPKG" до размонтирования.

Есть поддержка расписаний в access-list в 2.09, но это довольно муторно, учитывая сколько IP-адресов у youtube, и как часто они меняются.

Ждите 2.08 stable, там должно быть поправлено. Или проверьте прямо сейчас на 2.09.

Сейчас SSL нужен для KeenDNS (входит в базовую поставку) и для HTTP-сервера (тоже входит в базовую поставку). Потому его исключили как отдельный компонент.

А не хотите попробовать 2.09 с Entware-3x? Там куда больше шансов на удачную работу. Все же 2.6.22 - это ядро десятилетней давности...

Эти поля останутся по-любому, потому что запись в conntrack создается все равно.

Наши мобильные приложения вообще никак не связаны с Web, кроме использования общедоступного NDM XML API (впрочем его можно использовать где угодно и через утилиту ndmq в Entware например).

Играют. Если суммарный трафик превышает некоторый предел, то автовыбор будет отложен.

Это из-за сочетания сразу двух особенностей. Во-первых, используется небольшой fuzz для определения времени rekey. То есть если задано например 86400 секунд, то настоящий rekey начнется за 86400 - 8640 + 4320 * (rand() % 1) секунд. Это специально сделано, чтобы не было ситуации, когда IKE/CHILD SA удаляются по истечении времени жизни и только потом начинается rekey, что ведет к пропаданию трафика на время + чтобы избежать перегрузки канала и процессора, если настроено сразу несколько туннелей с одинаковым интервалом rekey. Потому в вашем случае rekey может быть инциирован любой из сторон, возможно двумя сторонами сразу, возможно с небольшим лагом друг от друга. Это может выглядеть как излишний rekey. Но в итоге это все равно отработает правильно. Во-вторых, SA в ядре полудуплексные, но из-за особенностей настройки ядра в случае транспортного режима необходимо пересогласовывать каждую SA индивидуально, а для туннельного режима можно обойтись одним разом.

@Leksey118 @Sergey Zozulya Мужики, честно, постараемся. Помним об этой теме, но сейчас у нас есть более важные вещи к починке. А там как немного разгребем - дойдут руки и сюда.

Всем спасибо, работаем.

У вас все нормально, судя по тесту. Удалите нафиг маршруты, они не нужны на Keenetic. Посоветую разве что проверить как там себя ведет удаленная сторона, нет ли в фаерволе чего заблокированного. Плюс в IPsec туннеле не работает NAT, а стандартный firewall винды блокирует доступ, если IP источника не лежит в ее локальной подсети. Проверьте это.

Спасибо за очень интересные селф-тесты, нашлась еще одна неочевидная вещь Поработаем над ней.

Ну емое, ну сверху в объявлениях же https://forum.keenetic.net/announcement/4-как-правильно-добавить-self-test-и-прочую-отладку-в-тему/

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

MITM или явный proxy

Ну там виндовые шары, http. UDP тоже пойдет. А вообще маршруты не нужно прописывать (по крайней мере на стороне Keenetic). Пришлите self-test в момент, когда соединения установлены.

Над этим работаем. Стандартными средствами пока никак. ping нет, а другие протоколы работают?

Где тут Keenetic?

Youtube работает через quic (UDP) и TLS. Такой трафик невозможно фильтровать без MITM.

Все в ваших руках: https://github.com/ndmsystems/packages/wiki/Opkg-Component#ndmfsd