gaaronk

В 2.09.A.9.0-0 сломали ручные transport туннели На большом сервер я вижу keen-tun[455]: ESTABLISHED 32 seconds ago, 2.2.2.2[first.test.com]...1.1.1.1[keen.test.com] keen-tun[455]: IKEv2 SPIs: 32915b5f5a09ff39_i 389258019666757e_r*, pre-shared key reauthentication in 23 hours keen-tun[455]: IKE proposal: AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048 keen-tun{358}: INSTALLED, TRANSPORT, reqid 2, ESP SPIs: c1ef525e_i cddfb68e_o keen-tun{358}: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 588 bytes_o (7 pkts, 32s ago), rekeying in 5 hours keen-tun{358}: 2.2.2.2/32[gre] === 1.1.1.10/32[gre] При этом на кинетике туннель висит в состоянии first-tunnel[96]: CONNECTING, 1.1.1.1[keen.test.com]...2.2.2.2[first.test.com] first-tunnel[96]: IKEv2 SPIs: 32915b5f5a09ff39_i* 389258019666757e_r first-tunnel[96]: IKE proposal: AES_CBC=256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048/# first-tunnel[96]: Tasks active: IKE_CERT_PRE IKE_AUTH IKE_CERT_POST IKE_CONFIG CHILD_CREATE IKE_AUTH_LIFETIME и #ip x s src 2.2.2.2 dst 1.1.1.1 proto esp spi 0xcddfb68e reqid 0 mode tunnel replay-window 0 sel src 2.2.2.2/32 dst 1.1.1.1/32 src 1.1.1.1 dst 2.2.2.2 proto esp spi 0x00000000 reqid 35 mode transport replay-window 0 sel src 1.1.1.1/32 dst 2.2.2.2/32 proto gre key 0 Почему моде тунель, хотя должен быть транспорт?

Настраивайте через CLI В CLI же изменения автоматом не сохраняются. заходите по ssh, запускаете sleep 600 && reboot & И настраиваете. У вас есть 10 минут. Если все хорошо ищите PID процесса sleep и даете ему kill Если все плохо через 10 минут ребутнется с исходным конифгом.

Мультикаст только в EoIP или GRE Броадкаст только а EoIP

У меня один клиент поднимающий ко мне туннель сидит за NAT с динамическим IP. Он инициирует ко мне коннект и сван в updown скрипте на моей стороне делает так #!/bin/sh [ "$PLUTO_VERB" != "up-host" ] && exit 0 ip tun change gre3 remote $PLUTO_PEER /usr/bin/logger -t "ipsec-vpn-tun" "cahnge tunnel address to $PLUTO_PEER" exit 0 Можно, наверное сделать такую логику и тут, и конфигурировать такой интерфейс как interface Gre1 tunnel source PPPoE0 tunnel destination dynamic Хотя может это и извращение

На текущий момент HTTPS для веб интерфейса без проблем реализовался при помощи stunnel из entware

