华为防火墙HCIA学习笔记06_ipsec ***

IPSec ***技术与应用

IPSec ***技术原理

 

IPSec基本概念

• IPSec 对等体：
  • IPSec用于在协商发起方和响应方这两个端点之间提供安全的IP通信，通信的两个端点被称为IPSec对等体。其中，端点可以是网关路由器或者防火墙，也可以是主机。
• IPSec 隧道：
  • IPSec为对等体间建立IPSec隧道来提供对数据流的安全保护。一对IPSec对等体间可以存在多条IPSec隧道，针对不同的数据流各选择一条隧道对其进行保护，例如有的数据流只需要认证、有的需要认证和加密。
  • IPSec对数据的加密是以数据包为单位，而不是以整个数据流为单位。发送方对要保护的数据包进行加密封装，在Internet上传输，接收方采用相同的参数对报文认证、解封装，以得到原始数据。

 

IPSec协议体系结构

• IPSec *** 体系结构主要由验证头 AH （ Authentication Header ）、封装安全载荷 ESP （ Encapsulating Security Payload ）和因特网密钥交换 IKE （ Internet Key Exchange ）协议套件组成。 IPSec 通过 AH 和 ESP 两个安全协议实现 IP 报文的安全保护，通过 ESP 来保障 IP 数据传输过程的机密性，使用 AH/ESP 提供数据完整性、数据源验证和抗报文重放功能。 ESP 和 AH 定义了协议和载荷头的格式及所提供的服务，但却没有定义实现以上能力所需具体转码方式，转码方式包括对数据转换方式，如算法、密钥长度等。为简化 IPSec 的使用和管理， IPSec 还可以通过 IKE 进行自动协商交换密钥、建立和维护安全联盟的服务。具体介绍如下：
  • AH协议：AH是报文头验证协议，主要提供数据源验证、数据完整性验证和防报文重放功能，不提供加密功能。
  • ESP协议：ESP是封装安全载荷协议，主要提供加密、数据源验证、数据完整性验证和防报文重放功能。
  • IKE协议：IKE协议建立在Internet安全联盟和密钥管理协议ISAKMP（Internet Security Association and Key Management Protocol）框架之上，采用DH（Diffie-Hellman）算法在不安全的网络上安全地分发密钥、验证身份，以保证数据传输的安全性。IKE协议可提升密钥的安全性，并降低IPSec管理复杂度。

 

IPSec安全协议 – AH

• 提供数据源验证（真实性）、完整性校验和抗重放
• 不提供数据加密功能
• AH用IP协议号51来标识

• AH是一种基于IP的传输层协议，协议号为51。
• AH的工作原理是在每一个数据包的标准IP报头后面添加一个AH报文头。AH对数据包和认证密钥进行Hash计算，接收方收到带有计算结果的数据包后，执行同样的Hash计算并与原计算结果比较，传输过程中对数据的任何更改将使计算结果无效，这样就提供了数据来源认证和数据完整性校验。AH协议的完整性验证范围为整个IP报文。
• AH 报文头字段含义如下：
  • 下一头部： 8 比特，标识 AH 报文头后面的负载类型。
    • 传输模式下，是被保护的上层协议（TCP或UDP）或ESP协议的编号；
    • 隧道模式下，是IP协议或ESP协议的编号。
  • 负载长度：8比特，表示以32比特为单位的AH头部长度减2，缺省为4。
  • 保留字段：16比特，保留将来使用，缺省为0。
  • 安全参数索引（SPI）：32比特，用于唯一标识IPSec安全联盟（IPSec SA）。
  • 序列号：32比特，是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放***。
  • 认证数据：一个变长字段，长度为32比特的整数倍，通常为96比特。该字段包含数据完整性校验值ICV（Integrity Check Value），用于接收方进行完整性校验。可选择的认证算法有MD5（Message Digest）、SHA-1（Secure Hash Algorithm）、SHA-2、SM3。前三个认证算法的安全性由低到高依次排列，安全性高的认证算法实现机制复杂，运算速度慢。SM3密码杂凑算法是中国国家密码管理局规定的IPSec协议规范。

 

IPSec安全协议 – ESP

• 提供数据真实性、数据完整性、抗重放、数据机密性
• ESP用IP协议号50来标识

 

• ESP的工作原理是在每一个数据包的标准IP报头后面添加一个ESP报文头，并在数据包后面追加一个ESP尾（ESP Tail和ESP Auth data）。与AH不同的是，ESP将数据中的有效载荷进行加密后再封装到数据包中，以保证数据的机密性，但ESP没有对IP头的内容进行保护。
• ESP 报文头字段含义如下：
  • 安全参数索引（SPI）：32比特，用于唯一标识IPSec安全联盟（IPSec SA）。
  • 序列号：32比特，是一个从1开始的单项递增的计数器，唯一地标识每一个数据包，用于防止重放***。
  • 负载数据：包含由下一头部字段给出的变长数据。
  • 填充字段：用于增加ESP包头的位数。填充字段的长度与负载数据的长度和算法有关。当待加密报文的明文长度不是加密算法所要求的块长度时，需要进行填充补齐。
  • 填充长度：8比特，给出前面填充字段的长度，置0时表示没有填充。
  • 下一头部： 8 比特，标识 ESP 头后面的下一个负载类型。
    • 传输模式下，是被保护的上层协议（TCP或UDP）的编号；
    • 隧道模式下，是IP协议的编号。
  • 认证数据：一个变长字段，长度为32比特的整数倍，通常为96比特。该字段包含数据完整性校验值ICV，用于接收方进行完整性校验。ESP的验证功能是可选的，如果启动了数据包验证，会在加密数据的尾部添加一个ICV数值。

 

IPSec协议封装模式

• 封装模式是指将 AH 或 ESP 相关的字段插入到原始 IP 报文中，以实现对报文的认证和加密。 IPSec 协议有两种封装模式：传输模式和隧道模式。
  • 传输模式：在传输模式中，AH头或ESP头被插入到IP头与传输层协议头之间，保护TCP/UDP/ICMP负载。传输模式不改变报文头，故隧道的源和目的地址必须与IP报文头中的源和目的地址一致，所以只适合两台主机或一台主机和一台***网关之间通信。
  • 隧道模式：与传输模式不同，在隧道模式下，AH头或ESP头被插到原始IP头之前，另外生成一个新的报文头放到AH头或ESP头之前，保护IP头和负载。隧道模式主要应用于两台***网关之间或一台主机与一台***网关之间的通信。

 

