KorDen

IPIP over IPsec. ну или GRE/EoIP/L2TP over Ipsec, без разницы, у IPIP оверхед меньше

Для strong всё так и осталось, 1536 для SA впереди: ~ # cat /tmp/ipsec/ipsec.conf ... conn IPIP0 ... ike = aes256-sha1-modp2048,aes256-sha1-ecp384,aes256-sha1-modp1536,aes128-sha1-modp2048,aes128-sha1-ecp256,aes128-sha1-modp1536! ... esp = aes256-sha1-modp1536,aes256-sha1-modp2048,aes128-sha1-modp2048,aes128-sha1-modp1536! (в CLI Guide аналогично)

Наткнулся в логах на "peer didn't accept DH group MODP_1536, it requested MODP_2048" и последующий полный рестарт при пересогласовании (с той стороны прописано только ....-modp2048). Есть какой-то тайный смысл в том. что в SA первым идет modp1536?

Проверка идет в момент загрузки (первоначального опроса шины)? Если отвалится находу (после нормальной инициализации и работы) - теоретически улетит как обычно в ребут, или заблочит и продолжит работу без него?

О, а это в 3.x появилось? При full-cone как соотносится с фаерволом?

Есть же dehydrated, в котором только в одном месте надо поменять "#!/usr/bin/env bash" на "#!/opt/bin/bash" Достаточно открыть в фаерволе Что мешает перманентно перенести сервер кинетика на другой порт?

Ничего не устареет, два сертификата для одного домена - нормальная практика

Если каких-то особых требований нет, попробуйте чистый IPsec-туннель (AES128/SHA, AES128/MD5) или IPIP over IPsec, если нужна маршрутизация. Там оверхед поменьше, чем в L2TP/IPsec, и максимальная скорость скорость чуть больше (30-35), хотя конечно зависит от характера нагрузки. На 1010/1910/1810 в туннеле IPIPoverIPsec практическая скорость порядка 150-200 мбит/с (на гигабитном линке), при этом интерфейс не отваливается, проц не упирается в 100%.

Есть Giga II, у которой WiFi работает, но она изредка самопроизвольно ребутается. Либо не ребутается, но WiFi в какой-то момент и до ребута начинает работает очень паршиво (сеть видна, но не подключается и т.п.). Подозреваю, это "ранние симптомы"? (наблюдается уже с полгода) Или такого не наблюдалось? Если прошить той прошивкой - WiFi вырубится совсем?

Вопрос именно в том - можно ли без последствий заниматься разработкой кода того же exFAT (если MS внесет патенты в пул OIN), самому не вступая в OIN. Иначе говоря - если патенты будут в пуле OIN, потребуется ли от Keenetic членство в OIN (пускай и формальное) для соблюдения всех формальностей при включении поддержки exFAT, или можно не вступать? // еще вспоминается ситуация с AV1 - AOM vs Sisvel, где AOM это аналог OIN, но это уже совсем другая история

Вопрос по OIN - подразумевается ли, что если патент в пуле OIN, то код, подпадающий под этот патент, может использоваться для коммерческой разработки любой компанией в мире, или только компаниями, состоящими в OIN? Ну или еще какой-нибудь RedHat-way там, или другие подобные ограничения по использованию/бэкпортированию в свою ветку ядра? (это я про используемое там везде "Linux System" и The definition of the Linux System relevant to the OIN license agreement is described on this page and associated tables.)

По мотивам данной темы, из чата: аналогичная проблема с туннелями 6in4, тоже желательно хотя бы IPDEFTTL вместо inherit

Но это есть и в конфиге для IPIP-туннелей. Поясню тогда вопрос подробнее. Кинетик - клиент, сервер - свой strongSwan 5.7.2, где настройки IPsec практически аналогичны тем что на кинетике в режиме сервера. Наблюдаю иногда двойное пересогласование, как я понимаю из-за того, что таймеры reauth/rekey выставляются в случайные значения (8 часов плюс-минус несколько минут). Со стороны сервера выглядит как Aug 25 15:39:48 db-a2 charon: 14[KNL] creating rekey job for CHILD_SA ESP/... *пересогласование ESP* Aug 25 15:39:49 db-a2 charon: 10[IKE] CHILD_SA closed через пару минут полная переустановка: Aug 25 15:42:08 db-a2 charon: 11[IKE] received DELETE for IKE_SA *полная переустановка IKE/ESP* Со стороны кинетика I [Aug 25 18:39:48] ipsec: 05[CFG] received proposals: ESP:... *пересогласование ESP* I [Aug 25 18:39:48] ndm: kernel: EIP93: release SPI.... .... I [Aug 25 18:42:07] ipsec: 06[IKE] reauthenticating IKE_SA IPIP0[7] *полное пересогласование* ... I [Aug 25 18:42:08] ipsec: 04[IKE] scheduling reauthentication in 28780s ... I [Aug 25 18:42:08] ipsec: 04[IKE] received AUTH_LIFETIME of 28037s, scheduling reauthentication in 28017s На туннеле кинетик-кинетик вот этого вот лишнего пересогласования ESP перед полным пересогласованием не наблюдаю. Подозреваю, дело собственно в таймерах - когда таймер пересогласования ESP меньше таймера пересогласования IKE - так и происходит (таймер со стороны сервера), а в кинетиковской реализации оно подавлено. Просто хочу для себя понять, в правильную ли я сторону копаю. Хочу максимально уменьшить лишние телодвижения по пересогласованию, потому что это лишние потери пакетов как обычно в самый неподходящий момент.

