SWAN之ikev2协议compress配置测试

本测试主要验证远程用户carol和moon网关之间的IPComp压缩功能，两次使用ping测试隧道连接的压缩与否，使用的报文长度不同，内核不压缩长度较小的报文。测试拓扑如下：

主机配置

carol的连接配置文件：ikev2/compress/hosts/carol/etc/ipsec.conf，内容如下，主要关注compress字段设置为yes，这真是本次测试的压缩功能。另外moon主机的配置于此类似，打开compress功能。

config setupconn %defaultikelifetime=60mkeylife=20mrekeymargin=3mkeyingtries=1keyexchange=ikev2compress=yesleftfirewall=yesconn homeleft=PH_IP_CAROLleftcert=carolCert.pemleftid=carol@strongswan.orgright=PH_IP_MOONrightsubnet=10.1.0.0/16rightid=@moon.strongswan.orgauto=add

测试准备阶段

配置文件：ikev2/compress/pretest.dat，内容如下。主要是启动strongswan进程，以及在主机carol开启home连接。

carol::iptables-restore < /etc/iptables.rules
moon::iptables-restore < /etc/iptables.rules
carol::ipsec start
moon::ipsec start
moon::expect-connection rw
carol::expect-connection home
carol::ipsec up home

测试阶段

配置文件：ikev2/compress/evaltest.dat。以下测试语句确认ipsec status命令的输出结果中带有IPCOMP压缩字段。以及在moon主机上strongswan的运行日志中，在IKE_AUTH阶段协商了IPCOMP_SUP，对压缩的支持。

carol::ipsec status 2> /dev/null::home.*INSTALLED, TUNNEL.*IPCOMP::YES
moon:: ipsec status 2> /dev/null::rw.*INSTALLED, TUNNEL.*IPCOMP::YES
moon:: cat /var/log/daemon.log::IKE_AUTH request.*N(IPCOMP_SUP)::YES
moon:: cat /var/log/daemon.log::IKE_AUTH response.*N(IPCOMP_SUP)::YES

命令ipsec status在carol主机上的输出如下，可看到IPCOMP字段，及其CPI压缩参数索引值，入方向为52f2，出方向为4c65。

Connections:home:  192.168.0.100...192.168.0.1  IKEv2...
Security Associations (1 up, 0 connecting):home[1]: ESTABLISHED 1 second ago, 192.168.0.100[carol@strongswan.org]...192.168.0.1[moon.strongswan.org]home[1]: IKEv2 SPIs: d98370d54219a9d3_i* 5137ef64dcf2a7ff_r, public key reauthentication in 53 minuteshome[1]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519home{1}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c7f11753_i c8a3649e_o, IPCOMP CPIs: 52f2_i 4c65_o

以下carol主机上strongswan进程的日志，可见carol在IKE_AUTH的请求报文中发送了对IPCOMP_SUP，并且接收到的相应中也带有IPCOMP_SUP支持的字段。

 carol charon: 12[ENC] generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH N(IPCOMP_SUP) SA TSi TSr N(MOBIKE_SUP) N(ADD_6_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]...carol charon: 13[ENC] parsed IKE_AUTH response 1 [ IDr CERT AUTH N(IPCOMP_SUP) SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_6_ADDR) N(ADD_6_ADDR) ]

以下测试语句确认内核中是否建立了comp的安全关联。

moon:: ip xfrm state::proto comp spi::YES
carol::ip xfrm state::proto comp spi::YES

以下为carol主机上ip xfrm state的部分输出，可见完全符合以上的测试语句。

src 192.168.0.100 dst 192.168.0.1proto comp spi 0x00004c65(19557) reqid 1(0x00000001) mode tunnelreplay-window 0 seq 0x00000000 flag noecn nopmtudisc af-unspec (0x00100101)comp deflatesrc 192.168.0.1 dst 192.168.0.100proto comp spi 0x000052f2(21234) reqid 1(0x00000001) mode tunnelreplay-window 0 seq 0x00000000 flag noecn nopmtudisc af-unspec (0x00100101)comp deflate

最后的测试语句，在carol主机上ping主机alice，第一个ping命令指定报文长度为8192，第二个ping报文为默认的64字节，IPCOMP将对第一个ping报文进行压缩；由于第二个报文长度很短，不进行压缩处理。

carol::ping -n -c 1 -s 8184 -p deadbeef PH_IP_ALICE::8192 bytes from PH_IP_ALICE::YES
carol::ping -n -c 1 PH_IP_ALICE::64 bytes from PH_IP_ALICE::YES
moon::tcpdump::carol.strongswan.org > moon.strongswan.org: ESP::YES
moon::tcpdump::moon.strongswan.org >  carol.strongswan.org: ESP::YES

由下图tcpdump抓取的报文可见，第一个ping报文增加了IP Compression的报头，由于是carol发给alice的请求，CPI使用出方向的0x4c65。

strongswan测试版本： 5.8.1

END