gaaronk

Конечно будут работать одновременно и 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 что пользоваться ими без понимания не надо.

Я вот IPv6 использую. Провайдером делегировна префикс, раздаю его внутри. Для раздачи адресов используется SLAAC, а stateless DHCP для выдачи дополнительных DHCP серверов, NTP сервера, domain-search и некоторых других опций. Со stateful DHCPv6 макось плохо дружит.

Ну вот пока такой костыль который не NATит в сторону gre (мой частный случай) тоннелей и NATит трафик из туннелей на выходе из public интерфейсов #!/bin/sh [ "$table" != "nat" ] && exit 0 /opt/sbin/iptables -t nat -A _NDM_IPSEC_POSTROUTING_NAT -o ngre+ -j ACCEPT /opt/sbin/iptables -t nat -A _NDM_STATIC_SNAT -i ngre+ -p udp -j _NDM_NAT_UDP /opt/sbin/iptables -t nat -A _NDM_STATIC_SNAT -i ngre+ -j MASQUERADE

И кроме того - выборочное включение, ибо трафик пришедший через туннель вполне имеет право уйти в Интернет и должен будет пронатиться. Или как вариант в CLI разрешить использовать обычную, а не инверсную логику NAT - делать на выходе из интерфейса Что то вроде ip nat out ISP

А в скриптах /opt/etc/ndm/netfilter.d/ при использовании "встроенного" iptables он выпадает в Segmentation fault Хотя просто из шелла работает. Надо обязательно ставить iptables из пакетов? Версия release: v2.08(AAUW.0)C1

Нет, ну есть костыль подпинывать ACCEPT через /opt/etc/ndm/netfilter.d Но это плохая идея. Правила "дергаются" очень часто, можно не успеть со своим скриптом и пара тройка транзитных пакетов улетит в NAT

И еще вопрос. Попробовал поднять просто IPSec туннель между Giga и удаленным офисом. Локалка на гиге 192.168.19.0/24, на удаленной точке пачка разных сетей вида 192.168.Х.0/24 Описываем концы туннеля как 192.168.19.0/24 - 192.168.0.0/16 IPSec поднимается и.... и все умирает. Как минимум правила вида Chain _NDM_IPSEC_INPUT_FILTER (1 references) pkts bytes target prot opt in out source destination 0 0 ACCEPT all -- * * 0.0.0.0/0 0.0.0.0/0 ndmmark match 0x88 0 0 DROP all -- * * 192.168.0.0/16 192.168.19.0/24 Убивают пакет от локальной сети к самому рутеру. И в таблице mangle есть в достатке таких нюансов.

А как настроить что бы при прохождении трафика из сегмента Home в GRE туннель к трафику не применялся NAT ?

И в догонку. Если делать lifetime большим, например сутки, то strongswan не закрывает уже не используемые CHILD_SA пока не истечет их таймаут. Поэтому 70 минут было выбрано "для красоты", что бы swan оперативно закрывал все лишнее.

А при чем тут аппаратное ускорение? Мы говорим про IKE, а не ESP. Аппаратное ускорение используется для шифрования трафика, а не для протокола обмена ключами.

А чем принципиально отличается задача PSK через crypto ike key и crypto ipsec profile \ preshared-key ? Для статических туннелей "crypto ike key" работает, а задача PSK через "crypto ipsec profile \ preshared-key" нет. Во втором случае в ipsec.secrets записывается что то вида "cmap:test-tunnel : PSK "<..>" Про такой вариант селектора в документации стронгсвана не написано...

Если мы говорим про IOS или MacOS с его кривым ракуном, то проблема в том что они не могут сделать reauth если его инициирует сервер, а reauth для IKEv1 обязателен. Только если они инициирует его сами. При этом lifitime жестко вшит, и составляет 3600 секунд. Для Apple надо настраивать strongswan так, что бы сервер сам никогда не инициировал reath и rekey. Примерно так (кусок конфига выстраданный долгой отладкой, ковырянием сорцов и перепиской с авторами стронгсвана): ikelifetime=70m lifetime=70m rekeyfuzz=0% margintime=5m При авторизации только по PSK или сертификату, без Xauth, то будет работать. Если дополнительно настроить XAuth по паролю, то работать все равно не будут. Продукты apple не хранят в памяти логин\пароль, и НЕ умеют заново запросить его у пользователя.