gaaronk

Я вот 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 не хранят в памяти логин\пароль, и НЕ умеют заново запросить его у пользователя.

Это видимо в 2.09, я не указал свою версию ПО. У меня стабильная 2.08 ip adjust-ttl send 64 Command::Base error[7405602]: inc: argument parse error. Впрочем это надо было для работы OSPF, и уже не актуально, так как в bird можно сказать на интерфейсе ttl security tx only; И он начнет слать мультикаст пакет с TTL 255, а не 1.

Сейчас максимально возможная длина 68 символов. Думаю стоит ограничить в 128. Процитирую вики стронгсвана As you can see from the above formula, the maximum key size a HMAC-based prf can handle is equivalent to its internal block size which is 512 bits or 64 bytes for SHA-1 and SHA-2_256 or 1024 bits or 128 bytes for SHA-2_384 and SHA-2_512. Thus a restriction to a 64 byte PSK makes sense if you don't care for the HMAC being used. If you explicitly specify sha384 or sha512 in your ike= parameter, then a PSK of up to 128 bytes is possible.

Можно ли для GRE туннеля явно задать TTL, вместо inherit ? Или как можно выполнить что то вроде ip tun change ngre0 ttl 64 сразу по поднятию интерфейса?

При использовании для IPSec достаточно длинного PSK - 120 символов, при выполнении sh run получаю в выводе ! ERROR: command "crypto ike key": not enough arguments !Command::Argument::Password ERROR[268304478]: out of memory [0xcffe005e]. А в логе Mar 08 14:08:34ndmCommand::Argument::Password: out of memory [0xcffe005e]. Mar 08 14:08:34ndmCommand::Argument::Password: out of memory [0xcffe005e]. При этом ввести в CLI такой PSK можно, файл /var/ipsec/ipsec.secrets создается верный, туннель работает. ПО release: v2.08(AAUW.0)C1