传输模式报文封装

 

• 在传输模式下，以TCP报文为例，原始报文经过传输模式封装后，报文格式如上图所示。
• 传输模式下
  • AH协议的完整性验证范围为整个IP报文。
  • ESP 协议
    • 验证报文的完整性检查部分包括ESP头、传输层协议头、数据和ESP报尾，但不包括IP头，因此ESP协议无法保证IP头的安全。
    • 加密部分包括传输层协议头、数据和ESP报尾。

 

隧道模式报文封装

• 在隧道模式下，以TCP报文为例，原始报文经过隧道模式封装后，报文格式如上图所示。
• 隧道模式下，
  • AH协议的完整性验证范围为包括新增IP头在内的整个IP报文。
  • ESP 协议
    • 加密部分包括源IP头、传输层协议头、数据和ESP报尾。
    • ESP协议验证报文的完整性检查部分包括ESP包头、原IP头、传输层协议头、数据和ESP报尾，但不包括新IP头，因此ESP协议无法保证新IP头的安全。
• 当安全协议同时采用AH和ESP时，AH采用封装模式为传输模式。

 

IPSec协议封装模式对比

IKE介绍

• 因特网密钥交换IKE（Internet Key Exchange）协议建立在Internet安全联盟和密钥管理协议ISAKMP定义的框架上，是基于UDP（User Datagram Protocol）的应用层协议。它为IPSec提供了自动协商密钥、建立IPSec安全联盟的服务，能够简化IPSec的使用和管理，大大简化IPSec的配置和维护工作。
• 用IPSec保护一个IP包之前，必须先建立一个安全联盟（SA）。IPSec的安全联盟可以通过手工配置的方式建立。但是当网络中节点较多时，手工配置将非常困难，而且难以保证安全性。这时就可以使用IKE（Internet Key Exchange）自动进行安全联盟建立与密钥交换的过程。Internet密钥交换（IKE）就用于动态建立SA，代表IPSec对SA进行协商。
• 密钥管理协议ISAKMP定义了消息交换的体系结构，包括两个IPSec对等体间分组形式和状态转变（定义封装格式和协商包交换的方式）。

 

IKE与IPSec的关系

• IKE是UDP之上的一个应用层协议，是IPSec的信令协议。
• IKE 与 IPSec 的关系如上图所示：
  • 对等体之间先建立一个IKE SA完成身份验证和密钥信息交换
  • 在IKE SA的保护下，根据配置的AH/ESP安全协议等参数协商出一对IPSec SA。此后，对等体间的数据将在IPSec隧道中加密传输。

 

安全联盟

• IPSec安全传输数据的前提是在IPSec对等体（即IPSec协议的两个端点）之间成功建立安全联盟SA（Security Association）。SA是通信的IPSec对等体间对某些要素的约定。IPSec安全联盟简称IPSec SA。
• SA由一个三元组来唯一标识，这个三元组包括安全参数索引SPI（Security Parameter Index）、目的IP地址和使用的安全协议号（AH或ESP）。其中，SPI是用于唯一标识SA的一个32比特数值，它在AH和ESP头中传输。在手工配置SA时，需要手工指定SPI的取值。使用IKE协商产生SA时，SPI将随机生成。
• 安全联盟是单向的，在两个对等体之间的双向通信，最少需要两个安全联盟来分别对两个方向的数据流进行安全保护。另外，SA的个数还与安全协议相关。如果您只使用AH或ESP来保护两个对等体之间的流量，则对等体之间就有两个SA，每个方向上一个。如果对等体同时使用了AH和ESP，那么对等体之间就需要四个SA，每个方向上两个，分别对应AH和ESP。
• 建立 IPSec SA 的方式：手工方式和 IKE 自动协商方式。二者的主要区别为：
  • 密钥生成方式不同：手工方式下，建立SA所需的全部参数，包括加密、验证密钥，都需要用户手工配置，也只能手工刷新，在中大型网络中，这种方式的密钥管理成本很高；IKE方式下，建立SA需要的加密、验证密钥是通过DH算法生成的，可以动态刷新，因而密钥管理成本低，且安全性较高。
  • 生存周期不同：手工方式建立的SA，一经建立永久存在；IKE方式建立的SA，其生存周期由双方配置的生存周期参数控制。

 

IKE的安全机制

• IKE具有一套自保护机制，可以在不安全的网络上安全地认证身份、分发密钥、建立IPSec SA：
• 身份认证：身份认证确认通信双方的身份（对等体的IP地址或名称）。
• 身份保护：通信双方的身份数据在密钥产生之后加密传送，实现了对身份数据的保护。
• DH（Diffie-Hellman）密钥交换算法：通信双方通过交换密钥材料来计算共享的密钥，即使第三方截获了双方用于计算密钥的所有交换数据，也无法计算出真正的密钥。
• 完善的前向安全性PFS（Perfect Forward Secrecy）：PFS是一种安全特性，指一个密钥被破解，并不影响其他密钥的安全性，因为这些密钥间没有派生关系。PFS是由DH算法保障的。

 

IKE的安全机制 – 身份认证

• 身份认证确认通信双方的身份（对等体的 IP 地址或名称），包括预共享密钥 PSK （pre-shared key）认证、数字证书RSA（rsa-signature）认证和数字信封认证 。
  • 在预共享密钥认证中，认证字作为一个输入来产生密钥，通信双方采用共享的密钥对报文进行Hash计算，判断双方的计算结果是否相同。如果相同，则认证通过；否则认证失败。（理解：使用输入的共享秘钥作为材料，采用对称加密算法产生秘钥，对秘钥进行哈希计算，将计算结果传送给对端。对端使用相同的方法得到哈希值，进行比较。）
  • 在数字证书认证中，通信双方使用CA证书进行数字证书合法性验证，双方各有自己的公钥（网络上传输）和私钥（自己持有）。发送方对原始报文进行Hash计算，并用自己的私钥对报文计算结果进行加密，生成数字签名。接收方使用发送方的公钥对数字签名进行解密，并对报文进行Hash计算，判断计算结果与解密后的结果是否相同。如果相同，则认证通过；否则认证失败。
  • 在数字信封认证中，发送方首先随机产生一个对称密钥，使用接收方的公钥对此对称密钥进行加密（被公钥加密的对称密钥称为数字信封），发送方用对称密钥加密报文，同时用自己的私钥生成数字签名。接收方用自己的私钥解密数字信封得到对称密钥，再用对称密钥解密报文，同时根据发送方的公钥对数字签名进行解密，验证发送方的数字签名是否正确。如果正确，则认证通过；否则认证失败。
