我正在云上设置一个 VLAN，其中许多服务器将通过 VPN 连接到远程主机。设置如下：
Their Host d.d.d.72
|
|
|
Their VPN Public IP b.b.b.116
|
|
Internet
|
|
Our VPN Public IP a.a.a.101
|
Our VPN Local IP s.s.s.31
|
Our VLAN ----------+-----------+-------------------+--------...--------+--
| | |
s.s.s.111 s.s.s.112 ... s.s.s.nnn
| | |
UAT1 UAT2 ... UATn
strongswan被使用Our VPN，目标是允许UAT1其中UATn的主机使用原始 TCP 套接字Our VLAN进行连接。Their Host
SYN数据包从 发送UAT2并到达 ，Their Host用 进行回复SYN ACK。SYN ACK被 接收Our VPN然后转发到UAT2。 问题是SYN ACK未被 接收UAT2！
以下是 tcpdump 日志UAT2：
root@uat2:~# tcpdump -ttnnvvS -i any host d.d.d.72
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
1687385350.426771 ens7 Out IP (tos 0x10, ttl 64, id 38370, offset 0, flags [DF], proto TCP (6), length 60)
s.s.s.112.54838 > d.d.d.72.9990: Flags [S], cksum 0x324d (incorrect -> 0x3ba1), seq 4126082045, win 62720, options [mss 8960,sackOK,TS val 4002865714 ecr 0,nop,wscale 7], length 0
1687385351.445963 ens7 Out IP (tos 0x10, ttl 64, id 38371, offset 0, flags [DF], proto TCP (6), length 60)
s.s.s.112.54838 > d.d.d.72.9990: Flags [S], cksum 0x324d (incorrect -> 0x37a6), seq 4126082045, win 62720, options [mss 8960,sackOK,TS val 4002866733 ecr 0,nop,wscale 7], length 0
1687385353.461982 ens7 Out IP (tos 0x10, ttl 64, id 38372, offset 0, flags [DF], proto TCP (6), length 60)
s.s.s.112.54838 > d.d.d.72.9990: Flags [S], cksum 0x324d (incorrect -> 0x2fc6), seq 4126082045, win 62720, options [mss 8960,sackOK,TS val 4002868749 ecr 0,nop,wscale 7], length 0
以下是 tcpdump 日志Our VPN：
root@vpn1:~# tcpdump -ttnnvvS -i any host d.d.d.72
tcpdump: data link type LINUX_SLL2
tcpdump: listening on any, link-type LINUX_SLL2 (Linux cooked v2), snapshot length 262144 bytes
1687385350.426647 ens4 In IP (tos 0x10, ttl 64, id 38370, offset 0, flags [DF], proto TCP (6), length 60)
s.s.s.112.54838 > d.d.d.72.9990: Flags [S], cksum 0x3ba1 (correct), seq 4126082045, win 62720, options [mss 8960,sackOK,TS val 4002865714 ecr 0,nop,wscale 7], length 0
1687385350.468411 ens3 In IP (tos 0x0, ttl 57, id 11319, offset 0, flags [DF], proto TCP (6), length 60)
d.d.d.72.9990 > s.s.s.112.54838: Flags [S.], cksum 0x94f0 (correct), seq 1695227873, ack 4126082046, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 1699598776 ecr 4002865714], length 0
1687385350.469803 ens4 Out IP (tos 0x0, ttl 56, id 11319, offset 0, flags [DF], proto TCP (6), length 60)
d.d.d.72.9990 > s.s.s.112.54838: Flags [S.], cksum 0x94f0 (correct), seq 1695227873, ack 4126082046, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 1699598776 ecr 4002865714], length 0
1687385351.445122 ens4 In IP (tos 0x10, ttl 64, id 38371, offset 0, flags [DF], proto TCP (6), length 60)
s.s.s.112.54838 > d.d.d.72.9990: Flags [S], cksum 0x37a6 (correct), seq 4126082045, win 62720, options [mss 8960,sackOK,TS val 4002866733 ecr 0,nop,wscale 7], length 0
1687385351.484746 ens3 In IP (tos 0x0, ttl 57, id 11635, offset 0, flags [DF], proto TCP (6), length 60)
d.d.d.72.9990 > s.s.s.112.54838: Flags [S.], cksum 0x90f3 (correct), seq 1695227873, ack 4126082046, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 1699598778 ecr 4002866733], length 0
1687385351.484783 ens4 Out IP (tos 0x0, ttl 56, id 11635, offset 0, flags [DF], proto TCP (6), length 60)
d.d.d.72.9990 > s.s.s.112.54838: Flags [S.], cksum 0x90f3 (correct), seq 1695227873, ack 4126082046, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 1699598778 ecr 4002866733], length 0
1687385353.461170 ens4 In IP (tos 0x10, ttl 64, id 38372, offset 0, flags [DF], proto TCP (6), length 60)
s.s.s.112.54838 > d.d.d.72.9990: Flags [S], cksum 0x2fc6 (correct), seq 4126082045, win 62720, options [mss 8960,sackOK,TS val 4002868749 ecr 0,nop,wscale 7], length 0
1687385354.421463 ens3 In IP (tos 0x0, ttl 57, id 13219, offset 0, flags [DF], proto TCP (6), length 60)
d.d.d.72.9990 > s.s.s.112.54838: Flags [S.], cksum 0x90ee (correct), seq 1695227873, ack 4126082046, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 1699598783 ecr 4002866733], length 0
1687385354.421495 ens4 Out IP (tos 0x0, ttl 56, id 13219, offset 0, flags [DF], proto TCP (6), length 60)
d.d.d.72.9990 > s.s.s.112.54838: Flags [S.], cksum 0x90ee (correct), seq 1695227873, ack 4126082046, win 65535, options [mss 1460,nop,wscale 2,nop,nop,TS val 1699598783 ecr 4002866733], length 0
1687385359.466543 ens3 In IP (tos 0x10, ttl 253, id 37551, offset 0, flags [DF], proto TCP (6), length 40)
d.d.d.72.9990 > s.s.s.112.54838: Flags [R.], cksum 0x019a (correct), seq 1695227874, ack 4126082046, win 0, length 0
1687385359.466573 ens4 Out IP (tos 0x10, ttl 252, id 37551, offset 0, flags [DF], proto TCP (6), length 40)
d.d.d.72.9990 > s.s.s.112.54838: Flags [R.], cksum 0x019a (correct), seq 1695227874, ack 4126082046, win 0, length 0
如你看到的：
UAT2已SYN发送id 38370- 该数据包已被接收，
Our VPN并转发给Their Host Their Host已SYN ACK回复id 11319- 该数据包已被接收，
Our VPN并转发给UAT2 - 问题是：
UAT2没有收到SYN ACK
知道如何调查这个问题吗？
在上述测试过程中：
Our VPN，所有虚拟机UAT1都在云上UATnDebian 11iptables是UAT2空的：root@uat2:~# iptables -L -v --line-numbers Chain INPUT (policy ACCEPT 65 packets, 26451 bytes) num pkts bytes target prot opt in out source destination Chain FORWARD (policy ACCEPT 0 packets, 0 bytes) num pkts bytes target prot opt in out source destination Chain OUTPUT (policy ACCEPT 64 packets, 26539 bytes) num pkts bytes target prot opt in out source destination root@uat2:~# telnet d.d.d.72 9990 Trying d.d.d.72... ^C定义了静态路由
UAT2以到达Their Host对于
Our VPN，ip_forward被激活：net.ipv4.ip_forward = 1ipsec隧道已建立：
root@vpn1:~# ipsec status Security Associations (1 up, 0 connecting): our_conn[2]: ESTABLISHED 24 minutes ago, a.a.a.101[a.a.a.101]...b.b.b.116[b.b.b.116] our_conn{2}: INSTALLED, TUNNEL, reqid 1, ESP SPIs: c38c258f_i c727e8a0_o our_conn{2}: s.s.s.0/24 === d.d.d.72/32 root@vpn1:~#Our VPNping 成功UAT2
答案1
正如@ecdsa 所建议的，数据包被基础设施（云服务）丢弃。
为了证明这一点，我添加了一个 NAT 规则，根据目标端口更改源地址。当我telnet从My VPN到 时，例如UAT2使用 NAT 端口，数据包会被丢弃。当我telnet使用任何其他端口时，数据包不会被丢弃。
我想到的解决方案是在 级别实现端口转发Our VPN。这样，UATx机器将通过 进行通信Our VLAN，Our VPN然后将流量转发到d.d.d.72机器。
UATx注意：使用此解决方案，不再需要机器上的静态路由。