gaaronk

Переход на версию 2.09.A.7.0-0 не помог. Apr 30 05:12:04 wmond WifiMaster1/AccessPoint0: (MT76x2) STA(78:31:c1:bf:e7:e2) had been aged-out and disassociated. Клиенты отваливаются на 5-10 секунд

Giga III, v2.08(AAUW.0)C2 На 5GHz had been aged-out and disassociated появляются тем чаще чем больше качаешь по воздуху. Один раз в 2-3 минуты. Self-test ниже.

Для AES еще используется ESP Pad, идущий после данных перед ESP Trailer. Например расклад для данных размером в 1400 в туннельном режиме AES, SHA-1 PACKET DETAILS Field Bytes New IPv4 Header (Tunnel Mode) 20 SPI (ESP Header) 4 Sequence (ESP Header) 4 ESP-AES (IV) 16 Original Data Packet 1400 ESP Pad (ESP-AES) 6 Pad length (ESP Trailer) 1 Next Header (ESP Trailer) 1 ESP-SHA-HMAC ICV (ESP Trailer) 12 Total IPSec Packet Size 1464 AES, SHA-256 PACKET DETAILS Field Bytes New IPv4 Header (Tunnel Mode) 20 SPI (ESP Header) 4 Sequence (ESP Header) 4 ESP-AES (IV) 16 Original Data Packet 1400 ESP Pad (ESP-AES) 6 Pad length (ESP Trailer) 1 Next Header (ESP Trailer) 1 ESP-SHA-256-HMAC ICV (ESP Trailer) 16 Total IPSec Packet Size 1468 AES, SHA-1, NAT-T, 1420 payload PACKET DETAILS Field Bytes New IPv4 Header (Tunnel Mode) 20 UDP Header (NAT-T) 8 SPI (ESP Header) 4 Sequence (ESP Header) 4 ESP-AES (IV) 16 Original Data Packet 1420 ESP Pad (ESP-AES) 2 Pad length (ESP Trailer) 1 Next Header (ESP Trailer) 1 ESP-SHA-HMAC ICV (ESP Trailer) 12 Total IPSec Packet Size 1488 Если есть CCO, то вот отличный калькулятор

Ну без обрывов при реаутентификации.

Мечта яблочников решается и на psk с использованием xauth-noauth для IKEv1 C сертификатами для клиентов есть нюансы. Стронгсван проверяет соответствие полученного от клиента ID клиентскому сертификату. Для MacOS и iOS - к сожалению использовать DN в качестве ID на клиенте нельзя, это баг клиента. Можно использовать как ID email или FQDN, соотвественно надо в сертификат надо добавлять соотвествующий SAN - fqdn или email Windows если использовать машинный сертификат использует авторизацию pubkey (в терминах стронгсвана) и корректно передает DN как ID. Но если использовать пользовательский сертификат, то используется eap-tls и тут винда как ID передает только значение поля CN, потому все то что записано в CN должно в сертификате дублироваться в SAN (fqdn или email) Ну и не забываем про EKU Client Authentication ( 1.3.6.1.5.5.7.3.2 ) IPSEC End System ( 1.3.6.1.5.5.7.3.5 ) IPSEC User ( 1.3.6.1.5.5.7.3.7 ) Если интересно кому могу отдельно рассказать так же весь ад с ciphers, lifiteme и прочими reauth По freeradius - если использовать только eap-tls или eap-mschapv2 то он не нужен. Но если мы хотим два разных соединения оба с MSCHAPv2 и в зависимости от eap_identity выдавать например разные сетки то начинается боль печаль с windows. Она не отдает eap_id пока ее явно не спросят. Соотвественно надо задавать eap_identity=%identity и прикручивать радиус. Двух соединений с просто с eap_identity=petrov и eap_identity=ivanov не получится. Но freeradius легковесен, для IPSec у меня используется в продакшене для EAP-TLS и EAP-MASCAHPv2 с минимальным конфигом. Хотя и тут не без костылей (хехе). Если пользователей мало то их можно хранить прямо в users файле, но любое его изменение приводит к тому что freeradius надо рестартовать. Если юзеров много нужен уже SQL или LDAP. Как то так.

Я думаю можно, если в CLI поправить ACL руками вписав вместо сети 192.168.1.0/24 что то вроде 192.168.0.0/22 И поставив галку NAT что бы не мудрить с вторым тоннелем (заворачивая в него пул динамики с первого рутера)

Впишите локальный адрес кинетика А можно показать вывод команды show ipsec (из телнета) в момент когда iphone подключен