• 对于预共享密钥认证方法，当有1个对等体对应多个对等体时，需要为每个对等体配置预共享的密钥。该方法在小型网络中容易建立，但安全性较低。使用数字证书安全性高，但需要CA来颁发数字证书，适合在大型网络中使用。而数字信封认证用于设备需要符合国家密码管理局要求时使用，此认证方法只能在IKEv1的主模式协商过程中支持。
• IKE支持的认证算法有：MD5、SHA-1、SHA2-256、SHA2-384、SHA2-512、AES-XCBC-MAC-96、SM3。

 

IKE的安全机制 – 身份保护

• 身份数据在密钥产生之后加密传送，实现了对身份数据的保护。
• 支持的加密算法有：
  • DES ( 56bità64bit )
  • 3DES( 3个 56bit à64bit )
  • AES (128、192、256)
  • 国密算法SM1、SM4

 

IKE的安全机制 – DH (Diffie-Hellman) 密钥交换算法

• 发起方和响应方利用 ISAKMP消息 的 Key Exchange 和 nonce 载荷交换彼此的密钥材料。
  • Key Exchange用于交换DH公开值。
  • nonce用于传送临时随机数。
• 由于DH算法中IKE Peer双方只交换密钥材料，并不交换真正的共享密钥，即使***窃取了DH值和临时值也无法计算出共享密钥，这一点正是DH算法的精髓所在。从抓包中可以看到IKE Peer双方交换密钥材料，以消息3为例：

• DH被称为公共密钥交换方法，它用于产生密钥材料，并通过ISAKMP消息在发送和接收设备之间进行密钥材料交换。然后，两端设备各自计算出完全相同的对称密钥。该对称密钥用于计算加密和验证的密钥。在任何时候，通信双方都不交换真正的密钥。DH密钥交换是IKE的精髓所在。但DH没有提供双方身份的任何信息，不能确定交换的数据是否发送给合法方，第三方可以通过截获的数据与通信双方都协商密钥、共享通信，从而获取和传递信息，所以，IKE还需要身份认证来对对等体身份进行认证。

 

DH (Diffie-Hellman) 密钥交换算法

• 两个对等体使用DH算法，通过两条ISAKMP消息交换与密钥相关的信息。然后，结合自身的身份验证方法,各自开始密钥计算过程（预共享密钥或数字证书都会参与到密钥计算过程中）如上图所示，最终生成相关密钥：
  • SKEYID：SKEYID为基础密钥，通过它可以推导出SKEYID_a、SKEYID_e、SKEYID_d；
  • SKEYID_a：ISAKMP消息完整性验证密钥；
  • SKEYID_e：ISAKMP消息加密密钥；

  以上两个密钥保证了后续交换的ISAKMP消息的安全性。

  • SKEYID_d：用于衍生出IPSec报文加密和验证密钥，最终是由这个密钥保证IPSec封装的数据报文的安全性。
  • 整个密钥交换和计算过程在IKE SA超时时间的控制下以一定的周期进行自动刷新，避免了密钥长期不变带来的安全隐患。
• MD5、SHA-1、DES、3DES、AES等算法都可以采用DH算法来共享对称密钥。
• DH使用密钥组定义自己产生的密钥长度。密钥组长度越长，产生的密钥就越强壮。

 

IKE的安全机制 – 完美的前向安全性PFS

• 短暂的一次性密钥系统称为"完美向前保密"(Perfect Forward Secrecy，PFS)。
• 如果加密系统中有一个秘钥是所有对称密钥的衍生者（始祖），便不能认为那是一个"完美向前保密"的系统。在这种情况下，一旦破解了根密钥，便能拿到其它衍生的所有密钥，受那些密钥保护的全部数据都会曝光。
• 在IPSec里，PFS是通过在IPSec SA协商阶段重新进行一次DH交换来实现的。

 

IKE协商

• IKE协议分IKEv1和IKEv2两个版本。
• IKEv1
  • IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA。
    • 第一阶段，通信双方协商和建立IKE本身使用的安全通道，建立一个IKE SA。
    • 第二阶段，利用这个已通过了认证和安全保护的安全通道，建立一对IPSec SA。
• IKEv2
  • IKEv2则简化了协商过程。
  • 在一次协商中可直接产生IPSec的密钥，生成IPSec SA。
• IKE协议分IKEv1和IKEv2两个版本。IKEv2与IKEv1相比有以下优点：
  • 简化了安全联盟的协商过程，提高了协商效率。

  IKEv1使用两个阶段为IPSec进行密钥协商并建立IPSec SA：第一阶段，通信双方协商和建立IKE本身使用的安全通道，建立一个IKE SA；第二阶段，利用这个已通过了认证和安全保护的安全通道，建立一对IPSec SA。IKEv2则简化了协商过程，在一次协商中可直接生成IPSec的密钥并建立IPSec SA。

  • 修复了多处公认的密码学方面的安全漏洞，提高了安全性能。
  • 加入对EAP（Extensible Authentication Protocol）身份认证方式的支持，提高了认证方式的灵活性和可扩展性。

 

IKEv1协商的两个阶段

• 采用IKEv1协商安全联盟主要分为两个阶段：
  • 第一阶段，通信双方协商和建立IKE协议本身使用的安全通道，即建立一个IKE SA；
  • 第二阶段，利用第一阶段已通过认证和安全保护的安全通道，建立一对用于数据安全传输的IPSec安全联盟。
• IKEv1协商阶段1的目的是建立IKE SA。IKE SA建立后对等体间的所有ISAKMP消息都将通过加密和验证，这条安全通道可以保证IKEv1阶段2的协商能够安全进行。
• 两个对等体间只建立一个IKE SA，它是一个双向逻辑连接。
• IKEv1协商阶段1支持两种协商模式：
  • 主模式（Main Mode）
  • 野蛮模式（Aggressive Mode）
