跳至主要內容

IPSec 重协商机制

2025/10/29IPSec VPN原理大约 10 分钟

IPSec 重协商机制

SA 到期时间

FortiGate 的 IPSec 关于 SA 的到期时间，有两个相关的时间概念：

  • hard-timeout：​ 在 IPSec 的一阶段和二阶段中，均可以配置重协商超时时间（lifetime，下文我们用 hard-timeout 来表示配置的 lifetime）。当 hard-timeout 到期后，FortiGate 将结束当前一阶段/二阶段的 SA。hard-timeout 表示每一个一阶段/二阶段 SA 在本地的最大存在时间。默认配置下，FortiGate 的 IPSec 一阶段重协商（hard-timeout）超时时间为 86400s（24 小时），二阶段重协商（hard-timeout）超时时间为 43200s（12 小时）。

  • soft-timeout：​ 实际的重协商间隔时间会小于 hard-timeout，被称为 soft-timeout。soft-timeout 总是小于 hard-timeout。在 hard-timeout 到期前，FortiGate 会发起新的一阶段/二阶段协商并形成一对新的 SA。同时，旧的一阶段/二阶段 SA 直到 hard-timeout 到期时才会消失，在（hard-timeout - soft-timeout）这个时间差（rekey-margin）内，会存在两对 SA。soft-timeout 是一种平滑机制，保证在旧 SA 的 hard-timeout 到期前协商出新的 SA。在旧 SA 与新 SA 交替的过程中，IPSec 业务不会中断。如果在 SA 的 hard-timeout 到期时才重协商新的 SA，那么会导致 IPSec 业务在重协商期间中断。

    重要

    soft-timeout rekey 机制需要在 IPSec 二阶段中开启 keepalive 功能才能生效，详情请参考：VPN → IPSec VPN → 自动协商与 keepalive 章节。

hard-timeout 交互

在 IPSec 一阶段/二阶段协商交互报文中，会携带已配置的重协商时间：

  • IKEv1 主模式：

    • 一阶段，位于第 1、2 个协商报文中：

      image-20240510163525416

    • 二阶段，位于第 1、2 个协商报文中：

      image-20240510163726166

  • IKEv1 野蛮模式：

    • 一阶段，位于第 1、2 个协商报文中：

      image-20240510165150286

    • 二阶段：与 IKEv1 主模式相同，位于第 1、2 个协商报文中。

  • IKEv2：FortiGate 一阶段/二阶段协商时不携带 hard-timeout 参数。

hard-timeout 协商

IKEv1

如 hard-timeout 交互章节所示，IPSec IKEv1 协商的双方会交互 hard-timeout 参数。但并不会因为双方配置的 hard-timeout 不一致而导致协商失败。当 IPSec IKEv1 协商的双方配置的一阶段/二阶段 hard-timeout 不一致时，两端 IPSec 应以 IPSec 协商双方配置的较小的 hard-timeout 为准。如下示例：

  1. FW1 与 FW2 之间建立 IPSec IKEv1（主模式或野蛮模式）连接，FW1 配置 IPSec 的一阶段/二阶段协商时间为 3600s/1800s，FW2 配置 IPSec 的一阶段/二阶段协商时间为 1800s/3600s。

    FW1:
config vpn ipsec phase1-interface
    edit "to_FW2"
        set interface "port2"
        set keylife 3600    <----一阶段hard-timeout
        set net-device disable
        set remote-gw 201.1.1.2
        set psksecret xxxxxx
    next
end

config vpn ipsec phase2-interface
    edit "to_FW2"
        set phase1name "to_FW2"
        set keylifeseconds 1800    <----二阶段hard-timeout
    next
end
    FW2:
config vpn ipsec phase1-interface
    edit "to_FW1"
        set interface "port2"
        set keylife 1800    <----一阶段hard-timeout
        set net-device disable
        set remote-gw 200.1.1.2
        set psksecret xxxxxx
    next
end

config vpn ipsec phase2-interface
    edit "to_FW1"
        set phase1name "to_FW1"
        set keylifeseconds 3600    <----二阶段hard-timeout
    next
end

  2. 两端 IPSec 建立后，查看 IPSec 一阶段的 hard-timeout，可以看到 FW1 和 FW2 协商成功的一阶段 hard-timeout 以 FW2 配置（较小的 hard-timeout）为准（1800s）。

    FW1 # diagnose vpn ike gateway list name to_FW2 | grep "lifetime\|name"