Проверить наличие галки NAT в свойствах VPN сервера, и DNS тоже по идее надо бы указать Ну и проверяете вы не изнутри сети то хоть?

Даешь IKEv2 с авторизацией по сертификатам!

Ну если селектор будет 0.0.0.0/0.0.0.0 то по идее будет и интернет и "туннель" (думаю под этим вы имели ввиду доступ в локалку) Основной туннель не отвалится.

Ну если в настройках IPsec Virtual IP server выбрать не сеть конкретную, а Internet то как раз в инет айфон будет ходить через vpn (недолго правда, один час).

Конечно будут работать одновременно и IKEv1 и IKEv2

Можно скриптом /opt/etc/ndm/netfilter.d/02_nat.sh #!/bin/sh [ "$table" != "nat" ] && exit 0 /opt/sbin/iptables -t nat -A _NDM_IPSEC_POSTROUTING_NAT -o ngre+ -j ACCEPT /opt/bin/logger -t "iptables" "Add GRE rules to table $table" Только имя -o <интерфейс> задайте нужное вам

Ну меня слишком много, но все же psk_authenticator.c строка 73 if (key != NULL) { DBG1(DBG_IKE, "found linked key for crypto map '%s'", ike_sa_name); } else Разве не надо перед выводом дебага сделать что то вроде my_id = this->ike_sa->get_my_id(this->ike_sa); Что бы потом использовать my_id при вызове (строка 91) if (!keymat->get_psk_sig(keymat, FALSE, this->ike_sa_init, this->nonce, key->get_key(key), my_id, this->reserved, &auth_data)) А то получается что если мы нашли linked key то my_id не определяется. Если все это бред, то удалите топик пожалуйста.

Разобрался где косяк (?) Итак крипто профайл вида crypto ipsec profile remote.domain.com dpd-interval 20 identity-local fqdn local.domain.com match-identity-remote fqdn remote.domain.com authentication-local pre-share authentication-remote pre-share mode transport policy tun-ikev2-policy preshared-key ns3 <PSK> Мы иницируем установку туннеля. В момент IKE сессии передаем свое ID как local.domain.com но, начинаем вычислять на своей стороне MAC с использованием ID remote.domain.com Mar 22 23:03:10ipsec11[IKE] IKE_CERT_PRE task Mar 22 23:03:10ipsec11[IKE] IKE_AUTH task Mar 22 23:03:10ipsec11[IKE] found linked key for crypto map 'test-tunnel' Mar 22 23:03:10ipsec11[IKE] IDx' => 22 bytes @ 0x75ef5ba0 Mar 22 23:03:10ipsec11[IKE] 0: 02 00 00 00 XX XX XX XX XX XX XX XX XX XX XX XX ....remote.domain Mar 22 23:03:10ipsec11[IKE] 16: 2E 63 6F 6D .com Mar 22 23:03:10ipsec11[IKE] SK_p => 32 bytes @ 0x471ef8 Mar 22 23:03:10ipsec11[IKE] 0: A2 DA A4 C6 E6 65 84 DD A6 CC CF 2E 5F 3D 36 DF .....e......_=6. Mar 22 23:03:10ipsec11[IKE] 16: 89 D5 05 F3 94 A0 A9 20 36 C7 75 5F 98 F1 97 D9 ....... 6.u_.... Mar 22 23:03:10ipsec11[IKE] octets = message + nonce + prf(Sk_px, IDx') => 528 bytes @ 0x471418 Mar 22 23:03:10ipsec11[IKE] 0: BD ED 37 4A 8B D9 5A 22 00 00 00 00 00 00 00 00 ..7J..Z"........ Что приводит к Mar 22 23:03:12ipsec 15[IKE] received AUTHENTICATION_FAILED notify error Если мы из профайла уберем preshared-key и опишем его как crypto ike key test-key ns3 <PSK> fqdn remote.domain.com То все хорошо. Мы передаем свое ID как local.domain.com и начинаем вычислять на своей стороне MAC с использованием ID local.domain.com Mar 22 23:17:50ipsec03[IKE] IKE_AUTH task Mar 22 23:17:50ipsec03[IKE] linked key for crypto map 'test-tunnel' is not found, still searching Mar 22 23:17:50ipsec03[IKE] authentication of 'local.domain.com' (myself) with pre-shared key Mar 22 23:17:50ipsec03[IKE] IDx' => 21 bytes @ 0x76becba0 Mar 22 23:17:50ipsec03[IKE] 0: 02 00 00 00 XX XX XX XX XX XX XX XX XX XX XX XX ....local.domain Mar 22 23:17:50ipsec03[IKE] 16: 2E 63 6F 6D .com Mar 22 23:17:50ipsec03[IKE] SK_p => 32 bytes @ 0x8113c0 Mar 22 23:17:50ipsec03[IKE] 0: 96 2E 4D 0C 3F D8 D8 FA 95 D8 22 7C 6C 80 73 98 ..M.?....."|l.s. Mar 22 23:17:50ipsec03[IKE] 16: AD E5 2B 56 F4 46 B0 22 D3 EE 1E 88 A8 11 E1 79 ..+V.F.".......y Mar 22 23:17:50ipsec03[IKE] octets = message + nonce + prf(Sk_px, IDx') => 528 bytes @ 0x813140 В итоге Mar 22 23:17:57ipsec 06[IKE] authentication of 'remote.domain.com' with pre-shared key successful