• IKEv1协商阶段2的目的就是建立用来安全传输数据的IPSec SA，并为数据传输衍生出密钥。
• IKEv1协商阶段2采用快速模式（Quick Mode）。该模式使用IKEv1协商阶段1中生成的密钥SKEYID_a对ISAKMP消息的完整性和身份进行验证，使用密钥SKEYID_e对ISAKMP消息进行加密，故保证了交换的安全性。
• 在快速模式中，对等体两端协商IPSec SA的各项参数，并为数据传输衍生出密钥。

 

主模式和野蛮模式协商过程图

• 主模式包含三次双向交换，用到了六条ISAKMP信息，协商过程如图左所示。这三次交换分别是：
• 消息①和②用于协商对等体之间使用的IKE安全提议。
  • 发起方发送一个或多个IKE安全提议（IKE协商过程中用到的加密算法、认证算法、Diffie-Hellman组及认证方法等）。
  • 响应方对发起方的IKE安全提议进行协商。在协商时将从优先级最高的提议开始匹配，协商双方必须至少有一条匹配的IKE安全提议才能协商成功。匹配的原则为协商双方具有相同的加密算法、认证算法、认证方法和Diffie-Hellman组标识。
  • 响应方响应ISAKMP消息，携带经协商匹配的安全提议及参数。 如果没有匹配的安全提议，响应方将拒绝发起方的安全提议。
• 消息③和④使用DH算法交换与密钥相关的信息，并生成密钥。
  • 双方交换Diffie-Hellman公共值和nonce值，并产生IKE SA的认证和加密密钥（请参考前面的DH密钥交换算法）。
• 消息⑤和⑥用于身份和认证信息交换（双方使用生成的密钥发送信息），双方进行身份认证（预共享密钥方式下为IP地址或名称，数字证书方式下还需要传输证书的内容）和对整个主模式交换内容的认证。
• 野蛮模式只用到三条信息，前两条消息①和②用于协商IKE安全提议，交换Diffie-Hellman公共值、必需的辅助信息以及身份信息，并且消息②中还包括响应方发送身份信息供发起方认证，消息③用于响应方认证发起方。

 

主模式和野蛮模式的区别

• 交换的消息：
  • 主模式为6个，野蛮模式为3个。
• 身份保护：
  • 主模式的最后两条消息有加密，可以提供身份保护功能；而野蛮模式消息集成度过高，因此无身份保护功能
• 对等体标识：
  • 主模式只能采用IP地址方式标识对等体；而野蛮模式可以采用IP地址方式或者Name方式标识对等体。

 

快速模式协商过程图

• 快速模式中，双方需要协商生成 IPSec SA 各项参数（包含可选参数 PFS ），并为 IPSec SA 生成认证 / 加密密钥。 IKEv1 协商阶段 2 通过三条 ISAKMP 消息完成双方 IPSec SA 的建立，如上图所示：
  • 消息1：协商发起方发送本端的安全参数和身份认证信息。

  安全参数包括被保护的数据流和IPSec安全提议等需要协商的参数。IPSec安全提议指IPSec协商过程中用到的安全协议、加密算法及认证算法等。身份认证信息包括第一阶段计算出的密钥和第二阶段产生的密钥材料等，可以再次认证对等体。

  • 消息2：协商响应方发送确认的安全参数和身份认证信息并生成新的密钥。

  IPSec SA数据传输需要的加密、验证密钥由第一阶段产生的密钥、SPI、协议等参数衍生得出，以保证每个IPSec SA都有自己独一无二的密钥。

  如果启用PFS，则需要再次应用DH算法计算出一个共享密钥，然后参与上述计算，因此在参数协商时要为PFS协商DH密钥组。

  • 消息3：发送方发送确认信息，确认与响应方可以通信，协商结束。

 

IKEv2密钥协商和交换

• IKEv2中所有消息都以"请求-响应"的形式成对出现，响应方都要对发起方发送的消息进行确认，如果在规定的时间内没有收到确认报文，发起方需要对报文进行重传处理，提高了安全性。
• 采用IKEv2协商安全联盟比IKEv1协商过程要简化的多。要建立一对IPSec SA，IKEv1需要经历两个阶段："主模式＋快速模式"或者"野蛮模式＋快速模式"，前者至少需要交换9条消息，后者也至少需要6条消息。而IKEv2 正常情况使用2次交换共4条消息就可以完成一对IPSec SA的建立，如果要求建立的IPSec SA大于一对时，每一对IPSec SA只需额外增加1次创建子SA交换，也就是2条消息就可以完成。
• IKEv2定义了三种交换：初始交换（Initial Exchanges）、创建子SA交换（Create_Child_SA Exchange）以及通知交换（Informational Exchange）。

 

IKEv2初始交换过程图

• IKEv2通过初始交换就可以完成一个IKE SA和第一对IPSec SA的协商建立。如果要求建立的IPSec SA大于一对时，每一对SA值只需要额外增加一次创建子SA交换（IKEv1仍然需要经历两个阶段）。
• IKEv2 初始交换对应 IKEv1 的第一阶段，初始交换包含两次交换四条消息，如图所示。
  • 消息①和②属于第一次交换（称为IKE_SA_INIT交换），以明文方式完成IKE SA的参数协商，包括协商加密和验证算法，交换临时随机数和DH交换。IKE_SA_INIT交换后生成一个共享密钥材料，通过这个共享密钥材料可以衍生出IPSec SA的所有密钥。
  • 消息③和④属于第二次交换（称为IKE_AUTH交换），以加密方式完成身份认证、对前两条信息的认证和IPSec SA的参数协商。
• 创建子SA交换包含两条消息，用于一个IKE SA创建多个IPSec SA或IKE的重协商，对应IKEv1的第二阶段。该交换必须在初始交换完成后进行，交换消息由初始交换协商的密钥进行保护。如果启用PFS，创建子SA交换需要额外进行一次DH交换，生成新的密钥材料。生成密钥材料后，子SA的所有密钥都从这个密钥材料衍生出来。该交换的发起者可以是初始交换的协商发起方，也可以是初始交换的协商响应方。

 

IKEv2通知交换过程图

• 通知交换如图所示，运行IKE协商的两端有时会传递一些控制信息，例如错误信息或者通告信息，这些信息在IKEv2中是通过通知交换完成的。
• 通知交换必须在IKE SA保护下进行，也就是说通知交换只能发生在初始交换之后。控制信息可能是IKE SA的，那么通知交换必须由该IKE SA来保护进行；也可能是某子SA的，那么该通知交换必须由生成该子SA的IKE SA来保护进行。

 

IPSec ***部署逻辑顺序