Нда. Слона то я и не приметил =( charon.ignore_routing_tables "A space-separated list of routing tables to be excluded from route lookup." Надо было этот параметр задавать

Костыль по настройке strongswan под себя усовершенствован Cоздаем дополнительный файлик с настройками strongswan - /opt/etc/strongswan_opt.conf Например charon { interfaces_ignore = "br0, br1, ngre0, ngre1, ezcfg0" make_before_break = yes } При старте системы копируем его куда надо и один раз (а не каждый раз при монтировании флешки с entware) дергаем демона # fix strongswan if [ ! -f "/tmp/ipsec/strongswan_opt.conf" ]; then cp /opt/etc/strongswan_opt.conf /tmp/ipsec/ /opt/usr/sbin/swan-fix.sh & fi swan-fix.sh конфиги не трогает, только рестартует сервис #!/bin/sh while true; do SPID=`pidof charon` if [ ! -z "$SPID" ]; then kill $SPID /opt/bin/logger -t "swan-fix" "Fix strongswan interfaces" exit 0 fi sleep 1 done В принципе этого не надо, обычно у меня скрипт при старте системы отрабатывает до старта strongswan. Но это так, на всякий случай. Зато если теперь сделать no service ipsec service ipsec То внесенные вами изменения в конфиг не пропадут.

Вот кусок конфига subnet создавался после конфигурирования туннеля interface TunnelSixInFour0 description "Test Tun" ip remote 1.1.1.1 ipv6 address 2a01:4f8:173:641:0:2:0:3 ipv6 prefix 2a01:4f8:173:641:0:2:2:0/112 ipv6 force-default up ! ipv6 subnet Test bind Home number 4 mode slaac Вот лог May 16 13:06:57 ndmNetwork::Interface::Base: "TunnelSixInFour0": description saved. May 16 13:06:57 ndmNetwork::Interface::Tunnel6: static remote address saved. May 16 13:06:57 ipsec05 [KNL] 2a01:4f8:173:641:0:2:0:3 appeared on tun6in4_1 May 16 13:06:57 ndm Ip6::Prefixes: added static prefix: 2a01:4f8:173:641:0:2:2:0/112. May 16 13:06:57 ndm Json::Object: AppendMember: duplicate key: "message". May 16 13:06:57 ndm Opkg::Manager: /opt/etc/ndm/netfilter.d/02_nat.sh: Another app is currently holding the xtables lock. Perhaps you want to use the -w option? May 16 13:06:57 ndmCore::Syslog: last message repeated 3 times. May 16 13:06:57 iptables Add GRE rules to table nat May 16 13:07:52 ndm Ip6::Subnets: created subnet "Test". May 16 13:07:57 ndm Ip6::Addressing: system failed [0xcffd0055], unable to set :: to br0: address not available. May 16 13:07:57 ndm Ip6::Subnets: interface "Home" bound to subnet "Test". May 16 13:08:03 ndm Ip6::Addressing: system failed [0xcffd0055], unable to remove :: from br0: address not available. May 16 13:08:03 ndm Ip6::Addressing: system failed [0xcffd0055], unable to set :: to br0: address not available. May 16 13:08:03 ndm Ip6::Subnets: subnet "Test" enabled as SLAAC. May 16 13:08:05 radvd[4611]version 2.15 started May 16 13:08:05 radvd[4611]br0 prefix length should be: 64 May 16 13:08:07 ndm Ip6::Addressing: system failed [0xcffd0055], unable to remove :: from br0: address not available. May 16 13:08:07 ndm Ip6::Addressing: system failed [0xcffd0055], unable to set :: to br0: address not available. May 16 13:08:07 ndm Ip6::Subnets: number 4 assigned to subnet "Test". May 16 13:08:07 radvd[4611]br0 prefix length should be: 64 May 16 13:09:17 ndmCore::Configurator: bye. May 16 13:09:17 ndmCore::Server: client disconnected. Вот скриншот Кстати бага. После задания параметров туннеля, хочешь его отредактировать и получаешь Надо в поле ввода менять последний 0 на двоеточие, что бы получилось 2a01:4f8:173:641:0:2:2::/112

А скажите, зачем после CHILD_SA rekeying дергать iptables? Параметры туннеля то не меняются.

О! Фрагментация. Реквестирую crypto ipsec df-bit clear

Только преобразовалок в комплекте не идет =)

Спасибо, хоть что то. Хотя кроме дичайшего отторжения это ничего более не вызывает. XML формат не для людей, для компов.

Да, но нет. Это из CLI. А надо из shell ndmq -p "show log once" -P message Ничего не выводит

Можно ли находясь в ssh сессии как либо посмотреть лог?

Ага. Понятно. Но при настройке руками delegated prefix размера /112 (уже понятно что это не совсем корректно) разные number генерировали странные подсети с масками /113, /114, /116 без понятной зависимости. Это наверное некорректное поведение, и делать так вообще не надо.

Спасибо! С этим понятно. А ipv6 subnet number как вычисляет подсети?

А давайте в 2.10 для авто-туннелей опциональную команду на интерфейсе включающую ikev2 ? Все остальные настройки естественно не трогаются. По умолчанию для совместимости ikev1.

Поясните пожалуйста логику работы ipv6 subnet number ? Как именно из ipv6 prefix вычсиляется подсеть? И еще вопрос. Правильно ли я понимаю логику работы. Я настраиваю TunnelSixInFour0 с ipv6 адресом для point-to-point соединения. На другой стороне мой сервер (не брокер!) где я поднимаю sit туннель. Все работает. На большом сервере в сторону туннеля я маршрутизирую <ip6_subnet>/112 для кинетика Соответственно на интерфейсе TunnelSixInFour0 я указываю ipv6 prefix <ip6_subnet>/112 - ipv6 prefix указывается на том интерфейсе через который он нам прилетает (верно?) Теперь делаю ipv6 subnet Home6 bind Home number 1 mode slaac Как я понимаю на интерфейсе br0 рутер начинает анонсировать <ip6_sub_subnet>/114 для клиентов. и Этот ip6_sub_subnet и его маска рассчитываются исходя из number На самом интерфейсе Home IPv6 адрес при этом не назначается, и в принципе он и не нужен, но я могу его настроить статически руками взяв адрес из диапазона <ip6_subnet>/112 который не пересекается с анонсируемой <ip6_sub_subnet>/114

