IPSec重协商机制

SA到期时间

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

  • Lifetime(Hardtime):在IPSec的一阶段和二阶段中,均可以配置重协商超时时间(Lifetime),当Lifetime到期后,FortiGate将结束当前一阶段/二阶段的SA。Lifetime表示每一个一阶段/二阶段SA在本地的最大存在时间。默认配置下,FortiGate的IPSec一阶段重协商(lifetime)超时时间为86400s(24小时),二阶段重协商(lifetime)超时时间为43200s(12小时)。
  • Rekey Time(Softtime):实际的重协商间隔时间会小于Lifetime,被称为Rekey Time。Rekey Time总是小于Lifetime。在Lifetime到期前,FortiGate会发起新的一阶段/二阶段协商并形成一对新的SA。同时,旧的一阶段/二阶段SA直到Lifetime到期时才会消失,在(Lifetime - Rekey Time)这个时间差内,会存在两对SA。Rekey Time是一种平滑机制,保证在旧SA的Lifetime到期前协商出新的SA。在旧SA与新SA交替的过程中,IPSec业务不会中断。如果在SA的Lifetime到期时才重协商新的SA,那么会导致IPSec业务在重协商期间中断。

Lifetime交互

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

  • IKEv1主模式:

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

      image-20240510163525416

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

      image-20240510163726166

  • IKEv1野蛮模式:

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

      image-20240510165150286

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

  • IKEv2:FortiGate一阶段/二阶段协商时不携带Lifetime参数。

Lifetime协商

IKEv1

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

  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    <----一阶段Lifetime
            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    <----二阶段Lifetime
        next
    end
    
    FW2:
    config vpn ipsec phase1-interface
        edit "to_FW1"
            set interface "port2"
            set keylife 1800    <----一阶段Lifetime
            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    <----二阶段Lifetime
        next
    end
    
  2. 两端IPSec建立后,查看IPSec一阶段的Lifetime,可以看到FW1和FW2协商成功的一阶段Lifetime以FW2配置(较小的Lifetime)为准(1800s)。

    FW1 # diagnose vpn ike gateway list name to_FW2 | grep "lifetime\|name"
    name: to_FW2
      lifetime/rekey: 1800/1778    <----“/”前为协商完成后生效的一阶段Lifetime
    
    FW2 # diagnose vpn ike gateway list name to_FW1 | grep "lifetime\|name"
    name: to_FW1
      lifetime/rekey: 1800/1751    <----“/”前为协商完成后生效的一阶段Lifetime
    
  3. 查看两端IPSec二阶段的Lifetime,可以看到FW1和FW2协商成功的二阶段Lifetime以FW1配置(较小的Lifetime)为准(1800s)。

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

IKEv2

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

  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    <----一阶段Lifetime
            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    <----二阶段Lifetime
        next
    end
    
    FW2:
    config vpn ipsec phase1-interface
        edit "to_FW1"
            set interface "port2"
            set ike-version 2
            set keylife 1800    <----一阶段Lifetime
            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    <----二阶段Lifetime
        next
    end
    
  2. 两端IPSec建立后,查看IPSec一阶段的Lifetime,可以看到FW1和FW2的一阶段Lifetime以本地配置的为准,FW1为3600s,FW2为1800s。

    FW1 # diagnose vpn ike gateway list name to_FW2 | grep "lifetime\|name"
    name: to_FW2
      lifetime/rekey: 3600/3313    <----“/”前为协商完成后生效的一阶段Lifetime
    
    FW2 # diagnose vpn ike gateway list name to_FW1 | grep "lifetime\|name"
    name: to_FW1
      lifetime/rekey: 1800/1725    <----“/”前为协商完成后生效的一阶段Lifetime
    
  3. 查看两端IPSec二阶段的Lifetime,可以看到FW1和FW2的二阶段Lifetime以本地配置的为准,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    <----“/”前为协商完成后生效的二阶段Lifetime
    
    FW2 # get vpn ipsec tunnel name to_FW1 | grep "name\|lifetime"
      name: 'to_FW1'
        name: 'to_FW1'
          lifetime/rekey: 3600/3299    <----“/”前为协商完成后生效的二阶段Lifetime
    

