gaaronk

А вот и косвенная бага. У меня два туннеля. оба траспорт, оба без connect - enable IPsec crypto map autoconnection В конфиге auto = route Когда по живому реконфигурируешь crypto ipsec profile то соединение естественно падает и поднимается, второе соединение остается в состоянии ESTABLISHED. Но! Для него пропадает секция ROUTED, TRANSPORT В логе видно May 10 12:21:19ndmIpSec::Configurator: start reloading IPsec config task. May 10 12:21:19ipsec12[CFG] received stroke: unroute 'first-tunnel' May 10 12:21:19ipsecconfiguration 'first-tunnel' unrouted May 10 12:21:19ipsec May 10 12:21:19ipsec16[CFG] received stroke: delete connection 'first-tunnel' May 10 12:21:19ipsec16[CFG] deleted connection 'first-tunnel' May 10 12:21:19ipsec10[CFG] received stroke: unroute 'second-tunnel' May 10 12:21:19ipsecconfiguration 'second-tunnel' unrouted May 10 12:21:19ipsec May 10 12:21:19ipsec13[CFG] received stroke: delete connection 'second-tunnel' May 10 12:21:19ipsec13[CFG] deleted connection 'second-tunnel' May 10 12:21:19ipsec00[DMN] signal of type SIGHUP received. Reloading configuration May 10 12:21:19ipsec05[CFG] received stroke: add connection 'first-tunnel' May 10 12:21:19ipsec00[CFG] loaded 0 entries for attr plugin configuration May 10 12:21:19ipsec05[CFG] added configuration 'first-tunnel' May 10 12:21:19ipsec11[CFG] received stroke: add connection 'second-tunnel' May 10 12:21:19ipsec11[CFG] added configuration 'second-tunnel' May 10 12:21:19ndmIpSec::Configurator: reloading IPsec config task done. May 10 12:21:19ndmIpSec::IpSecNetfilter: start reloading netfilter configuration... May 10 12:21:19ndmIpSec::IpSecNetfilter: netfilter configuration reloading is done. May 10 12:21:21ndmIpSec::Configurator: crypto map "second-tunnel" shutdown started. May 10 12:21:21ipsec16[CFG] received stroke: unroute 'second-tunnel' May 10 12:21:21ipsec10[CFG] received stroke: terminate 'second-tunnel{*}' May 10 12:21:22ndmIpSec::Configurator: crypto map "second-tunnel" routing started. May 10 12:21:22ipsec07[CFG] received stroke: route 'second-tunnel' May 10 12:21:22ndmIpSec::Configurator: crypto map "second-tunnel" routing complete. Меняли second-tunnel Зачем то оно делало received stroke: unroute 'first-tunnel' received stroke: delete connection 'first-tunnel' хотя по факту первый туннель "не сложился" а вот route 'first-tunnel' потом не пришло linked key работает UPD 2.09.A.7.0-2

Отлично, сейчас проверим.

Ну ручной ipsec в транспортном режиме я оттестировал очень плотно. Все работает на ура. Кроме бага с linked key for crypto map о котором я писал и вот этого с таблицами маршрутизации. В отдельной таблице у меня дефолт и правилами ip rule на эту таблицу у меня заворачивается "интересный" трафик. А команда для ручного режима желательна конечно. Ну или буду использовать свой мегакостыль на старте. lifebytes да, абсолютно не мешает, это просто "для красоты", но раз оно надо то и хорошо.

С этим я абсолютно согласен. Поэтому и предложил для этого как вариант по умолчанию ввести режим "автонастройка" где для IKE и ESP подобраны параметры которые гарантированно заработают на всех клиентских устройствах и операционках.

А для решения этой проблемы Или например прямо на интерфейсе interface Gre0 ipsec no enable UPD можно конечно попробовать патчить и ковырять сам сван, но с учетом того что на x86 проблема не воспроизводится - это imho долгий путь.

Возможность деактивировать демона strongswan на указанных в конфигурации интерфейсах Указание в CLI что то вроде crypto ipsec ignore <interface name> строк может быть много, список интерфейсов попадает в конфигурацию strongswan.conf charon { interfaces_ignore = "name0, name2, name3" }

А дома у меня рутер это стоковый дебиан в виртуалке на сервере виртуальных машин. Там бэкпортированный мной сван 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 (недолго правда, один час).