interfaces_ignore = ezcfg0 - появился а команды нет :(

А не должен и не может работать pmtu в этом случае

Не очень хороше решение. В таком случае трекер видит IP той точки через которую идет отдельный рутинг и пытается раздавать его как peer другим качальщикам. Для рутрекера лучше решение с privoxy

Как сейчас сделано у меня Есть статические туннели, есть удаленный доступ, есть туннели которые принимаются с любого адреса (на клиенте ISP каждый раз назначает новый адрес). Пример для IKEv2 Берутся настройки IKE для каждого типа подключения и суммируются. То есть если на туннеле 3des-aes128-md5-dh1, а для RA aes128-sha1-dh14 то итог 3des-aes128-md5-sha1-dh1-dh14 И создается отдельный темплейт чисто под IKE, на который ссылаются соединения Примерно так conn tmpl-ikev2 ike=aes256-aes128-sha256-modp2048,aes256gcm16-aes128gcm16-prfsha256-modp2048! conn first-tun also=tmpl-ikev2 <...> conn IKEv2-RA-RSA # for windows machine certificate with full DN as local ID also=tmpl-ikev2 <...>

Вот куски конфига access-list acl-first-gre permit gre 5.5.5.5 255.255.255.255 1.1.1.1 255.255.255.255 ! access-list acl-second-gre permit gre 5.5.5.5 255.255.255.255 2.2.2.2 255.255.255.255 interface Gre0 rename First security-level private ip address 192.168.1.10 255.255.255.252 ip dhcp client no dns-routes ip dhcp client no name-servers ip mtu 1400 ip tcp adjust-mss pmtu tunnel source PPPoE0 tunnel destination 1.1.1.1 up ! interface Gre1 rename Second security-level private ip address 192.168.1.14 255.255.255.252 ip dhcp client no dns-routes ip dhcp client no name-servers ip mtu 1400 ip tcp adjust-mss pmtu tunnel source PPPoE0 tunnel destination 2.2.2.2 up crypto engine hardware crypto ike key first.test.com ns3 wFGX... fqdn first.test.com crypto ike key second.test.com ns3 l8e... fqdn second.test.com crypto ike proposal ike-aes256-sha256 encryption aes-cbc-256 dh-group 14 integrity sha256 ! crypto ike policy tun-ikev2-policy proposal ike-aes256-sha256 lifetime 86400 mode ikev2 ! crypto ipsec transform-set esp-aes128-sha1 cypher esp-aes-128 hmac esp-sha1-hmac dh-group 14 lifetime 21600 crypto ipsec profile first.test.com dpd-interval 20 identity-local fqdn local.test.com match-identity-remote fqdn first.test.com authentication-local pre-share authentication-remote pre-share mode transport policy tun-ikev2-policy ! crypto ipsec profile second.test.com dpd-interval 20 identity-local fqdn local.test.com match-identity-remote fqdn second.test.com authentication-local pre-share authentication-remote pre-share mode transport policy tun-ikev2-policy crypto ipsec mtu auto crypto map first-tunnel set-peer 1.1.1.1 set-profile first.test.com set-transform esp-aes128-sha1 match-address acl-first-gre nail-up virtual-ip no enable enable ! crypto map wombat-tunnel set-peer 2.2.2.2 set-profile second.test.com set-transform esp-aes128-sha1 match-address acl-second-gre nail-up virtual-ip no enable enable service ipsec Стартовали, все хорошо. Оба туннеля поднялись и ROUTED Заходим в CLI, хотим проверить linked key (config)> (config)> crypto ipsec profile second.test.com Core::Configurator: Done. (config-ipsec-profile)> preshared-key NEW_KEY Все. second-tunnel перпеподнялся с новой конфигурацией и с linked key first-runnel не дергался, но перестал быть ROUTED

Тогда отлично. Я просто думал что речь про SIP, а не DECT, а то там возникает транскодинг (ну могут же быть разные legs на разных кодеках), выравнивание по громкости и прочая фигня.

Конференция это очень не банальная штука. Просто ее не сделать.