gaaronk

Поясните пожалуйста логику работы 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 на разных кодеках), выравнивание по громкости и прочая фигня.

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

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