这是一个棘手的问题。
总结：
1) 客户端在（已关闭/不可用）端口 21 上与防火墙建立 TCP 握手，即使防火墙没有响应客户端的 SYN 数据包。
2）客户端发送 1 个 SYN 数据包（无重传），防火墙看到来自客户端的 3 个 SYN 数据包。
3) 同样的事情也发生在另一个大陆的 Linux 服务器上，其 PREROUTING 链上有阻止规则。
最近，我们注意到我们的边缘企业防火墙（Gartner 排名前三）在其 WAN 端口上显示端口 21 作为开放端口。
即使防火墙本身不使用该端口来提供任何服务，也没有策略/NAT/LB 将其重定向到另一个主机/服务器，它仍然在 NMAP 或 telnet/NC 输出中显示打开。
在防火墙界面和安全策略下明确拒绝它，没有任何效果。我在该供应商的文档中搜索，没有得到任何结果。
当时，为了确保防火墙是对端口 21 做出响应的防火墙，我在系统上运行了 tcpdump，并使用该防火墙的“数据包流”工具来查看发生了什么，瞧，我看到与端口 21 的连接流入了防火墙，证明来自客户端的数据包到达防火墙本身。
奇怪的是，我的客户发送1 个 SYN 数据包防火墙接收3 个 SYN 数据包，没有回应我的客户（没有发送 SYN/ACK），但不知何故连接成功。
只有 TCP 握手成功在客户端如果您在客户端按下回车键，您的连接将立即关闭。
由于这些防火墙的核心是基于 UNIX 的，出于好奇，我开始尝试看看是否可以在虚拟专用服务器（运行 Ubuntu Server 19）我在另一个大陆。
使用 IPTABLES，我创建了 DROP 策略预路由链阻止发往端口 21 的流量。我重复了我的测试，结果完全一样！客户端发送1 个 SYN 数据包，Ubuntu 服务器看到 3 个 SYN 数据包，未以 ACK 做出响应，但不知何故，客户端的连接却建立了！不用说，在客户端上按下回车键后，连接立即关闭。防火墙上的行为完全相同。
以下是我运行过的测试，在服务器和防火墙上都是相同的：
客户端通过端口 21 远程登录到服务器：
Client~# telnet Server-IP 21
Trying Server-IP...
Connected to Server-IP.
Escape character is '^]'.
Connection closed by foreign host.
运行 telnet 时在客户端上运行 TCPDUMP：
Client~# tcpdump -ni any port 21
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
19:24:05.456477 IP Client-priv-IP.36284 > Server-IP.21: Flags [S], seq 3093982956, win 64240, options [mss 1460,sackOK,TS val 3370721563 ecr 0,nop,wscale 7], length 0
19:24:05.557556 IP Server-IP.21 > Client-priv-IP.36284: Flags [S.], seq 3130560876, ack 3093982957, win 4080, options [mss 1360,sackOK,TS val 1773913297 ecr 3370721563], length 0
19:24:05.557679 IP Client-priv-IP.36284 > Server-IP.21: Flags [.], ack 1, win 64240, options [nop,nop,TS val 3370721664 ecr 1773913297], length 0
19:24:17.740636 IP Server-IP.21 > Client-priv-IP.36284: Flags [R.], seq 1, ack 1, win 0, length 0
运行 telnet 时在服务器上运行 TCPDUMP：
Server~# tcpdump -ni any -Q in port 21
listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes
19:25:05.001238 IP Client-pub-IP.36288 > Server-IP.21: Flags [S], seq 2605288404, win 4080, options [mss 1360,sackOK,TS val 1773972678 ecr 0], length 0
19:25:08.000566 IP Client-pub-IP.36288 > Server-IP.21: Flags [S], seq 2605288404, win 4080, options [mss 1360,sackOK,TS val 1773975678 ecr 0], length 0
19:25:10.999775 IP Client-pub-IP.36288 > Server-IP.21: Flags [S], seq 2605288404, win 4080, options [mss 1360,sackOK,TS val 1773978678 ecr 0], length 0
19:25:16.999702 IP Client-pub-IP.36288 > Server-IP.21: Flags [R.], seq 2605288405, ack 0, win 0, length 0
IPTABLES 丢弃 3 个 SYN 数据包：
Server~# iptables -t raw -L -n -v
Chain PREROUTING (policy ACCEPT 36M packets, 26G bytes)
pkts bytes target prot opt in out source destination
3 2468 DROP tcp -- eth0 * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21
我们已经从不同的 PC 和 ISP 对此进行了测试，以排除任何奇怪的客户端或互联网连接问题。
为了保密，我不能分享 IP 地址和供应商名称。
有人能解释这种行为吗？最令人费解的是客户端发送 1 个 SYN，而服务器/防火墙收到 3 个。
提前致谢
答案1
这难道不是预期的行为吗？“如果初始 TCP 握手由于数据包丢失而失败，那么您会看到 TCP SYN 数据包仅被重传 3 次。”我不知道微软是否是这个主题的权威，但我发现了这一点：文档 Microsoft
答案2
端口 21 是众所周知的 FTP 端口，而 FTP 并不是一个完全支持 NAT 的协议。您从客户端截取的 tcpdump 显示“Client-priv-IP”，而从服务器截取的 tcpdump 显示“Client-pub-IP”，因此我认为客户端位于 NAT 路由器后面。我敢打赌，路由器正在拦截 FTP，以便使其通过 NAT 工作，自行完成三次握手，并同时尝试三次到达目标服务器。当目标服务器没有响应时，它会在下一次机会时终止来自客户端的连接。
答案3
感谢 Tilman Schmidt，我能够搜索并找到 RFC 3234，它实际上是一个用于处理 FTP 流量的中间盒。
在 TCPDUMP 输出中，您可以看到 MSS 值等因素以及一些 TCP 选项（例如 SACK）在客户端和服务器之间有所不同，这表明存在中间盒。
中间框倾向于操纵：
- 一些 TCP 选项（SACK、NOP 等）
- TTL 值
- MSS 值
- 在某些情况下，源端口
- 序列号
- 数据包ID
我（乐观地）怀疑这些中间设备之所以会这样工作，是因为像 FTP 这样的协议在两个不同的 TCP 通道中工作。代理我的 FTP 连接的行为是为了了解并不会破坏从服务器流向客户端的数据通道。