name: to_FW2
  lifetime/rekey: 1800/1778    <----“/”前为协商完成后生效的一阶段hard-timeout
  
FW2 # diagnose vpn ike gateway list name to_FW1 | grep "lifetime\|name"
name: to_FW1
  lifetime/rekey: 1800/1751    <----“/”前为协商完成后生效的一阶段hard-timeout

  3. 查看两端 IPSec 二阶段的 hard-timeout，可以看到 FW1 和 FW2 协商成功的二阶段 hard-timeout 以 FW1 配置（较小的 hard-timeout）为准（1800s）。

    FW1 # get vpn ipsec tunnel name to_FW2 | grep "name\|lifetime"
  name: 'to_FW2'
    name: 'to_FW2'
      lifetime/rekey: 1800/1618    <----“/”前为协商完成后生效的二阶段hard-timeout

FW2 # get vpn ipsec tunnel name to_FW1 | grep "name\|lifetime"
  name: 'to_FW1'
    name: 'to_FW1'
      lifetime/rekey: 1800/1564    <----“/”前为协商完成后生效的二阶段hard-timeout

IKEv2

IKEv2 的协商报文中，不包含任何 hard-timeout 参数，所以 IKEv2 配置下 IPSec 双方的 hard-timeout 以本地配置为准，不会进行交互。如下示例：

  1. FW1 与 FW2 之间建立 IPSec IKEv2 连接，FW1 配置 IPSec 的一阶段/二阶段协商时间为 3600s/1800s，FW2 配置 IPSec 的一阶段/二阶段协商时间为 1800s/3600s。

    FW1:
config vpn ipsec phase1-interface
    edit "to_FW2"
        set interface "port2"
        set ike-version 2
        set keylife 3600    <----一阶段hard-timeout
        set net-device disable
        set remote-gw 201.1.1.2
        set psksecret xxxxxx
    next
end

config vpn ipsec phase2-interface
    edit "to_FW2"
        set phase1name "to_FW2"
        set keylifeseconds 1800    <----二阶段hard-timeout
    next
end
    FW2:
config vpn ipsec phase1-interface
    edit "to_FW1"
        set interface "port2"
        set ike-version 2
        set keylife 1800    <----一阶段hard-timeout
        set net-device disable
        set remote-gw 200.1.1.2
        set psksecret xxxxxx
    next
end

config vpn ipsec phase2-interface
    edit "to_FW1"
        set phase1name "to_FW1"
        set auto-negotiate enable
        set keylifeseconds 3600    <----二阶段hard-timeout
    next
end

  2. 两端 IPSec 建立后，查看 IPSec 一阶段的 hard-timeout，可以看到 FW1 和 FW2 的一阶段 hard-timeout 以本地配置的为准，FW1 为 3600s，FW2 为 1800s。

    FW1 # diagnose vpn ike gateway list name to_FW2 | grep "hard-timeout\|name"
name: to_FW2
  lifetime/rekey: 3600/3313    <----“/”前为协商完成后生效的一阶段hard-timeout
  
FW2 # diagnose vpn ike gateway list name to_FW1 | grep "hard-timeout\|name"
name: to_FW1
  lifetime/rekey: 1800/1725    <----“/”前为协商完成后生效的一阶段hard-timeout

  3. 查看两端 IPSec 二阶段的 hard-timeout，可以看到 FW1 和 FW2 的二阶段 hard-timeout 以本地配置的为准，FW1 为 1800s，FW2 为 3600s。

    FW1 # get vpn ipsec tunnel name to_FW2 | grep "name\|lifetime"
  name: 'to_FW2'
    name: 'to_FW2'
      lifetime/rekey: 1800/1648    <----“/”前为协商完成后生效的二阶段hard-timeout

FW2 # get vpn ipsec tunnel name to_FW1 | grep "name\|lifetime"
  name: 'to_FW1'
    name: 'to_FW1'
      lifetime/rekey: 3600/3299    <----“/”前为协商完成后生效的二阶段hard-timeout

soft-timeout 数值

如上文介绍，soft-timeout 会比 hard-timeout 减小一定的数值（rekey-margin），根据 hard-timeout 设置的大小以及 IPSec 连接建立的会话方向是发起方（initiator）还是响应方（responder），这个减去的值会相应变化，总结如下：

