本测试主要验证远程用户carol和moon网关之间的IPComp压缩功能,两次使用ping测试隧道连接的压缩与否,使用的报文长度不同,内核不压缩长度较小的报文。测试拓扑如下:
carol的连接配置文件:ikev2/compress/hosts/carol/etc/ipsec.conf,内容如下,主要关注compress字段设置为yes,这真是本次测试的压缩功能。另外moon主机的配置于此类似,打开compress功能。
config setup
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
compress=yes
leftfirewall=yes
conn home
left=PH_IP_CAROL
leftcert=carolCert.pem
[email protected]
right=PH_IP_MOON
rightsubnet=10.1.0.0/16
[email protected]
auto=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[[email protected]]...192.168.0.1[moon.strongswan.org]
home[1]: IKEv2 SPIs: d98370d54219a9d3_i* 5137ef64dcf2a7ff_r, public key reauthentication in 53 minutes
home[1]: IKE proposal: AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/CURVE_25519
home{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.1
proto comp spi 0x00004c65(19557) reqid 1(0x00000001) mode tunnel
replay-window 0 seq 0x00000000 flag noecn nopmtudisc af-unspec (0x00100101)
comp deflate
src 192.168.0.1 dst 192.168.0.100
proto comp spi 0x000052f2(21234) reqid 1(0x00000001) mode tunnel
replay-window 0 seq 0x00000000 flag noecn nopmtudisc af-unspec (0x00100101)
comp deflate
最后的测试语句,在carol主机上ping主机alice,第一个ping命令指定报文长度为8184,第二个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