Le ecureuil

Можно, в 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

https://github.com/relan/exfat + Entware + fuse = PROFIT

Фича. Ваш "рандомный" IP пересекается с адресами из Интернет, что плохо. Теперь туда допускается вводить только адреса приватных сетей из RFC 1918: 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16.

SSL будет переделан и расширен, тогда и реализуем все это.

Как именно это должно касаться роутера?