Зарулить можно. Только надо на каждом spoke (луче) описать выделение трафика для засовывание в ipsec как <local network> - <сеть центельного узла> <local network> - <сеть spoke2> <local network> - <сеть spoke3> и тд. Что не очень удобно, но работает. Кинетик же из списка доступа читает только первую строчку. По этому обычно делают туннели и внутри них гоняют маршруты. Сделайте full-mesh - туннель между 4G и "второй ультрой" С выделением трафика 192.168.13.128/25 - 192.168.10.0/24

Просто в моей специфической ситуации все мои SIP пиры принимают только G729. Сейчас для телефонии стоит SPA3102, в нее воткнута DECT база. Хотелось бы SPA задействовать под другие задачи и убрать лишнее преобразование аналог-цифрв. Если самим модулем не поддерживается то проще наверное поднять астериск из entware, зарегистрировать модуль на нем и делать рекодинг астериском.

Скажите, а модуль DECT поддерживает кодек G729 ?

Не могу найти информацию. Модуль Keenetic Plus DECT поддерживает кодек g729 ?

Голым IPSec это получится, но не на кинетике, где для селектора трафика можно использовать только один элемент ACL. Можно на средней ультре делать двусторонний NAT, что бы клиент лез к адресам из диапазона 192.168.13.0/128, а его натило в src из сети192.168.13.0/128 dst 192.168.10.230 Ну и virce versa.

Поясню немного свою позицию. NAT не является средством контроля и безопасности. Использовать его для этого - опасно. Это всего лишь правила по которым меняются source и/или destination адреса/порты у пакетов в зависимости от кого/кому предназначен пакет, через какой интерфейс он входит/выходит. Контролировать доступ, кто куда может ходить, по каким портам и адресам - надо в filter. Если пакет предназначен адресу вашего рутера он обработается в цепочке INPUT, если он транзитный то в FORWARD. Вот там и контролируйте. По умолчанию в кинетике пакет нового соединения не будет маршрутизироваться если он пришел из public интерфейса, то есть ваш рутер при нескольких провайдерах не будет транзитным. Транзит разрешен от private - ко всем и и от protected к public

Нет конечно. Раз прилетает на IP рутера, то в FORWARD оно не попадет и НЕ будет маршрутизироваться. Рутер ответит скорее всего icmp unreachable.

Если такой пакет прилетит от ISP то его срежет фильтр.

В любом случае спасибо и за такую реализацию. Я прекрасно понимаю как важна обратная совместимость и стабильность взаимодействия с остальными компонентами. Я просто порассуждал на тему логики работы NAT. Возможно это будет интересно и вам (в будущем).

Отлично, спасибо! Вопрос ради интереса на логику. Если мы задействует этот механизм, то например если у у нас локалка, гостевая сеть, приватный туннель и выход через ISP в MAN и PPPoE в WAN, то нам надо написать такие правила ip static Home ISP ip static Home PPPoE ip static Guest ISP ip static Guest PPPoE ip static Gre0 ISP ip static Gre0 PPPoE По сути полную матрицу, если что то не опишем - в сторону провайдера уйдут не транслированные адреса, что некрасиво. Вариант "ip static out <WAN_INT>" подразумевает что то вроде -A POSTROUTING ! -s <WAN_IP>/32 -o <WAN_INTERFACE> -j MASQUERADE В этом случае на выход через этот интерфейс (на котором от нас ожидается только трафик от выданного нам IP) мы всегда идем с правильным source IP. Или такой механизм затратнее чем матчить по source интерфейсу? Ну а команды в CLI на то и даны только в CLI что пользоваться ими без понимания не надо.