• 配置高级ACL：手工方式和IKE自动协商方式建立的IPSec隧道都可以通过ACL来指定要保护的数据流范围，在对等体间镜像配置ACL，筛选出需要进入IPSec隧道的报文，ACL规则允许（permit）的报文将被保护，没有被允许（permit）的报文将不被保护。这种方式可以利用ACL的丰富配置功能，根据IP地址、端口、协议类型等对报文进行过滤进而灵活制定IPSec的保护方法。
• 配置IKE安全提议：IKE安全提议是IKE对等体的一个组成部分，定义了对等体进行IKE协商时使用的参数，包括认证方法、认证算法、加密算法、DH组和IKE安全联盟的生存周期。
• 配置IKE对等体：配置IKE动态协商方式建立IPSec隧道时，需要引用IKE对等体，并配置IKE协商时对等体间的一系列属性。
• 配置IPSec安全提议：IPSec安全提议是IPSec安全策略或者安全框架的一个组成部分，它包括IPSec使用的安全协议、认证/加密算法以及数据的封装模式，定义了IPSec的保护方法，为IPSec协商SA提供各种安全参数。IPSec隧道两端设备需要配置相同的安全参数。
• 配置IPSec安全策略：IPSec安全策略是创建SA的前提，它规定了对哪些数据流采用哪种保护方法。配置IPSec安全策略时，通过引用ACL和IPSec安全提议，将ACL定义的数据流和IPSec安全提议定义的保护方法关联起来，并可以指定SA的协商方式、IPSec隧道的起点和终点、所需要的密钥和SA的生存周期等。
• 应用IPSec安全策略：为使接口能对数据流进行IPSec保护，需要在该接口上应用一个IPSec安全策略组。当取消IPSec安全策略组在接口上的应用后，此接口便不再具有IPSec的保护功能。

 

IPSec ***应用场景分析

 

IPSec点到点应用场景

• 点到点***也称为局域网到局域网***，网关到网关***，主要用于两个网关之间建立IPSec隧道，从而实现局域网之间安全地互访。
• 点到点***两端网关必须提供固定的IP地址或固定的域名。通信双方都可以主动发起连接。

• 以上场景中组网需求如下：
  • PC1与PC2之间进行安全通信，在FW_A与FW_B之间使用IKE自动协商建立安全通道。
  • 为使用pre-shared key验证方法的提议配置验证字。
  • FW_A与FW_B均为固定公网地址。
• 两个网络的公网IP地址固定不变，且两个网络之间要互相访问，可建立IKE协商的点到点方式的IPSec隧道，使两个网络中的设备都可以主动发起连接。
• 点到点应用场景作为IPSec ***中最典型的场景，将在本小节中为大家做详细讲解。

 

IPSec *** Web配置流程

• IPSec的配置使用命令行和在Web界面下进行配置有较大的差别，在Web配置界面下，配置项做了很多简化，同时对于各种场景也做了集成，在面对不同场景需求的时候，使得配置更加简略。

 

数据规划

 

配置基本信息

• 配置 FW_A 的 IPSEC 隧道， FW_B 与 FW_A 配置类似：
  • 选择"网络 > IPSec > IPSec"。单击"新建"，建立一条IPSec安全策略。选择"场景"为"点到点"。
  • 配置IPSec策略名称及本端接口信息。如上图所示。
  • 选择认证方式为预共享密钥，设置预共享密钥为huawei。
  • 选择IKE peer中本端端口IP信息。如上图所示。

 

配置保护的数据流

• 在"待加密的数据流"中单击"新建"，按如下参数新增一条数据流规则，定义两端的私网网段地址为待加密数据流报文。

 

 

配置IKE安全提议

• 展开"安全提议"中的"高级"，配置IKE和IPSec协商参数。首先，配置IKE参数，此处可直接采用默认值配置，具体如下所示：

 

配置IPSec安全提议

• 配置IPSEC参数，此处可直接采用默认值配置，具体如下所示：

 

配置验证

 

查看IKE SA

• display ike sa命令可以查看到的信息包括：安全联盟的连接索引、安全联盟的对端IP地址、***实例名称、SA所属阶段、此安全联盟的状态。
• 分别在FW_A和FW_B上执行display ike sa会显示IKE安全联盟的建立情况。以FW_B为例，出现以上显示说明IKE安全联盟建立成功。

 

查看IPSec SA

• 分别在FW_A和FW_B上执行display ipsec sa会显示IPSec安全联盟的建立情况。以FW_B为例，出现以上显示说明IPSec安全联盟建立成功。

FW_A的配置脚本

 

#定义被保护的数据流。配置高级ACL 3000，允许10.1.1.0/24网段访问10.1.2.0/24网段。

acl number 3000

rule permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255

 

#配置IKE安全提议，缺省参数可不配置。

ike proposal 1

encryption-algorithm aes-256

dh group2 //配置IKE密钥协商时采用的DH密钥交换参数，缺省参数为group14。

authentication-algorithm sha2-256

authentication-method pre-share

integrity-algorithm hmac-sha2-256

prf hmac-sha2-256

 

#配置IKE对等体，缺省参数可不配置。

ike peer ike6117323732

pre-shared-key Huawei //配置预共享密钥为huawei。

ike-proposal 1 //引用前面已创建的IKE安全提议。

remote-id-type ip

remote-address 1.1.5.1

 

#配置IPSec安全提议，缺省参数可不配置。

ipsec proposal prop6117323732

esp authentication-algorithm sha2-256

esp encryption-algorithm aes-256

 

#配置IPSec安全策略，引用已创建的ACL、IPSec安全提议、IKE对等体。

ipsec policy ipsec6117323788 1 isakmp

security acl 3000

ike-peer ike6117323732

proposal prop6117323732

tunnel local 1.1.3.1

#

 

interface GigabitEthernet1/0/3

ip address 10.1.1.1 255.255.255.0

 

#在FW_A的外网出接口上引用已创建的IPSec安全策略。

interface GigabitEthernet1/0/1

ip address 1.1.3.1 255.255.255.0

ipsec policy ipsec6117323788

 

#将接口GE1/0/3加入Trust区域。

firewall zone trust

set priority 85

add interface GigabitEthernet1/0/3

 

#将接口GE1/0/1加入Untrust区域。

firewall zone untrust

set priority 5

add interface GigabitEthernet1/0/1

 

#配置到达对端10.1.2.0/24的路由。FW_A通往FW_B侧的下一跳设备的IP地址为1.1.3.2。

