В настоящее время я использую следующую конфигурацию. Я должен переключиться на rekey=yes и если да, то почему? Я хочу обеспечить совершенную прямую секретность (PFS). Другие предложения по безопасности приветствуются.
config setup
charondebug="ike 1, knl 1, cfg 0"
uniqueids=never
conn ikev2
auto=add
compress=no
type=tunnel
keyexchange=ikev2
fragmentation=yes
forceencaps=yes
ike=aes256gcm16-sha384-modp3072!
esp=aes256gcm16-sha384-modp3072!
dpdaction=clear
dpddelay=300s
rekey=no
left=%any
leftid=my-vpn.com
leftcert=vpn-server.crt
leftsendcert=always
leftsubnet=0.0.0.0/0
right=%any
rightid=%any
rightauth=eap-tls
rightdns=1.1.1.1,1.0.0.1
rightsourceip=%dhcp
rightsendcert=never
eap_identity=%identity
Идеальная прямая секретность (PFS) является неотъемлемой частью IKEv2, поскольку ключевой материал для каждого IKE_SA является производным от эфемерного обмена Диффи-Хеллмана (DH) и повторное использование факторов DH это (надеюсь) не очень распространенная практика (strongSwan этого не делает).
Таким образом, даже без смены ключей каждый новый IKE_SA будет использовать независимые ключи. Если не используется бездетное инициирование IKE_SA (RFC 6023), ключи для первого CHILD_SA всегда выводятся из этого ключевого материала. Если созданы дополнительные CHILD_SA (не в случае с вашей конфигурацией), они могут дополнительно получить ключи из отдельного обмена DH.
Смена ключей IKE_SA всегда требует использования обмена DH для создания полностью независимого ключевого материала, это необязательно при смене ключей CHILD_SA. Опять же, без обмена DH ключи CHILD_SA являются производными от материала ключа IKE_SA. Это означает, что в зависимости от того, был ли изменен ключ IKE_SA перед CHILD_SA, новые ключи CHILD_SA не связаны с теми, которые использовались предыдущим CHILD_SA.
Таким образом, изменение ключей в основном контролирует, как долго, а для CHILD_SA также и сколько пакетов / байтов используется конкретный набор ключей, то есть сколько данных злоумышленник, записавший весь трафик, может расшифровать после успешной атаки на один обмен DH. Использовать ли смену ключей и с какой периодичностью, следовательно, зависит от ваших политик / предпочтений в этих аспектах (это также зависит от того, как долго вы ожидаете, что соединение будет устанавливаться за раз).
Для IKE_SAs также можно использовать повторная аутентификация (reauth=yes в ipsec.conf) вместо смены ключей, что создает новый IKE_SA и его CHILD_SA с нуля (либо до, либо после разрушения предыдущих SA). Это может, например, использоваться для обеспечения того, чтобы клиент по-прежнему имел доступ к закрытому ключу на смарт-карте. Однако этот процесс не такой плавный, как встроенная замена ключей, поэтому некоторые пакеты могут быть отброшены (в частности, если используется повторная аутентификация по умолчанию break-before-make).