@Le ecureuil > no_reauth_passive = yes Я правильно понимаю, судя по коммиту, что это позволяет избежать "двойного" пересогласования ipsec для туннеля (вначале пересогласовывается по инициативе сервера, затем через минуту клиент полностью переустанавливает), но этот код должен быть именно на "сервере" (passive)?

KN Start = KN Lite = KN City = KN Air = Z Air = Z Start II = Z Lite III r.B по CPU-RAM-Flash. Ну и KN 4G и Z 4G III r.B туда же. Туннелей всего PPPoE до провайдера + IPIP over IPsec, без FTP ALG по FTP не пошаришься

Что из этого списка вам кажется лишним? Ну вот берем Air. Инет по PPPoE, нужен IPsec-туннель, есть IPTV. На роутер по telnet ходить небезопасно, IPsec зависит от L2TP. Лишние тут PPTP, с натяжкой UPnP и Cloud (и это еще не V2). А вообще по PPPoE еще IPv6 прилетает, а заюзать его не получается... Зато у нас ACME и это всё уже нифига не модульное и вшито в базовый набор ЕМНИП, хотя HTTPS бы нафиг оттуда убрать, потому что бестолковый. P.S.: у меня Air из-за нехватки места так и не автообновился 2.14->2.15.. 3.xx не пробовал, но чую опять придется урезать.

Ну вот на 2.15 впритык влезает: Базовые: WiFi, ускоритель, DHCP-сервер, IGMP Proxy, UPnP, SSH Сетевые: PPPoE, PPTP, L2TP, IPsec, FTP ALG, PPTP ALG, туннели Сервисы: Cloud, PingCheck, tcpdump Лишний тут пожалуй только PPTP-клиент. IPv6, SNMP или банальный L2TP/IPsec-сервер уже не влезет.

Bump... Впрочем, продолжу чертыхаться каждый раз при дебаге...

Multipath уже имеется, но он для WAN, вам же нужна агрегация портов. Учитывая схему портов в нынешних кинетиках - разве что в Ultra II можно получить какой-либо профит, проще поставить рядом свич

По-умолчанию ip nat Home - натить все исходящие пакеты. Т.е. при выходе с R2 ставится IP 192.168.201.2 - а до транзитных сетей на R2/R3 у вас прописаны маршруты? (R3: ip route 192.168.201.2 192.168.201.1)

И при этом DoH/DoT так же является "интернет-фильтром"... // + 1 гвоздь

Оно на самом деле очень скачет, если подампить вывод несколько раз в течение продолжительного времени. Пиковые цифры как я понимаю выскакивают когда keepalive закончился и он пересогласовывает TLS - если активности в сети не много, оно кмк часто будет дохнуть. У меня например такая картина получается tls upstream 8.8.8.8 sni dns.google tls upstream 1.1.1.1 sni cloudflare-dns.com tls upstream 9.9.9.9 sni dns.quad9.net Ip Port R.Sent A.Rcvd NX.Rcvd Med.Resp Avg.Resp Rank 127.0.0.1 40500 184 168 11 24ms 32ms 10 127.0.0.1 40501 317 226 10 314ms 1102ms 4 127.0.0.1 40502 19 3 7 207ms 1296ms 5 ---чуть позже--- Ip Port R.Sent A.Rcvd NX.Rcvd Med.Resp Avg.Resp Rank 127.0.0.1 40500 285 255 11 24ms 23ms 10 127.0.0.1 40501 336 236 10 52ms 250ms 8 127.0.0.1 40502 33 3 7 207ms 1296ms 3

IMHO претензия тут в любимой EULA фразе "включая, но не ограничиваясь", современные приложения уже приучили понимать её как "мы скопируем себе всё, до чего сможем дотянуться". Что ни установи - лезет всюду. Поэтому новому пользователю, не знакомому плотно с кинетиками, кажется, что тут тоже всё всюду лезет. Этому мнению (для устройства "из коробки") вполне способствуют автополучаемый сертификат на *.keenetic.io, автообновление, подтягивание статей поддержки при наведении на вопросик и т.п. Нынешней статье в поддержке не хватает конкретики в первых двух пунктах. В идеале бы иметь отдельный раздел или статью с техническим описанием, что будет отправляться при минимальной конфигурации. Или еще лучше - иметь возможность "предпросмотра" отправляемых данных. Скажем, что-то типа: - проверка подлинности и базовая статистика - минимально (если не использовать KeenDNS/etc) это передача серийник+IP+минимальная статистика, можно посмотреть отправляемые данные командой show support-info short (вывод по аналогии show self-test) - информация об ошибках - можно посмотреть пример отчета через show support-info diag. Так же туда может быть включен дамп ядра, которого у вас в выводе может и не быть, если еще ничего не крашилось, пример: ...

Хотелось бы поднять эту тему. А так же заметить, что через ip host нули сейчас добавить невозможно (config)> ip host www.google-analytics.com 0.0.0.0 Dns::Manager error[22544392]: address: invalid IP address: 0.0.0.0. (config)> ip host www.google-analytics.com 127.0.0.1 Dns::Manager error[22544392]: address: invalid IP address: 127.0.0.1.

SPKI - это замена авторизации через CA по домену, "не заполнять, если не знаете, для чего нужно". У DNS Message оверхед меньше