![如何调试 ip xfrm 规则](https://linux22.com/image/671966/%E5%A6%82%E4%BD%95%E8%B0%83%E8%AF%95%20ip%20xfrm%20%E8%A7%84%E5%88%99.png)
我在 2 台机器上创建了 ip xfrm 规则,并尝试通过 ipsec 隧道传输流量。数据包进入另一端,加密后消失。
我通过 iptables 跟踪了它们,以下是跟踪结果。
2015-11-27T14:50:21.442638+04:30 cfae kernel: [70234.667488] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=00:0c:29:b7:97:49:00:0c:29:42:5b:e1:08:00 SRC=172.24.1.178 DST=10.60.60.31 LEN=128 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=108
2015-11-27T14:50:21.442665+04:30 cfae kernel: [70234.667513] TRACE: mangle:PREROUTING:rule:2 IN=eth0 OUT= MAC=00:0c:29:b7:97:49:00:0c:29:42:5b:e1:08:00 SRC=172.24.1.178 DST=10.60.60.31 LEN=128 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=108
2015-11-27T14:50:21.442672+04:30 cfae kernel: [70234.667580] TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC=00:0c:29:b7:97:49:00:0c:29:42:5b:e1:08:00 SRC=172.24.1.178 DST=10.60.60.31 LEN=128 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=108
2015-11-27T14:50:21.442674+04:30 cfae kernel: [70234.667589] TRACE: filter:INPUT:policy:1 IN=eth0 OUT= MAC=00:0c:29:b7:97:49:00:0c:29:42:5b:e1:08:00 SRC=172.24.1.178 DST=10.60.60.31 LEN=128 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=108
2015-11-27T14:50:21.471390+04:30 cfae kernel: [70234.696166] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=00:0c:29:b7:97:49:00:0c:29:42:5b:e1:08:00 SRC=172.24.1.178 DST=10.60.60.31 LEN=128 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=108
2015-11-27T14:50:21.471401+04:30 cfae kernel: [70234.696184] TRACE: mangle:PREROUTING:rule:2 IN=eth0 OUT= MAC=00:0c:29:b7:97:49:00:0c:29:42:5b:e1:08:00 SRC=172.24.1.178 DST=10.60.60.31 LEN=128 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=108
2015-11-27T14:50:21.471408+04:30 cfae kernel: [70234.696225] TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC=00:0c:29:b7:97:49:00:0c:29:42:5b:e1:08:00 SRC=172.24.1.178 DST=10.60.60.31 LEN=128 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=108
2015-11-27T14:50:21.471409+04:30 cfae kernel: [70234.696234] TRACE: filter:INPUT:policy:1 IN=eth0 OUT= MAC=00:0c:29:b7:97:49:00:0c:29:42:5b:e1:08:00 SRC=172.24.1.178 DST=10.60.60.31 LEN=128 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=108
2015-11-27T14:50:21.695777+04:30 cfae kernel: [70234.920757] TRACE: raw:PREROUTING:policy:2 IN=eth0 OUT= MAC=00:0c:29:b7:97:49:00:0c:29:42:5b:e1:08:00 SRC=172.24.1.178 DST=10.60.60.31 LEN=128 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=108
2015-11-27T14:50:21.695801+04:30 cfae kernel: [70234.920804] TRACE: mangle:PREROUTING:rule:2 IN=eth0 OUT= MAC=00:0c:29:b7:97:49:00:0c:29:42:5b:e1:08:00 SRC=172.24.1.178 DST=10.60.60.31 LEN=128 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=108
2015-11-27T14:50:21.695808+04:30 cfae kernel: [70234.920847] TRACE: mangle:INPUT:policy:1 IN=eth0 OUT= MAC=00:0c:29:b7:97:49:00:0c:29:42:5b:e1:08:00 SRC=172.24.1.178 DST=10.60.60.31 LEN=128 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=108
2015-11-27T14:50:21.695810+04:30 cfae kernel: [70234.920875] TRACE: filter:INPUT:policy:1 IN=eth0 OUT= MAC=00:0c:29:b7:97:49:00:0c:29:42:5b:e1:08:00 SRC=172.24.1.178 DST=10.60.60.31 LEN=128 TOS=0x00 PREC=0x00 TTL=61 ID=0 DF PROTO=UDP SPT=4500 DPT=4500 LEN=108
从跟踪中,我看到数据包从 filter:INPUT 返回到 raw:PREROUTING,这意味着它必须经过 xfrm 查找/解码处理。但数据包经过此处理后没有变化(长度相同,源/目标地址相同)。
但是“ip -s xfrm state”显示 0 个失败/已处理的数据包。
有什么方法可以通过 xfrm 模块跟踪这些数据包吗?或者有没有办法启用 xfrm 的调试?
这是配置。
On Machine1:
# ip xfrm state
src 10.60.60.31 dst 172.24.1.178
proto esp spi 0x5fca3acb reqid 212013014 mode tunnel
replay-window 0
auth-trunc hmac(sha512) 0xc2dde59416e78c96b9b0333686b3cf0b09016bb1c1d27215d3dbf7aca471304a1c25536eb2648b3dcd8946047007389d06eb3fb4c4e9379630acae51bd755b07 96
enc cbc(aes) 0x944023fd181e13d401f80e2166654b549b758aeeb9f382a20ca967631b111ef0
encap type espinudp sport 4500 dport 4500 addr 10.60.60.31
sel src 0.0.0.0/0 dst 0.0.0.0/0
src 172.24.1.178 dst 10.60.60.31
proto esp spi 0x5fca3acb reqid 212013014 mode tunnel
replay-window 0
mark 212013014/0xffffffff
auth-trunc hmac(sha512) 0xc2dde59416e78c96b9b0333686b3cf0b09016bb1c1d27215d3dbf7aca471304a1c25536eb2648b3dcd8946047007389d06eb3fb4c4e9379630acae51bd755b07 96
enc cbc(aes) 0x944023fd181e13d401f80e2166654b549b758aeeb9f382a20ca967631b111ef0
encap type espinudp sport 4500 dport 4500 addr 172.24.1.178
sel src 0.0.0.0/0 dst 0.0.0.0/0
# ip xfrm policy
src 0.0.0.0/0 dst 0.0.0.0/0
dir fwd priority 65535
tmpl src 10.60.60.31 dst 172.24.1.178
proto esp spi 0x5fca3acb reqid 212013014 mode tunnel
level use
src 0.0.0.0/0 dst 0.0.0.0/0
dir in priority 65535
tmpl src 10.60.60.31 dst 172.24.1.178
proto esp spi 0x5fca3acb reqid 212013014 mode tunnel
level use
src 0.0.0.0/0 dst 0.0.0.0/0
dir out priority 65535
mark 212013014/0xffffffff
tmpl src 172.24.1.178 dst 10.60.60.31
proto esp spi 0x5fca3acb reqid 212013014 mode tunnel
level use
On Machine2:
# ip xfrm policy
src 0.0.0.0/0 dst 0.0.0.0/0
dir fwd priority 65535
tmpl src 172.24.1.178 dst 10.60.60.31
proto esp spi 0x5fca3acb reqid 212012972 mode tunnel
level use
src 0.0.0.0/0 dst 0.0.0.0/0
dir in priority 65535
tmpl src 172.24.1.178 dst 10.60.60.31
proto esp spi 0x5fca3acb reqid 212012972 mode tunnel
level use
src 0.0.0.0/0 dst 0.0.0.0/0
dir out priority 65535
mark 212012972/0xffffffff
tmpl src 10.60.60.31 dst 172.24.1.178
proto esp spi 0x5fca3acb reqid 212012972 mode tunnel
level use
# ip xfrm state
src 172.24.1.178 dst 10.60.60.31
proto esp spi 0x5fca3acb reqid 212012972 mode tunnel
replay-window 0
auth-trunc hmac(sha512) 0xc2dde59416e78c96b9b0333686b3cf0b09016bb1c1d27215d3dbf7aca471304a1c25536eb2648b3dcd8946047007389d06eb3fb4c4e9379630acae51bd755b07 96
enc cbc(aes) 0x944023fd181e13d401f80e2166654b549b758aeeb9f382a20ca967631b111ef0
encap type espinudp sport 4500 dport 4500 addr 172.24.1.178
sel src 0.0.0.0/0 dst 0.0.0.0/0
src 10.60.60.31 dst 172.24.1.178
proto esp spi 0x5fca3acb reqid 212012972 mode tunnel
replay-window 0
mark 212012972/0xffffffff
auth-trunc hmac(sha512) 0xc2dde59416e78c96b9b0333686b3cf0b09016bb1c1d27215d3dbf7aca471304a1c25536eb2648b3dcd8946047007389d06eb3fb4c4e9379630acae51bd755b07 96
enc cbc(aes) 0x944023fd181e13d401f80e2166654b549b758aeeb9f382a20ca967631b111ef0
encap type espinudp sport 4500 dport 4500 addr 10.60.60.31
sel src 0.0.0.0/0 dst 0.0.0.0/0
答案1
要调试 xfrm,您可以使用命令ip xfrm monitor
。
它将显示数据库策略的变化。它将显示每个数据包的处理。
答案2
http://techblog.newsnow.co.uk/2011/11/simple-udp-esp-encapsulation-nat-t-for.html
看来,如果没有某些指令,Linux 内核不会解封装数据包。我们需要绑定到传入 udp 端口上的套接字并启用 udp 封装。上面的链接有 perl 脚本可以执行此操作。此后,我的流量没有任何问题。