通过上篇案例，我们已经初步掌握了如何通过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负载再做好一些，是不是还能提升呢？