重要

  • initiator：IPSec 一阶段建立成功的发起方，也就是 IKE 成功协商过程中第 1 个 IKE 报文的发起者。
  • responder：IPSec 一阶段建立成功的响应方，也就是 IKE 成功协商过程中第 2 个 IKE 报文的响应者。
hard-timeout 配置发起方 soft-timeout - hard-timeout
(rekey-margin)		响应方 soft-timeout - hard-timeout
(rekey-margin)
hard-timeout < 3600s-30s-20s
hard-timeout ≥ 3600s-300s-270s

无论是发起方（initiator）还是响应方（responder），当 soft-timeout 到期时（hard-timeout 还未到期），会主动与对端 IPSec 协商出一个新的一阶段/二阶段 SA，在（hard-timeout - soft-timeout = rekey-margin）这个时间差内，会与旧的 SA 共存。如下示例：

  1. FW1 与 FW2 之间建立 IPSec IKEv1（主模式或野蛮模式）连接，FW1 配置 IPSec 的一阶段/二阶段协商时间为 120s/120s，FW2 配置 IPSec 的一阶段/二阶段协商时间为 120s/120s。为了测试时使 FW1 一直为响应方（Responder），开启 FW1 IPSec 一阶段中的 passive-mode 功能（不会主动发起 IKE 协商）。

    FW1:
config vpn ipsec phase1-interface
    edit "to_FW2"
        set interface "port2"
        set keylife 120    <----一阶段hard-timeout
        set net-device disable
        set passive-mode enable    <----开启passive-mode，不会主动发起IKE协商
        set remote-gw 201.1.1.2
        set psksecret xxxxxx
    next
end

config vpn ipsec phase2-interface
    edit "to_FW2"
        set phase1name "to_FW2"
        set keylifeseconds 120    <----二阶段hard-timeout
    next
end
    FW2:
config vpn ipsec phase1-interface
    edit "to_FW1"
        set interface "port2"
        set keylife 120    <----一阶段hard-timeout
        set net-device disable
        set remote-gw 200.1.1.2
        set psksecret xxxxxx
    next
end

config vpn ipsec phase2-interface
    edit "to_FW1"
        set phase1name "to_FW1"
        set auto-negotiate enable    <----开启二阶段自动发起协商
        set keylifeseconds 120    <----二阶段hard-timeout
    next
end

  2. 两端 IPSec 建立后，立即查看 IPSec 一阶段的 hard-timeout 与 soft-timeout，可以看到响应方（responder）FW1 的 soft-timeout 比 hard-timeout 小 20s，发起方（initiator）FW2 的 soft-timeout 比 hard-timeout 小 30s，符合本章节开头的总结。

    FW1 # diagnose vpn ike gateway list name to_FW2 | grep "name\|lifetime\|status\|direction"
name: to_FW2
  direction: responder    <----FW1为IKE会话的响应方
  status: established 0-0s ago = 0ms    <----SA已建立时间
  lifetime/rekey: 120/100    <----作为Responder，soft-timeout比hard-timeout小20s
  
FW2 # diagnose vpn ike gateway list name to_FW1 | grep "name\|lifetime\|status\|direction"
name: to_FW1
  direction: initiator    <----FW2为IKE会话的发起方
  status: established 0-0s ago = 0ms    <----SA已建立时间
  lifetime/rekey: 120/90    <----作为Initiator，soft-timeout比hard-timeout小30s

  3. 在连接刚建立时，立即查看 IPSec 二阶段的 hard-timeout 与 soft-timeout，可以看到响应方（responder）FW1 的 soft-timeout 比 hard-timeout 小 20s，发起方（initiator）FW2 的 soft-timeout 比 hard-timeout 小 30s，符合本章节开头的总结。

    FW1 # get vpn ipsec tunnel name to_FW2 | grep "name\|lifetime"
  name: 'to_FW2'
    name: 'to_FW2'
      lifetime/rekey: 120/100    <----作为Responder，soft-timeout比hard-timeout小20s

FW2 # get vpn ipsec tunnel name to_FW1 | grep "name\|lifetime"
  name: 'to_FW1'
    name: 'to_FW1'
      lifetime/rekey: 120/90    <----作为Initiator，soft-timeout比hard-timeout小30s

  4. 所以理论上，发起方 FW2（initiator）的 soft-timeout 总是比响应方 FW1（responder）的 soft-timeout 先到期。

  5. 等待发起方 FW2（initiator）的一阶段 soft-timeout 到期，发起方 FW2（initiator）会主动与 FW1 协商一个新的 SA（soft-timeout 从 90s 开始倒计时），旧 SA 的 soft-timeout 虽然变为 0，但会重新从 30s（hard-timeout - soft-timeout）开始倒计时，旧 SA 的倒计时参数从 rekey 变为 expiry。

    FW2 # diagnose vpn ike gateway list name to_FW1 | grep "name\|lifetime\|status\|direction"