ip route-static 10.1.2.0 255.255.255.0 1.1.3.2

#

 

#

security-policy

rule name policy_ipsec_1

//配置从Trust到Untrust的域间策略，允许分支访问总部的报文通过。

source-zone trust

destination-zone untrust

source-address 10.1.1.0 24

destination-address 10.1.2.0 24

action permit

 

rule name policy_ipsec_2

//配置从Untrust到Trust的域间策略，允许总部访问分支的报文通过。

source-zone untrust

destination-zone trust

source-address 10.1.2.0 24

destination-address 10.1.1.0 24

action permit

 

rule name policy_ipsec_3

//配置从Untrust到Local的域间策略，允许总部到分支的ISAKMP协商报文、ESP报文通过。

source-zone untrust

destination-zone local

source-address 1.1.5.1 32

destination-address 1.1.3.1 32

action permit

 

rule name policy_ipsec_4

//配置从Local到Untrust的域间策略，允许分支到总部的ISAKMP协商报文通过。

source-zone local

destination-zone untrust

source-address 1.1.3.1 32

destination-address 1.1.5.1 32

action permit

FW_B的配置脚本与FW_A的配置脚本是对称的，在此不再进行详述。

 

IPSec 点到多点应用场景

 

多个分支机构与总部建立IPSec

• 业务需求：
  • 某公司总部与多个分支机构想要通过IPSec ***互通。总部的IP地址为固定公网IP地址，部分分支的IP地址为静态公网IP，也有部分是内网IP或动态公网IP。

 

组网方案：IPSec点到多点应用场景

• 点到多点多用于一个总部与多个分支建立IPSec的场景。在实际的应用中，经常需要使用HUB-Spoke类型的组网，即一个总部到多个分支机构的组网，分支节点建立到总部的IPSec隧道，各个分支机构之间的通信由总部节点转发和控制。

• 在此种场景下，网络内数据流量可能存在如下几种情况：
  • 各分支机构之间不需要通信

    此时只需要在总部和分支之间部署IPSec ***。

    • 各分支机构之间需要通信

    此时，若分支采用动态的公网地址接入Internet时，部署传统的IPSec ***将存在一个问题，即分支与分支间无法直接通信，所有分支与分支间的通信数据只能由总部中转。而总部在中转分支间的通信流量时会消耗Hub的CPU及内存资源，造成资源紧张；另外，总部要对分支间的流量进行封装和解封装，会引入额外的网络延时。

 

配置思路 (总部防火墙)

• 以上列出的配置思路中，重点在于点到多点场景的选择，而只有总部防火墙在配置时，需要将场景选择为"点到多点"，对于分支防火墙（如FW_B、FW_C），仍然按照"点到点"场景的配置模式完成配置，在此方案中，将FW_B和FW_C的配置省略。

 

关键配置：IPSec基本配置 (FW_A)

• 在本场景中，选择使用预共享密钥方式进行认证。预共享密钥设置为Test@123。
• 选择"网络 > IPSec > IPSec"，单击"新建"，参数配置如上图所示。

 

关键配置：感兴趣数据流 (FW_A)

• 安全提议使用缺省参数。

• 安全提议使用缺省参数。如果想要修改某个参数，展开"安全提议"中的"高级"进行设置，隧道两端所使用的安全提议配置必须相同。
• 单击IPSec策略配置中的"应用"。完成FW_A的配置。
• 对于其他两个分支的配置，请参考"点到点"场景中的配置。

 

GRE Over IPSec应用场景

• 组播业务的安全传输
• 业务需求：
• 某公司运行了组播业务，在两个分支之间需要进行业务传输，目前使用GRE隧道来完成这一需求，但GRE隧道安全性较低，管理员希望能用更高安全性的方法传输业务数据。

• 当需要在IPSec ***上传输组播、广播和非IP报文时，如在总部和分支之间开视频会议等组播业务，可以采用GRE over IPSec。GRE over IPSec利用了GRE和IPSec的优势，利用GRE将组播、广播和非IP报文封装成普通的IP报文，通过IPSec将封装后的IP报文安全地传输。

 

组网方案：GRE Over IPSec应用场景

• GRE是常用的隧道封装协议，可以很好的实现对于组播、广播和非IP报文的数据承载，但是GRE只有简单的密码验证，没有加密功能，数据传输安全性较低。 IPSec虽具备很高的数据安全传输能力，但其本身不支持封装组播、广播和非IP报文。当需要在IPSec ***上传输组播、广播和非IP报文时，如在总部和分支之间开视频会议等组播业务，可以采用GRE over IPSec。GRE over IPSec利用了GRE和IPSec的优势，利用GRE将组播、广播和非IP报文封装成普通的IP报文，通过IPSec将封装后的IP报文安全地传输。
• GRE over IPSec使用的封装模式为可以是隧道模式也可以是传输模式。因为隧道模式跟传输模式相比多增加了IPSec头，导致报文长度更长，更容易导致分片。所以推荐采用传输模式GRE over IPSec。

 

GRE Over IPSec配置思路 (CLI)

• 配置GRE Over IPSec时，推荐使用命令行的方式进行配置。
• IPSec安全框架定义了对数据流的保护方法，如使用的IPSec安全提议、用于自动协商SA所需要的IKE协商参数、SA的生存周期以及PFS特性。一个IPSec安全框架相当于一个IPSec安全策略，与IPSec安全策略不同的是，安全框架由名称唯一确定，且只能通过IKE协商方式配置。
• IPSec安全框架无需通过ACL定义数据流，而是保护所有路由到IPSec虚拟隧道接口的数据流。在IPSec虚拟隧道接口下应用IPSec安全框架后只会生成一条IPSec隧道，并对所有路由到该隧道接口的数据流进行IPSec保护，简化了安全策略管理的复杂度。
• 为保证IKE协商成功，安全框架中所有配置的参数必须在本端和对端相匹配。

 

关键配置

 

IPSec ***故障排除

 

IPSec诊断工具与方法 – Web诊断

 

IPSec诊断工具与方法 – CLI诊断命令

• 如果能同时查看到完整的IKE SA及IPSec SA信息，则表示IPSec隧道建立成功。

 

IPSec ***故障总体处理思路