Rekey Time数值

如上文介绍,Rekey Time会比Lifetime减小一定的数值,根据Lifetime设置的大小以及IPSec连接建立的会话方向是发起方(initiator)还是响应方(responder),这个减去的值会相应变化,总结如下:

  • initiator:IPSec一阶段建立成功的发起方,也就是IKE成功协商过程中第1个IKE报文的发起者。
  • responder:IPSec一阶段建立成功的响应方,也就是IKE成功协商过程中第2个IKE报文的响应者。
Lifetime配置 发起方RekeyTime相对Lifetime减少时间 响应方RekeyTime相对Lifetime减少时间
Lifetime<3600s -30s -20s
Lifetime≥3600s -300s -270s

无论是发起方(initiator)还是响应方(responder),当Rekey Time到期时(Lifetime还未到期),会主动与对端IPSec协商出一个新的一阶段/二阶段SA,在(Lifetime - Rekey Time)这个时间差内,会与旧的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    <----一阶段Lifetime
            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    <----二阶段Lifetime
        next
    end
    
    FW2:
    config vpn ipsec phase1-interface
        edit "to_FW1"
            set interface "port2"
            set keylife 120    <----一阶段Lifetime
            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    <----二阶段Lifetime
        next
    end
    
  2. 两端IPSec建立后,立即查看IPSec一阶段的Lifetime与Rekey Time,可以看到响应方(responder)FW1的Rekey Time比Lifetime小20s,发起方(initiator)FW2的Rekey Time比Lifetime小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,RekeyTime比Lifetime小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,RekeyTime比Lifetime小30s
    
  3. 在连接刚建立时,立即查看IPSec二阶段的Lifetime与Rekey Time,可以看到响应方(responder)FW1的Rekey Time比Lifetime小20s,发起方(initiator)FW2的Rekey Time比Lifetime小30s,符合本章节开头的总结。

    FW2 # diagnose vpn ike gateway list name to_FW1 | grep "name\|lifetime\|status\|direction"
      name: 'to_FW2'
        name: 'to_FW2'
          lifetime/rekey: 120/100    <----作为Responder,RekeyTime比Lifetime小20s
    
    FW2 # get vpn ipsec tunnel name to_FW1 | grep "name\|lifetime"
      name: 'to_FW1'
        name: 'to_FW1'
          lifetime/rekey: 120/90    <----作为Initiator,RekeyTime比Lifetime小30s
    
  4. 所以理论上,发起方FW2(initiator)的Rekey Time总是比响应方FW1(responder)的Rekey Time先到期。

  5. 等待发起方FW2(initiator)的一阶段Rekey Time到期,发起方FW2(initiator)会主动与FW1协商一个新的SA(Rekey Time从90s开始倒计时),旧SA的Rekey Time虽然变为0,但会重新从30s(Lifetime - Rekey Time)开始倒计时,旧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)的RekeyTime倒计时结束
    
    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
      lifetime/expiry: 120/30    <----FW2(initiator)的旧SA,RekeyTime到期后,剩余的Lifetime倒计时
    
  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的RekeyTime倒计时,旧SA删除
    
  7. 二阶段的情况与一阶段一致,所以在这种Rekey Time机制下,由于旧SA与新SA有共同存在时间差(Lifetime - Rekey Time),只要网络状态正常,IPSec业务不会产生中断。

Rekey报文交互

IKEv1主模式

FW2的SA Rekey Time到期时发起的新的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 Rekey Time到期时发起的新的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 Rekey Time到期时发起的新的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端口。

Copyright © 2024 Fortinet Inc. All rights reserved. Powered by Fortinet TAC Team.
📲扫描下方二维码分享此页面👇
该页面修订于: 2024-05-20 15:03:12

results matching ""

    No results matching ""