Le ecureuil

Три раза лол. С чего вы взяли, что они нас будут слушать?

Значит, к сожалению, это несовместимость реализаций

Подскажете хоть одного мобильного оператора, дающего IPv6?

Щито? Это вы вообще к чему?

Вообще ощущение такое, что это баг сервера, а после сброса вы перешли на другой из-за DNS round-robin. По крайней мере конфиги l2tp/ipsec абсолютно идентичны, да и Keenetic не инициирует разрыв соединения, он только уведомляет о нем.

В процессе реализации.

Нет, аппаратно. Должно считаться, иначе это скорее всего баг.

Ок, проверим. Возможно что-то сломалось из-за новой реализации подсистемы netfilter.

Эти файлы могут существовать и просто так, безотносительно системы инициализации Opkg. И тогда Web будет вводить всех в заблуждение.

Будет доступна везде, где есть 2.09. Машина уже в пути (ц)

Ок, проверим на предмет явных косяков, но без каких-либо гарантий. Скорее всего Extra II в роли сервера не вытягивает более 30 мбит/с. Для клиентов у нас есть ppe software, но он не работает в серверном режиме.

Если вы все время сидели на 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 Мужики, честно, постараемся. Помним об этой теме, но сейчас у нас есть более важные вещи к починке. А там как немного разгребем - дойдут руки и сюда.