gaaronk

А дома у меня рутер это стоковый дебиан в виртуалке на сервере виртуальных машин. Там бэкпортированный мной сван 5.5.2, там уже все - и сертификаты, и туннели, и remote access и L2TP и Cisco IKEv1 и IKEv2, и так и сяк и с радиусом сбоку для EAP.

Я пользуюсь прошивочным лебедем на кинетике и на асусе с падаваном (собирал сам). Можно и из entware поставить, но он живет на флешке, а рутера от меня в 1200 км и 800 км. Если флешка умрет, то худо бедно, пусть с задержкой но туннели поднимутся. Можно будет попросить воткнуть другую флешку и все настроить заново.

Плохой, негодный костыль. К тому же валится в сегфолт, видимо из-за использования /usr/lib/ipsec/stroke Нужен мегакостыль! В /opt/etc/init.d лежит у меня S01system отрабатывающий при старте системы оттуда запускаем # Strongswan fixup /opt/usr/sbin/swan-fix.sh & и сам swan-fix.sh #!/bin/sh while true; do sleep 3 SPID=`pidof charon` if [ ! -z "$SPID" ]; then sed -i 's/cisco_unity = no/cisco_unity = no\n\tinterfaces_ignore = "ngre1, ezcfg0"/g' /tmp/ipsec/strongswan.conf kill $SPID /opt/bin/logger -t "swan-fix" "Fix strongswan routing" exit 0 fi done Так и живем

Пока подпер костылем /opt/etc/ndm/wan.d/01_swan.sh #!/bin/sh [ -z "$interface" ] && exit 0 /usr/lib/ipsec/stroke statusall | grep -q "78\.47\.125\.180\/32" if [ $? -eq 0 ]; then ip route del default table 200 /usr/lib/ipsec/stroke route test-tunnel /opt/bin/logger -t "swan-fix" "Re-route VPN connections" fi exit 0 Маршрут в таблице 200 потом сам появится, через динамику.

Так. Бага интересная. Есть отдельная таблица маршрутизации (номер 200) где прописан дефолт в сторону ngre2 интерфейса. В основной таблице дефолт в сторону ppp0 интерфейса. В ip rule правил для этой таблицы нет. Strongswan все равно использует ее для вычисления source address для route trap. Если ее очистить то все становится хорошо. При этом на "большом" линуксе есть и аналогичная таблица с отдельным дефолтом, есть и правила ссылающиеся на нее, но Strongswan так странно себя не ведет.

Прошивка 2.09.A.7.0-2 Настроены туннели GRE. Для них руками поднят IPSec примерно так. access-list acl-test-gre permit gre 1.1.1.1 255.255.255.255 2.2.2.2 255.255.255.255 crypto map test-tunnel set-peer 2.2.2.2 set-profile remote.test.com set-transform esp-aes128-sha1 match-address acl-test-gre nail-up virtual-ip no enable enable где 1.1.1.1 локальный адрес на PPPoE соединении (он статический всегда выдается один и тот же) Пр этом у стронгсвана создается конфиг conn test-tunnel keyingtries = 1 margintime = 20s rekeyfuzz = 100% lifebytes = 21474836480 closeaction = none leftupdown = /tmp/ipsec/charon.left.updown rightupdown = /tmp/ipsec/charon.right.updown ike = aes256-sha256-modp2048! ikelifetime = 86400s keyexchange = ikev2 mobike = no esp = aes128-sha1-modp2048! lifetime = 21600s dpdaction = restart dpddelay = 20s dpdtimeout = 60s leftid = fqdn:local.test.com leftauth = psk rightid = fqdn:remote.test.com rightauth = psk type = transport left = %any right = 2.2.2.2 leftsubnet = 1.1.1.1/32[47] rightsubnet = 2.2.2.2/32[47] auto = route rekey = yes И вроде бы все хорошо, НО! В Routed Connections: как source адрес выставляется либо адрес туннельного интерфейса, либо адрес ezcfg0 интерфейса Вижу Routed Connections: test-tunnel{2}: ROUTED, TRANSPORT, reqid 2 test-tunnel{2}: 78.47.125.180/32[gre] === 2.2.2.2/32[gre] Если сделать руками /usr/lib/ipsec/stroke route test-tunnel То Routed Connections: test-tunnel{2}: ROUTED, TRANSPORT, reqid 2 test-tunnel{2}: 3.3.3.3/32[gre] === 2.2.2.2/32[gre] Где 3.3.3.3/32 адрес на ngre интерфейсе Но ни разу не видел что бы был адрес PPPoE интерфейса Еще вопрос - как убрать lifebytes ? UPD Если strongswan стартовал до того как поднялся интернет (бывает такое что провайдер не отвечает и pppoe долго стартует) то в Routed Connections: как source адрес выставляется адрес ezcfg0 интерфейса Если потом после поднятия инета сделать руками /usr/lib/ipsec/stroke route test-tunnel то в Routed Connections: как source адрес выставляется адрес старшего ngre интерфейса, если в системе три туннеля то берется адрес от ngre2

Они НЕ МОГУТ быть не совместимыми между собой. Потому что настроены туннели с IKEv2, а "Сервер IPsec Virtual IP" использует IKEv1 Для IKEv2 и IKEv1 МОЖНО использовать РАЗНЫЕ proposal (шифрование, хэш, DH). Это просто разработчики криво реализовали логику. Хотя их понять можно, скажем для удаленного доступа используют aes128-sha1-dh14, а для туннеля 3des-md5-dh1, оба IKEv1 И при попытке поднять удаленное подключение с того IP с которого же устанавливается туннель естественно огребем NO_PROPOSAL_CHOSEN. Вот они и перестраховались, но перетянули гайки видимо, не делая различий между IKEv2 и IKEv1. Я бы при активации удаленного доступа и при создании туннелей версии IKEv1 просто бы делал в настройках туннелей не активными те proposal, которые на активированы в удаленном доступе. А cli не ограничивал - если человек лезет в CLI, он понимает что делает. Или бы использовал универсальную настройку для IKE. Вот такую: aes128-sha1-modp1024,aes256-sha256-modp1024,aes128-sha256-modp1024,aes256-sha256-modp2048,aes128-sha256-modp2048! В начале идут группы с modp1024 ибо винда 7ка по умолчанию не умеет modp2048, и при reauth если его инициирует сервер и в первой предложенной группе будет не modp1024 винда дропнет коннект. (Ну или править реестр add a DWORD HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Rasman\Parameters\NegotiateDH2048_AES256 "1") aes128-sha1-modp1024 - единственный более менее приемлемый вариант для iOS младше 9ки.

Для справедливости скажу что после перехода на 2.09.A.7.0-0 то пропадание wi-fi 5GHz про которое я писал постом ранее было единственным за 2е суток.

Переход на версию 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, зарегистрировать модуль на нем и делать рекодинг астериском.