• IPSec 故障分析可以按照故障出现的先后顺序从以下几个现象入手：
  • 配置阶段：IPSec配置界面不可见。
  • 业务触发阶段：没有数据流触发IKE协商。
  • IKE协商阶段：IKE协商不成功（IKE SA、IPSec SA协商不成功）。
  • 数据传输阶段：IKE协商成功，但***业务异常（不通或质量不好）。
• 其中IKE协商不成功是IPSec故障的核心问题，可以结合IKE协商过程进行深入分析；其它故障仅表现为IPSec业务故障，根因皆为NGFW基本特性的错误配置，如license、接口、链路、路由、安全区域、NAT等，需要结合具体场景来处理。

 

没有数据流触发IKE协商

 

IKE SA协商不成功

 

IPSec SA协商不成功

 

案例一：故障现象

• 在两台FW之间建立IPSec隧道。组网如上图所示。在修改参数之前，隧道能够建立成功。当在FW_B的公网接口增加了sub地址并修改某些配置后，发现隧道建立不成功。经检查，两端IPSec和IKE参数配置均正确。路由、接口、安全策略等配置也正确。

 

案例一：故障分析

• 本例中故障由配置sub地址引起，故猜测可能是本端的"对端网关"和对端的"本地地址"不匹配导致的，执行display ike peer命令观察到FW_A的RemoteAddr和FW_B的local-address不一致。

 

案例一：故障处理

 

案例一：问题总结

• 在配置IPSec安全策略时，local-address命令为可选配置。当本端发起IPSec隧道协商的IP地址与实际应用IPSec策略的接口IP地址不同时，需要配置local-address为本端发起协商的IP地址，且该地址需要和对端使用remote-address命令设置的目的地址一致。
• 本案例是由于FW_B指定了隧道本端地址为sub地址，引起对端的remote-address和本端的local-address不匹配导致IKE协商失败。

 

案例二：故障现象

• 在FW_A与FW_B之间建立点到点的IPSec ***。配置完成后，从PC1 ping PC2，无法ping通；从PC2 ping PC1，可以ping通，并正常建立隧道。经检查，各PC的IP地址、网关等基本配置无误；FW_A和FW_B的IP地址、路由、安全域和域间策略等基本配置都无误。

 

案例二：故障分析

 

案例二：故障处理与总结

• 隧道两端配成镜像并不是必要条件，IKEv1要求两端配置的ACL规则互为镜像或发起方配置的ACL规则为响应方的子集。IKEv2取双方ACL规则交集作为协商结果。
• 实际配置中建议将隧道两端的ACL规则配成互为镜像，即简单也不容易出错。

 

实验

点到点IPSec ***

FW1的配置，FW2反向配置

acl number 3000

rule 5 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.3.0 0.0.0.255

 

ike peer ike_fw2

pre-shared-key huawei@123

remote-address 1.1.5.1

 

[FW1]ipsec proposal ipsec_pro

 

ipsec policy policy_fw1 1 isakmp

security acl 3000

ike-peer ike_fw2

proposal ipsec_pro

 

interface GigabitEthernet1/0/0

undo shutdown

ip address 1.1.3.1 255.255.255.0

service-manage ping permit

ipsec policy policy_fw1

 

排错命令：

dis ike sa

dis ike sa verbose

dis ipsec sa

dis ipsec statistics

dis ike proposal

dis ike peer

dis ike peer brief

dis ipsec proposal

dis ipsec policy

dis firewall session table verbos

 

基于路由方式ipsec ***

需求：

使用IPSec ***基于路由方式，使PC1访问PC2

 

思路：

1. 创建Tunnel接口
2. 设置***路由,将流量引入Tunnel接口
3. 配置ike peer
4. 配置ipsec proposal，修改为传输模式
5. 配置ipsec profile
6. 在tunel接口中调用

 

步骤：SZ_***设置

1. 创建tunnel 0 接口

interface Tunnel0

ip address 10.1.1.1 255.255.255.0

 

1. 将tunnel 0 加入gre安全区域

firewall zone name gre id 4

set priority 10

add interface Tunnel0

 

1. 设置设置GRE ***

interface Tunnel0

ip address 10.1.1.1 255.255.255.0

tunnel-protocol gre

source 202.1.1.1

destination 101.1.1.1

 

1. 设置***路由

ip route-static 192.168.2.0 255.255.255.0 Tunnel0

 

1. 设置ike peer

ike peer ike-1

pre-shared-key Huawei@123

remote-address 101.1.1.1

 

1. 设置ipsec proposal，设置为传输模式

ipsec proposal ipsec-pro

encapsulation-mode transport

esp authentication-algorithm sha2-256

esp encryption-algorithm aes-256

 

1. 设置ipsec profile

ipsec profile profile1

ike-peer ike-1

proposal ipsec-pro

 

1. 在tunnel接口中调用

interface Tunnel0

ip address 10.1.1.1 255.255.255.0

tunnel-protocol gre

source 202.1.1.1

destination 101.1.1.1

ipsec profile profile1

 

 

IPSec点到多点应用场景

需求：

1. 深圳总部使用点到多点IPSec *** 连接广州分部，广州分部无固定IP

2. 深圳总部使用点到多点IPSec *** 连接北京分部，北京分部有固定IP

 

命令行：

广州分部使用动态IP地址，先设置北京分部，模拟器会出现问题

SZ_FW：深圳总部配置：

ike peer中没有设置remote-address，所以必须由广州分部先产生数据流，

深圳总部才能建立隧道

 

连接广州分部：

acl number 3000

rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.2.0 0.0.0.255

 

ike peer ike_sz

undo version 2

pre-shared-key huawei@123

 

ipsec proposal ipsec_pro_sz

 

ipsec policy-template ipsec_tem_sz 1

security acl 3000

ike-peer ike_sz

proposal ipsec_pro_sz

 

[SZ_FW]ipsec policy ipsec_pol_sz 1 isakmp template ipsec_tem_sz

//此命令，在调用北京分部之后再调用，不然IKE SA第二阶段无法创建

 

interface GigabitEthernet1/0/0

undo shutdown

ip address 202.1.1.1 255.255.255.0

service-manage ping permit

ipsec policy ipsec_pol_sz

广州分部和北京分部配置和前面普通配置一样。

 

连接北京分部，北京分部使用固定IP地址：

acl number 3001

rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.3.0 0.0.0.255

 

ike peer ike_bj

undo version 2

pre-shared-key huawei@123

remote-address 50.1.1.1

 

ipsec proposal ipsec_pro_sz

