SWAN之ikev2协议compress配置测试

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

SWAN之ikev2协议compress配置测试_第1张图片

主机配置

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。

SWAN之ikev2协议compress配置测试_第2张图片

strongswan测试版本: 5.8.1

END

你可能感兴趣的:(IPSecurity)