Le ecureuil

Мало памяти, но вообще говоря история странная, зачем ему 4 мбайт в ядре выделять...

bootstrap это изначальное преобразование FQDN -> IP для установки соединения с адресами DoH. Использовать можно, если нет проблем. Если наблюдаются проблемы, то стоит отключить.

Куча непонятно чего, а по делу ноль. Логи при обрыве где? Еще неплохо ввести > interface L2TP0 debug и уже с этим следить за разрывами

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

2. dhcp отключается в настройках сегмента.

Насчет обрыва - нужны dump udp/500 и udp/4500 на WAN Keenetic и WAN M. Сравним и посмотрим что не так.

Конечно нет, NAT-T в обоих режимах поддерживаются (по крайней мере в Keenetic, в другом оборудовании вопрос не по адресу).

>> Keenetic устанавливает режим ikev2 Это вы сами включили, поменяйте настройки.

Ок, да, есть такое. Но теперь следим за руками. Во-первых, под нее нужно эксклюзивно тащить драйвер rt2860v2. Он начиная с 2.06 не использовался, то есть три года патчей глюков нужно затянуть в одно лицо и протестить. Во-вторых, свитч AR8316. Под него тоже нет драйвера для новых ядер, нужно написать руками с нуля (старые версии совсем не подходят под новую структуру). В-третьих, на этих устройствах никогда не будет KeenDNS и мобильного приложения, потому что они с завода выпускались не зная, что такие сервера существуют. Собственно, под них нет лицензий. В-четвертых, сейчас 64 Мб ОЗУ, проц на 384 МГц и WiFi 802.11 draft-n ну как бы сказать... немного мусорный. Да, скажем, 1211 не гигабитный, но по всем функциям и энергопотреблению он уделает в щи этот утюг, а 1211 это, между прочим, стартовая модель с USB (думаю, что извращенцев гонять dlna/torrent на таком утюге нет, новые версии не будут работать терпимо). Да и в 8 мб flash все лезет очень впритирку, спросите у обладателей Omni 2 на 2.16. В-пятых, полностью живых устройств осталось очень мало. Я лично перебрал десяток kn_ra и пяток kng_ra, которые выкидывали из стенда в мусор. Скажу так: совсем живых устройств я нашел только два. То есть один kn_ra и один kng_ra. При такой конверсии нафиг не нужно копаться в "этом". В-шестых, соотношение между живыми kng_ra и kng_rb примерно в районе 1:10. Намного интереснее в таком случае G2 поддерживать. Ну и нет в этой модели ничего интересного на мой взгляд. G2 - это 256 ОЗУ, нормальный проц, аппаратный IPsec (как минимум), она и сегодня выглядит не слишком архаичной (кроме WiFi). ZKG1 - это уже "ретро", как не крути, в ней архаично все. Примерно как в компе pentium 3 с windows xp - сейчас на нем нельзя ничего, даже в веб выходить нормально, только все выкинуть и купить новое. А G2 это примерно как Core 2 с W7 - еще пока можно жить.

Очень уж похоже на баг в ROS, если честно. Он умеет реаутентификацию? Потому что пока видно, что оно или выключено или не умеет принципиально. Могу посоветовать только костыль в виде установки в ROS lifetime (оба, ike и sa) на, скажем, неделю-другую, и в keenetic тоже. Тогда разрывы сократятся до раз в неделю, но принципиально они останутся.

План по legacy на самом деле довольно прост и прозаичен. Как только устройство остается без поддержки (причем даже в draft), то создается legacy. На данный момент было два таких перехода: это 2.11 -> 2.12 (когда за бортом осталось все на 63368) и 2.15 -> 3.0 (когда за боротом осталось все на 7620/6856). Тогда и были созданы legacy для них. Сейчас в новых legacy смысла нет, поскольку ki_ra/ki_rb/kng_re/ku_rd поддерживаются в draft и delta на самых последних версиях. Белые устройства, оставленные на 2.04 и 5350, оставленные на 2.05 подтянуть повыше до 2.11/2.16 не выйдет, поскольку там катастрофически нет места во flash и ОЗУ (все же 32 мбайт flash и 4 мбайт ОЗУ не хватит даже для минимальной системы) (хотя попытки были), тут сорян.

До встреч лет через 5-7 уже где-нибудь в legacy для 1011 )

В таком случае конечно нужно 1810 с 4x4, и не в каждый номер, а в коридоре, и разнести по каналам. Покрытие будет лучше, меньше помех, и устройств нужно будет не 10, а условно 3-4-5.

Я думаю лучше модем сменить, похоже что он устал. Сомневаюсь что на новом ПО и устройстве он будет работать сильно лучше.

Да, можно по идее tset не трогать.

Да, он. Поставьте в районе 20000, и ipsec transform-set в 20000.

Уменьшите на кинетике ike lifetime, чтобы именно кинетик запускал rekey.

Я описал выше: возникает неразрешимая ситуация с тем, как должен себя вести well-known: пробрасываться внутрь или терминироваться на роутере. Мы выбрали первый вариант, и если у вас acme-клиент находится на проксируемом сервере, то все будет ок. Второй будет многим неочевиден.

Раньше официального анонса вам врядли кто скажет.

Да, это очень неочевидно было. Вообще в ситуации когда нужен well-known адрес, как понять, терминировать его на роутере или пробрасывать дальше, на proxy? У меня нет однозначного решения, потому и посоветовали удалять перед получением. Кстати через 90 дней это нужно будет сделать снова.

Чем тупее проходной свитч, тем меньше проблем. С мыльницами их меньше всего

Начиная с верии 3.6 она не нужна, поскольку нет поддержки старого мобильного приложения. При смене порта 80 ничего держать не будет.

Как dev-вариант пойдет, дождемся пока станет рабочим и добавим Сами писать конечно же не будем, и так дел хватает.

Кто-то может показать живую (хоть через fuse) работающую реализацию? Была одна, только уже год без движения совсем. Как в такой среде что-то можно сделать?

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