前面的文章中（IPsec：RFC2401-互联网协议的安全架构、IPsec小实验：手工方式建立保护IPv4报文的IPsec-ESP隧道、为什么IPsec两端内网的网段能不能重复？分明可以实现！、填坑：IPsec不同安全协议的报文封装结构对比、还能这么玩？Windows通过netsh命令配置IPsec、使用MMC和netsh两种方式配置Windows Server传输模式IPsec），我们用了很大篇幅来说明IPsec支持的两种封装模式：传输模式和隧道模式。
传输模式SA是两个主机之间的安全联盟。在ESP的情况下，传输模式SA仅为这些更高层协议提供安全服务，而不是为IP报文头或ESP报文头之前的任何扩展报文头提供安全服务。在AH的情况下，保护还扩展到IP报文头的指定部分、扩展报文头的指定部分和指定的选项。
隧道模式SA本质上是应用于IP隧道的SA。当SA的任一端是安全网关时，SA必须是隧道模式。因此，两个安全网关之间的SA始终是隧道模式SA，主机和安全网关之间的SA也是如此。
对于隧道模式SA，有一个“外部”IP报文头指定IPsec处理目的地，加上一个“内部”IP报文头，指定数据包的（表面）最终目的地。安全协议头出现在外部IP头之后，内部IP头之前。如果在隧道模式下使用AH，则外部IP报文头的部分将受到保护（如上所述），以及所有隧道传输的IP数据包（即，所有内部IP报文头都受到保护，以及更高层协议）。如果采用ESP，则仅对隧道数据包提供保护，而不对外部报文头提供保护。
总之，主机必须同时支持传输和隧道模式；要求安全网关仅支持隧道模式，如果安全网关支持传输模式，则应仅在安全网关充当主机时使用。
安全联盟SA的生成方式主要有以下几种：
1、手工方式。之前已经做过手工配置的实验，通过命令行配置SA的所有信息。该方式的配置比较复杂，而且不支持一些高级特性（例如定时更新密钥），优点是可以不依赖IKE而单独实现IPsec功能。该方式主要用于需要安全通信的对等体数量较少，或小型静态的组网环境中。
2、IKE自动协商方式。这将是本次实验的主要内容，对等体之间通过IKE协议自动协商生成SA，并由IKE协议维护该SA。该方式的配置相对比较简单，扩展能力强。在中、大型的动态网络环境中，推荐使用IKE自动协商建立SA。
3、量子加密方式。对等体之间利用从量子密钥服务器获取的量子密钥自动协商建立SA，由于量子密钥的不可预测性，使用该方式建立的SA拥有极高的安全性。额，这种方式不在我的考虑范围之内。
IKE（Internet Key Exchange，互联网密钥交换）协议利用ISAKMP（Internet Security Association and Key Management Protocol，互联网安全联盟和密钥管理协议）语言定义密钥交换的过程，是一种对安全服务进行协商的手段。IKE可实现密钥的自动协商功能，减少了密钥协商的开销。可以通过IKE建立和维护SA（Security Association，安全联盟），简化了IPsec的使用和管理
IKE的协议规范为RFC2409（IKE：互联网密钥交换），IKE为IPsec提供了自动协商建立IPsec SA的服务，具体有以下优点。
1、IKE首先会在通信双方之间协商建立一个安全通道（IKE SA），并在此安全通道的保护下协商建立IPsec SA，这降低了手工配置的复杂度，简化IPsec的配置和维护工作。
2、IKE的精髓在于DH（Diffie-Hellman）交换技术，它通过一系列的交换，使得通信双方最终计算出共享密钥。在IKE的DH交换过程中，每次计算和产生的结果都是不相关的。由于每次IKE SA的建立都运行了DH交换过程，因此就保证了每个通过IKE协商建立的IPsec SA所使用的密钥互不相关。
3、IPsec使用AH或ESP报文头中的顺序号实现防重放。此顺序号是一个32比特的值，此数溢出之前，为实现防重放，IPsec SA需要重新建立，IKE可以自动重协商IPsec SA。
为了贴近具体的SD-WAN使用场景，组网使用3台路由器。图中RTA为总部设备，RTB、RTC为分支设备，RTA和RTB、RTC之间分别建立IPsec隧道，对PCB所在的子网（10.1.1.0/24）与PCC所在的子网（10.1.2.0/24）之间的数据流进行安全保护。具体要求如下：
· 封装形式为隧道模式。
· 安全协议采用ESP协议。
· 加密算法采用128比特的AES，认证算法采用HMAC-SHA1。
· IKE协商方式建立IPsec SA。
采用IKE方式建立保护IPv4报文的IPsec隧道。
首先按照组网图所示配置各接口的IP地址，使得RTB和RTC可以互通。
配置一个IPv4高级ACL，定义要保护由子网10.1.1.0/24去往子网10.1.2.0/24的数据流。
#acl advanced 3401 rule 0 permit ip source 10.1.1.0 0.0.0.255 destination 10.1.2.0 0.0.0.255
配置到达PCC所在子网的静态路由。
#ip route-static 10.1.2.0 24 12.1.1.1
创建IPsec安全提议tran1，安全协议对IP报文的封装形式默认为隧道模式，采用的安全协议默认为ESP，无需调整。需要配置ESP协议采用的加密算法为128比特的AES，认证算法为HMAC-SHA1。
#ipsec transform-set tran1 esp encryption-algorithm aes-cbc-128 esp authentication-algorithm sha1
如果需要单独调整封装形式和安全协议，请使用以下命令：
#ipsec transform-set tran1 encapsulation-mode tunnel protocol esp
创建并配置IKE keychain，名称为key1。配置与IP地址为13.1.1.3的对端使用的预共享密钥为明文qwe123。
#ike keychain key1 pre-shared-key address 13.1.1.3 255.255.255.0 key simple qwe123
创建并配置IKE profile，名称为pro1。
#ike profile pro1 keychain key1 match remote identity address 13.1.1.3 255.255.255.0
创建一条IKE协商方式的IPsec安全策略，名称为map1，序列号为10。
指定引用ACL 3401，引用安全提议为tran1，引用的IKE profile为profile1。指定IPsec隧道的本端IP地址为12.1.1.2，对端IP地址为13.1.1.3。
#ipsec policy map1 10 isakmp transform-set tran1 security acl 3401 local-address 12.1.1.2 remote-address 13.1.1.3 ike-profile pro1
在接口G0/1上应用安全策略map1。
#interface GigabitEthernet0/1 ip address 12.1.1.2 255.255.255.0 ipsec apply policy map1
配置思路和RTB相同，主要是把对应的配置对称的变更过来即可，直接上配置：
#acl advanced 3401 rule 0 permit ip source 10.1.2.0 0.0.0.255 destination 10.1.1.0 0.0.0.255#ip route-static 10.1.1.0 24 13.1.1.1#ipsec transform-set tran1 esp encryption-algorithm aes-cbc-128 esp authentication-algorithm sha1#ike keychain key1 pre-shared-key address 12.1.1.2 255.255.255.0 key simple qwe123#ike profile pro1 keychain key1 match remote identity address 12.1.1.2 255.255.255.0#ipsec policy map1 10 isakmp transform-set tran1 security acl 3401 local-address 13.1.1.3 remote-address 12.1.1.2 ike-profile pro1#interface GigabitEthernet0/1 ip address 13.1.1.3 255.255.255.0 ipsec apply policy map1
以上配置完成后，使用10.1.1.2和10.1.2.2的互访流量来触发IKE进行IPsec SA的协商。IKE成功协商出IPsec SA后，子网10.1.1.0/24与子网10.1.2.0/24之间数据流的传输将受到IPsec SA的保护。
可通过命令查看到RTB的IKE提议信息。因为没有配置任何IKE提议，则只显示缺省的IKE提议。
可通过命令查看到RTB上IKE第一阶段协商成功后生成的IKE SA信息。
可以看到，DOI（IKE SA所属解释域）为IPsec，表示此IKE SA使用的DOI为IPsec DOI
如果带上verbose，可以看到更多的详细信息。比如RTB是发起者，本地和对端的端口号都是500，还有认证和加密算法，比较关键的，能看到1阶段的交换模式是主模式。
对应的，可以看到RTC为响应者，本地和对端的端口号都是500。
通过命令查看到协商生成的IPsec SA。
display ipsec sa
查看SA建立过程，抓包截图如下：
第一阶段使用公钥加密进行身份验证的过程如下，完全对的上。
打开第一个报文，有点熟悉啊。
可以看到跟之前的RFC3947（IKE中NAT-Traversal的协商）相呼应，IKE协商的第一步是检查两个IKE对等体之间是否存在NAT。你看，十六进制的值完全一致，HASH的是什么你还记得不？
第3个报文进行密钥交换，同时进行一系列的HASH计算。
到第5个报文，已经是加密的数据了。
按RFC2409介绍，第一阶段完成后，会进入第二阶段的快速模式，报文交互过程如下：
但是很不幸，因为已经全部是加密数据了，无法验证内容对不对，但是报文交互过程是没有问题的。
最后看一下IPsec加密的后的报文，有没有发现已经没有端口号了？那你猜这个报文是TCP报文还是UDP报文呢？
推荐本站淘宝优惠价购买喜欢的宝贝:
本文链接：https://hqyman.cn/post/9915.html 非本站原创文章欢迎转载，原创文章需保留本站地址！
微信支付宝扫一扫，打赏作者吧～休息一下~~
萌ICP备20248119号