//经测试可以公用一个安全提议

 

ipsec policy ipsec_pol_sz 2 isakmp

security acl 3001

ike-peer ike_bj

proposal ipsec_bj

 

IPSec *** 和NAT组合案例：

 

 

 

北京的ipsec ***和nat在同一个设备上，深圳的 ipsec ***和nat不在同一设备上

需求：

PC1能够ping通PC2。

北京设置EASY-IP使内网能够访问外网。

 

思路：

1. 在NAT_FW设置nat server
2. 在SZ_FW_***中设置ipsec ***,隧道的源IP：172.16.12.1 目标IP：101.1.1.1
3. 在BJ_FW_***设置ipsec ***，隧道的源IP：101.1.1.1 目标IP：202.1.1.1
4. 设置安全策略

 

深圳

NAT_FW：

1. 设置NAT_Server：先放行所有协议，查看会话表之后再回来设置

nat server nat_isakmp protocol udp global interface GigabitEthernet1/0/1 500 in

side 172.16.12.1 500

nat server nat_esp protocol udp global interface GigabitEthernet1/0/1 4500 insi

de 172.16.12.1 4500

 

SZ_FW_***:

1. 设置ACL

acl number 3000

rule 5 permit ip source 192.168.1.0 0.0.0.255 destination 192.168.2.0 0.0.0.255

 

2. 配置ike peer：

ike peer ike_bj

undo version 2

pre-shared-key huawei@123

remote-address 101.1.1.1

 

3. 配置ipsec proposal

[SZ_FW_***]ipsec proposal ipsec_pro_sz

//使用默认配置

 

4. 配置ipsec policy

ipsec policy ipsec_pol_sz 1 isakmp

security acl 3000

ike-peer ike_bj

proposal ipsec_pro_sz

 

5. 在出接口上调用

interface GigabitEthernet1/0/1

undo shutdown

ip address 172.16.12.1 255.255.255.0

service-manage ping permit

ipsec policy ipsec_pol_sz

 

北京

BJ_FW_***：

1. 设置ACL

acl number 3000

rule 5 permit ip source 192.168.2.0 0.0.0.255 destination 192.168.1.0 0.0.0.255

 

2. 配置ike peer

ike peer ike_sz

undo version 2

pre-shared-key huawei@123

remote-address 202.1.1.1

//远端地址是202.1.1.1

 

3. 配置ipsec proposal

ipsec proposal ipsec_pro_bj

 

4.配置ipsec policy

ipsec policy ipsec_pol_bj 1 isakmp

security acl 3000

ike-peer ike_sz

proposal ipsec_pro_bj

 

5. 出接口调用

interface GigabitEthernet1/0/1

undo shutdown

ip address 101.1.1.1 255.255.255.0

service-manage ping permit

ipsec policy ipsec_pol_bj

 

6. 设置EASY-IP NAT 使北京内网能访问公网

nat-policy

rule name to_wan

source-zone trust

egress-interface GigabitEthernet1/0/1

source-address 192.168.2.0 mask 255.255.255.0

action source-nat easy-ip

 

以上代码会出现PC2无法ping通PC1的情况。造成此情况的原因是：源NAT策略的优先级高于

报文地址转换（ipsec ***），导致PC2-->PC1流量的源IP地址直接被源NAT转换了。

ipsec *** 无法抓取流量进行转换。解决办法如下：

 

rule name ipsec_***

source-zone trust

destination-zone untrust

source-address 192.168.2.0 mask 255.255.255.0

destination-address 192.168.1.0 mask 255.255.255.0

action no-nat

 

nat策略匹配规则是从上往下精确匹配，所以还需要调整ipsec_***的位置。

 

[BJ_FW_***-policy-nat]rule move ipsec_*** before to_wan

 

IPSec ***安全策略

需求：

使用IPSec *** 使PC1和PC2互访，配置相关防火墙的安全策略

 

思路：

1. 将防火漆的defaul安全策略设置为permit，配置ipsec ***使PC1和PC2能互访。（省略）

2. 关闭SZ_***的defaul安全策略，配置PC1-->PC2的安全策略

3. 关闭GZ_***的defaul安全策略，配置PC2-->PC1的安全策略

 

命令：

2. 配置PC1-->PC2的安全策略

security-policy

rule name ipsec_icmp

source-zone trust

destination-zone untrust

source-address 192.168.1.0 mask 255.255.255.0

destination-address 192.168.2.0 mask 255.255.255.0

service icmp

action permit

 

rule name ipsec_icmp_gz

source-zone local

source-zone untrust

destination-zone trust

source-address 192.168.2.0 mask 255.255.255.0

destination-address 192.168.1.0 mask 255.255.255.0

service icmp

action permit

 

rule name ipsec_esp_gz

source-zone untrust

destination-zone local

source-address 101.1.1.1 mask 255.255.255.255

destination-address 202.1.1.1 mask 255.255.255.255

service esp

action permit

 

rule name ipsec_isakmp

source-zone local

source-zone untrust

destination-zone local

destination-zone untrust

source-address 101.1.1.1 mask 255.255.255.255

source-address 202.1.1.1 mask 255.255.255.255

destination-address 101.1.1.1 mask 255.255.255.255

destination-address 202.1.1.1 mask 255.255.255.255

service protocol udp source-port 500 destination-port 500

action permit

 

原理分析：

1. PC1发出icmp报文，源IP：192.168.1.100目的IP：192.168.2.100

报文到达防火墙，防火墙查找路由表，匹配默认路由。得出区域：

trust-->untrust。将报文转到g1/0/0口，匹配ipsec ***，将源目

地址转换为202.1.1.1-->101.1.1.1，由于华为防火墙默认发出***

不需要安全策略，此安全策略可以省略。

2. PC2使用esp报文返回，源目IP：101.1.1.1-->202.1.1.1，到达防火墙查路

由表，区域为：untrust-->local

3. 由PC2发送icmp给PC1：

a. 此时报文类型为esp报文，源目IP：101.1.1.1-->202.1.1.1，匹配安全

策略ipsec_esp_gz，经过ipsec ***转换后查路由表发往接口g1/0/1。

b. 此时报文类型为icmp，源目IP：192.168.2.100-->192.168.1.100

由于经过ipsec ***解密等操作后防火墙重新封装的报文，所以源区域

为local，目标区域为trust。

4. 缺少isakmp的报文，无法连接。原理和上面第3点类似。