☰

ipsec/strongswan - 隧道已启动，流量已发送和接收，但回复被忽略

tag-icon • tag-icon vpn ipsec strongswan
ipsec/strongswan - 隧道已启动，流量已发送和接收，但回复被忽略

我需要一些帮助，我使用 ESP 和 IKEv2 设置了 strongswan IPsec 隧道，隧道已启动并且远程看到数据包并对其进行应答，但我的服务器却忽略了？答案。

该隧道位于我的 Debian 11 服务器之间，该服务器同时拥有 IP 10.0.1.1 和公共 IP 100.100.100.100（此侧没有 NAT），远程是 Checkpoint VPN 端点。

在我这边，我配置了一个像这样的 swanctl 配置（所有 IP 都已更改）：

cat /etc/swanctl.d/conf.d/test.conf
connections {
  test {
    local_addrs = 100.100.100.100
    local {
      id = 100.100.100.100
      auth = psk
    }
    remote_addrs = 200.200.200.200
    remote {
      id = 200.200.200.200
    }
    children {
      test_child {
        local_ts = 10.0.1.0/24
        remote_ts = 10.0.2.0/24
        esp_proposals = aes256-sha256-modp2048
        dpd_action = restart
        start_action = start
        ike {
          proposals = aes256-sha256-modp2048
        }
      }
    }
    version = 2
    dpd_delay = 300s
  }
}

secrets {
  ike-psk {
    secret = "MY_PSK_KEY"
  }
}

远程由 Checkpoint VPN 端点上的另一个人配置。

我可以看到隧道但它在“in”部分显示 0 个数据包，仅限出站数据包

swanctl --list-sas
test: #1, ESTABLISHED, IKEv2, c7742fc57b157ccd_i* b75ae63221a8c6d7_r
  local  '100.100.100.100' @ 100.100.100.100[4500]
  remote '200.200.200.200' @ 200.200.200.200[4500]
  AES_CBC-256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
  established 2326s ago, rekeying in 11899s
  test_child: #1, reqid 1, INSTALLED, TUNNEL, ESP:AES_CBC-256/HMAC_SHA2_256_128
    installed 2326s ago, rekeying in 916s, expires in 1634s
    in  cb90145c,      0 bytes,     0 packets
    out 883097a1,  15600 bytes,   260 packets,     2s ago
    local  10.0.1.0/24
    remote 10.0.2.0/24

在远端，他们确认看到了进来的流量并且确认他们正在应答（我使用 nc 10.0.2.1 4444 进行测试）。为了尝试了解发生了什么，我使用 tcpdump 捕获了流量，并使用 Wireshark 解密所有内容。 在 Wireshark 中，解封装的数据包显示我的“nc 10.0.2.1 4444”，其中 TCP SYN 从 10.0.1.1 到 10.0.2.1，远程使用 TCP SYN ACK 从 10.0.2.1 到 10.0.1.1 进行应答，但此后我方未发送任何 TCP ACK。它只是再次开始 TCP 重传，TCP SYN 从 10.0.1.1 到 10.0.2.1，然后远程使用 TCP SYN ACK 从 10.0.2.1 到 10.0.1.1 进行应答，...

在禁用防火墙（UFW）的情况下，从我的服务器公共 IP 100.100.100.100（而不是从我的本地 IP 10.0.1.1，这很奇怪（我再次在解封装和解密的流量中看到此情况））收到 SYN-ACK 后，会发送 ICMP 目标不可达（端口不可达）信息

在我的防火墙（UFW）中，唯一的规则是

ufw allow from 200.200.200.200 port 500,4500 proto udp to any
ufw allow from 10.0.2.0/24 to any

我没有配置任何 NAT 规则因为我认为我不需要这样做，因为我的服务器在 local_ts 子网中持有 IP 10.0.1.1，并且发送的流量正确地使用 10.0.1.1 作为发件人地址。

所以我的问题是为什么 SYN-ACK 被忽略，为什么 swanctl --list-sas 显示 0 个数据包而我在 Wireshark 中可以看到它们？

一些额外的信息

ip xfrm policy
src 10.0.1.0/24 dst 10.0.2.0/24
        dir out priority 371839 ptype main
        tmpl src 100.100.100.100 dst 200.200.200.200
                proto esp spi 0x649d7f4d reqid 1 mode tunnel
src 10.0.2.0/24 dst 10.0.1.0/24
        dir fwd priority 371839 ptype main
        tmpl src 200.200.200.200 dst 100.100.100.100
                proto esp reqid 1 mode tunnel
src 10.0.2.0/24 dst 10.0.1.0/24
        dir in priority 371839 ptype main
        tmpl src 200.200.200.200 dst 100.100.100.100
                proto esp reqid 1 mode tunnel


ip route show table 220
10.0.2.0/24 via 100.100.100.255 dev enp33s0f0 proto static src 10.0.1.1


ip a
2: enp33s0f0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether ab:cd:ef:gh:ij:kl brd ff:ff:ff:ff:ff:ff
    inet 100.100.100.100/24 brd 100.100.100.255 scope global dynamic enp33s0f0
       valid_lft 81651sec preferred_lft 81651sec
    inet 10.0.1.1/24 brd 10.0.1.255 scope global enp33s0f0:0
       valid_lft forever preferred_lft forever

答案1

经过几个小时的调试，我终于找到了问题所在。我不得不encap = yes在 swanctl conf 中添加该选项/etc/swanctl.d/conf.d/test.conf

当使用 tcpdump 时，我发现我的服务器发送了没有 UDP 封装的数据包，但远程端发送了带有 UDP 封装的数据包。

11:29:17.152643 IP 100.100.100.100 > 200.200.200.200: ESP(spi=0xc5fde19f,seq=0xa), length 104
11:29:17.159164 IP 200.200.200.200.4500 > 100.100.100.100.0: UDP-encap: ESP(spi=0xc8bbfc6a,seq=0x10), length 104

添加 encap = yes 选项后，tcpdump 显示此信息

12:02:40.953446 IP 100.100.100.100.4500 > 200.200.200.200.4500: UDP-encap: ESP(spi=0x5b65b0e9,seq=0xf1), length 104
12:02:40.959585 IP 200.200.200.200.4500 > 100.100.100.100.4500: UDP-encap: ESP(spi=0xcf893859,seq=0x9f), length 104

从 strongswan 文档中，选项 encap 执行以下操作，其默认值为“否”

为了强制对 ESP 数据包进行 UDP 封装，IKE 守护进程可以操纵 NAT 检测负载。这会让对等端认为传输路径上存在 NAT 情况，从而迫使其将 ESP 数据包封装在 UDP 中。通常这不是必需的，但它可以帮助解决中间防火墙过于严格（阻止 ESP 数据包）导致的连接问题

相关内容