☰

ip xfrm 策略模板不匹配错误（XfrmInTmplMismatch）

tag-icon • tag-icon linux ipsec nftables template
ip xfrm 策略模板不匹配错误（XfrmInTmplMismatch）

我正在处理一个非常简单的 ipsec 案例，XfrmInTmplMismatch检查时不断收到接收错误（解封装 ESP 数据包之后）cat /proc/net/xfrm_stat。nft monitor all什么都没有显示。

这些是我设置的 SA 和 SP：

[root@b7a933eb94dd /]# ip -s xfrm state 
src 172.20.0.6 dst 172.18.0.6
    proto esp spi 0x000004d2(1234) reqid 0(0x00000000) mode tunnel
    replay-window 0 seq 0x00000000 flag  (0x00000000)
    mark 0x1234/0xffffffff output-mark 0x1234/0xffffffff
    auth-trunc hmac(sha256) 0x0123456789abcdef0123456789abcdef (128 bits) 96
    enc cbc(aes) 0xfedcba9876543210fedcba9876543210 (128 bits)
    anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
    sel src 0.0.0.0/0 dst 0.0.0.0/0 uid 0
    lifetime config:
      limit: soft (INF)(bytes), hard (INF)(bytes)
      limit: soft (INF)(packets), hard (INF)(packets)
      expire add: soft 0(sec), hard 0(sec)
      expire use: soft 0(sec), hard 0(sec)
    lifetime current:
      0(bytes), 0(packets)
      add 2022-08-06 14:45:00 use -
    stats:
      replay-window 0 replay 0 failed 0
src 172.18.0.6 dst 172.20.0.6
    proto esp spi 0x000004d2(1234) reqid 0(0x00000000) mode tunnel
    replay-window 0 seq 0x00000000 flag  (0x00000000)
    mark 0x1234/0xffffffff output-mark 0x1234/0xffffffff
    auth-trunc hmac(sha256) 0x0123456789abcdef0123456789abcdef (128 bits) 96
    enc cbc(aes) 0xfedcba9876543210fedcba9876543210 (128 bits)
    anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
    sel src 0.0.0.0/0 dst 0.0.0.0/0 uid 0
    lifetime config:
      limit: soft (INF)(bytes), hard (INF)(bytes)
      limit: soft (INF)(packets), hard (INF)(packets)
      expire add: soft 0(sec), hard 0(sec)
      expire use: soft 0(sec), hard 0(sec)
    lifetime current:
      1760(bytes), 16(packets)
      add 2022-08-06 14:44:51 use 2022-08-06 14:46:20
    stats:
      replay-window 0 replay 0 failed 0
[root@b7a933eb94dd /]# ip -s xfrm policy
src 0.0.0.0/0 dst 0.0.0.0/0 uid 0
    dir fwd action allow index 23930 priority 0 ptype main share any flag  (0x00000000)
    lifetime config:
      limit: soft (INF)(bytes), hard (INF)(bytes)
      limit: soft (INF)(packets), hard (INF)(packets)
      expire add: soft 0(sec), hard 0(sec)
      expire use: soft 0(sec), hard 0(sec)
    lifetime current:
      0(bytes), 0(packets)
      add 2022-08-06 14:54:07 use 2022-08-06 15:05:09
    mark 0x1234/0xffffffff 
    tmpl src 172.18.0.6 dst 172.20.0.6
        proto esp spi 0x000004d2(1234) reqid 0(0x00000000) mode tunnel
        level required share any 
        enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff
src 0.0.0.0/0 dst 0.0.0.0/0 uid 0
    dir out action allow index 23921 priority 0 ptype main share any flag  (0x00000000)
    lifetime config:
      limit: soft (INF)(bytes), hard (INF)(bytes)
      limit: soft (INF)(packets), hard (INF)(packets)
      expire add: soft 0(sec), hard 0(sec)
      expire use: soft 0(sec), hard 0(sec)
    lifetime current:
      0(bytes), 0(packets)
      add 2022-08-06 14:54:06 use -
    mark 0x1234/0xffffffff 
    tmpl src 172.20.0.6 dst 172.18.0.6
        proto esp spi 0x000004d2(1234) reqid 0(0x00000000) mode tunnel
        level required share any 
        enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff
src 0.0.0.0/0 dst 0.0.0.0/0 uid 0
    dir in action allow index 23912 priority 0 ptype main share any flag  (0x00000000)
    lifetime config:
      limit: soft (INF)(bytes), hard (INF)(bytes)
      limit: soft (INF)(packets), hard (INF)(packets)
      expire add: soft 0(sec), hard 0(sec)
      expire use: soft 0(sec), hard 0(sec)
    lifetime current:
      0(bytes), 0(packets)
      add 2022-08-06 14:54:06 use 2022-08-06 15:05:09
    mark 0x1234/0xffffffff 
    tmpl src 172.18.0.6 dst 172.20.0.6
        proto esp spi 0x000004d2(1234) reqid 0(0x00000000) mode tunnel
        level required share any 
        enc-mask ffffffff auth-mask ffffffff comp-mask ffffffff

我一直在以下不同阶段添加带有计数器的 nft 规则https://thermalcircle.de/lib/exe/fetch.php?media=linux:packet-flow-ipsec-tunnel.png，并且我确信 ESP 数据包已进入并且已被解密，请检查 SA 计数器：

src 172.18.0.6 dst 172.20.0.6
    proto esp spi 0x000004d2(1234) reqid 0(0x00000000) mode tunnel
    replay-window 0 seq 0x00000000 flag  (0x00000000)
    mark 0x1234/0xffffffff output-mark 0x1234/0xffffffff
    auth-trunc hmac(sha256) 0x0123456789abcdef0123456789abcdef (128 bits) 96
    enc cbc(aes) 0xfedcba9876543210fedcba9876543210 (128 bits)
    anti-replay context: seq 0x0, oseq 0x0, bitmap 0x00000000
    sel src 0.0.0.0/0 dst 0.0.0.0/0 uid 0
    lifetime config:
      limit: soft (INF)(bytes), hard (INF)(bytes)
      limit: soft (INF)(packets), hard (INF)(packets)
      expire add: soft 0(sec), hard 0(sec)
      expire use: soft 0(sec), hard 0(sec)
    lifetime current:
      1760(bytes), 16(packets)
      add 2022-08-06 14:44:51 use 2022-08-06 14:46:20
    stats:
      replay-window 0 replay 0 failed 0

然后，解封的 pkt 被重新循环，它通过预路由和路由，并且在到达转发之前，它无法查找fwd和/或inSP，因为模板与之前的 SA 不匹配。在这种情况下，有问题的数据包应该到达输出。

我已检查 pkt 到达此策略查找阶段时是否已正确标记。除了在 SA 中使用输出标记外，我还添加了临时 nft 规则来标记它，并且我使用 nftrace 检查这些规则是否被命中。

我的理解是，输出标记不是用于从 SP 模板中查找 SA 的哈希键的一部分，所以这应该不是问题。

我这里遗漏了什么吗？

提前致谢。

答案1

好的，所以我弄清楚了发生了什么，这在某种程度上与我的环境有关。被解封的数据包被路由到我的docker的eth0，只到达目标docker，然后通过相同的eth0返回路由，再通过eth0到达不同的目的地。在最后一步中，它匹配输出策略，但状态查找失败，这是正确的，因为此时它不是一个esp解封的pkt。对输出策略的模板进行更多限制解决了这个问题。

相关内容