name: to_FW1
  direction: initiator
  lifetime/rekey: 120/0    <----FW2(initiator)的soft-timeout倒计时结束
      
FW2 # diagnose vpn ike gateway list name to_FW1 | grep "name\|lifetime\|status\|direction"
name: to_FW1
  direction: initiator
  lifetime/rekey: 120/90    <----新的SA生成，rekey时间从90s开始倒计时
  direction: initiator
  hard-timeout/expiry: 120/30    <----FW2(initiator)的旧SA，soft-timeout到期后，剩余的hard-timeout倒计时

  6. 30s 后，FW2 旧 SA 的 expiry 倒计时结束，旧 SA 彻底删除，只剩下新的 SA。

    FW2 # diagnose vpn ike gateway list name to_FW1 | grep "name\|lifetime\|status\|direction"
name: to_FW1
  direction: initiator
  lifetime/rekey: 120/59    <----新SA的soft-timeout倒计时，旧SA删除

  7. 二阶段的情况与一阶段一致，所以在这种 soft-timeout 机制下，由于旧 SA 与新 SA 有共同存在时间差（hard-timeout - soft-timeout），只要网络状态正常，IPSec 业务不会产生中断。

Rekey 报文交互

IKEv1 主模式

FW2 的 SA soft-timeout 到期时发起的新的 SA 协商，新的 SA 协商正常使用 IKEv1 主模式报文（一阶段 6 个包，二阶段 3 个包）交互，根据是否为 NAT-T 环境，Rekey 协商报文所使用的端口有所不同：

  • NAT-T：使用 Rekey 方式协商的 IKEv1 报文，所有协商报文将使用 UDP 4500 端口进行协商，报文内容不变。

    重要

    而新发起（非 Rekey 方式）的 IKEv1 主模式协商第一阶段前 4 个报文使用 UDP 500 端口，后 2 个报文才开始使用 UDP 4500 端口）。

    image-20240515175228847

  • 非 NAT-T：无论是 Rekey 方式还是新发起的 IKEv1 主模式协商，都是用 UDP 500 端口。

IKEv1 野蛮模式

FW2 的 SA soft-timeout 到期时发起的新的 SA 协商，新的 SA 协商正常使用 IKEv1 野蛮模式报文（一阶段 3 个包，二阶段 3 个包）交互，根据是否为 NAT-T 环境，Rekey 协商报文所使用的端口有所不同：

  • NAT-T：使用 Rekey 方式协商的 IKEv1 报文，所有协商报文将使用 UDP 4500 端口进行协商，报文内容不变。

    重要

    而新发起（非 Rekey 方式）的 IKEv1 野蛮模式协商第一阶段前 2 个报文使用 UDP 500 端口，最后 1 个报文才开始使用 UDP 4500 端口）。

    image-20240515180451831

  • 非 NAT-T：无论是 Rekey 方式还是新发起的 IKEv1 野蛮模式协商，都是用 UDP 500 端口。

IKEv2

FW2 的 SA soft-timeout 到期时发起的新的 SA 协商，新的一阶段 SA 协商包（原 IKE_SA_INIT）使用旧的一阶段 SA 进行加密/验证，使用 CREATE_CHILD_SA 封装发送，新的二阶段 SA 协商包（原 IKE_AUTH）使用新的一阶段 SA 进行加密/验证，使用 CREATE_CHILD_SA 封装发送。所以对于 IKEv2 的 Rekey 过程，均是被加密/验证保护的：

  • NAT-T：使用 Rekey 方式协商的 IKEv2 报文，所有协商报文将使用 UDP 4500 端口进行协商，报文内容不变。

    重要

    而新发起（非 Rekey 方式）的 IKEv2 协商 IKE_SA_INIT 的 2 个报文使用 UDP 500 端口，IKE_AUTH 的 2 个报文才开始使用 UDP 4500 端口）。

    image-20240516180808037

  • 非 NAT-T：无论是 Rekey 方式还是新发起的 IKEv2 协商，都是用 UDP 500 端口。

最近更新: