strongSwan报文交互过程

strongSwan报文交互过程

通过上篇案例，我们已经初步掌握了如何通过strongSwan配置两台Linux主机之间的IPsec隧道。今天我们再来看一下strongSwan配置IPsec的报文交互过程和转发性能。

组网图还是上次的拓扑。

首先查看一下在配置完strongSwan之后，还没有建立IPsec SA的状态。

和正常建立起IKE SA和IPsec SA的状态对比一下。

可以看到，状态和设备配置的状态相似。上次也提到了，Security Associations就是安全联盟SA，swan后面[]中是1的就是一阶段，也就是对应的IKE SA；后面是2的就是二阶段，也就是对应的IPsec SA。

Connections可以理解为对等体信息，其中前3行是IKE对等体信息，有本端和对端的身份标识以及认证方式；最后一行child就是IPsec连接，模式为TUNNEL隧道模式，因为IPsec SA是基于IKE SA创建的，所以用child来表示也是比较合理的。

Routed Connections和child对应，是通过leftsubnet和rightsubnet来配置的本端私网和对端私网。这种基于策略的VPN配置，通过匹配源目IP地址，可以将符合条件的流量通过指定的VPN隧道进行传输。

了解了这些基本状态信息，我们开始抓包。

首先还是触发IPsec隧道建立，如果已经建立的情况，可以使用命令进行重置。

strongswan restart

触发隧道建立。

抓包结果如下，可以看到报文协商过程和设备是一样的。

可以看到，第一对消息进行SA交换，主要是通过协商确认双方IKE安全策略的过程，报文交互的源目端口都是UDP 500，载荷中还进行了NAT-T检测，如果穿越了NAT，则将端口修改为UDP 4500。

从报文的Transform字段中，我们可以看到双发交互的安全策略信息。比如加密算法是AES-CBC-128，认证方式为Pre-shared key等。

第一个报文中发起方给出了两套安全提议，响应方选择了#1提议。

从状态中也可以看到对应的协商密钥信息。

第二对消息进行密钥交换，通过交换Diffie-Hellman公共值和辅助数据，最终双方计算生成一系列共享密钥（例如，认证密钥、加密密钥以及用于生成IPsec密钥参数的密钥材料），并使其中的加密密钥和认证密钥对后续的IKE消息提供安全保障。

第三对消息进行ID信息和验证数据的交换，并进行双方身份的认证。此时数据就已经都是加密的了。

到这里，IKE SA就协商完成了。

如果是基于路由的VPN，也就是有IPsec隧道接口的那种，一般会自动协商建立IKE SA；当有业务流量需要转发时，再快速进入到第二阶段（快速模式），也就是用在第一阶段建立的IKE SA为IPsec协商安全服务SA，建立用于最终的IP数据安全传输的IPsec SA。

好了，可以看到报文交互过程和华三设备的交互过程都是一样的，我就放心了。掌握了这些，我们接下来就能配置strongSwan和华三设备的对接了。

最后看一下Linux主机（4核CPU、4 GB内存）作为strongSwan网关的转发性能吧。

先用Host1作为服务器，从Host2发起测试，报文长度修改为1400字节，打流30秒。

测得带宽为963 Mbps，测试过程中Linux主机的CPU0利用率一度达到100%，应该是尽力了。再把服务器和客户端对调测试一下。

测得带宽为1.03 Gbps。看来是比VSR（4核CPU、8 GB内存）使用IPsec对接的771 Mbps要高一些，如果把CPU负载再做好一些，是不是还能提升呢？

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。