我的防火墙 (Sonicwall NSA 2400) 已开始丢弃来自远程 Linux 服务器的 SSH 响应。当我从内部 IP 启动 SSH 会话时，它会超时，当我查看防火墙日志时，我看到以下内容：
TCP connection dropped
source (remote Linux server IP), port 1200, interface X1
destination: (my internal IP), port 65050, interface X0
notes: TCP Port: 65050
后续尝试失败，总是使用不同的内部目标端口。我这里遗漏了什么？我没有向 Sonicwall 的防火墙添加任何规则，但 Linux 服务器的 SSHD（Ubuntu 10.10）最近已更新。
更新：
数据包转储显示数据包因无效的 TCP 标志而被丢弃。
IP Type: TCP(0x6), Src=[source ip], Dst=[10.10.10.11]
TCP Packet Header
TCP Flags = [RST,], Src=[1200], Dst=[51150], Checksum=0x76d7
Application Header
Not Known
Value:[0]
DROPPED, Drop Code: 22, Module Id: 26, (Ref.Id: _3694_uyHtJcpfngKrRmv) 1:1)
十六进制：
0017c519 be3d0090 1a422c89 08004500 002c0000 00001606 *.....=...B,...E..,......*
82a34e10 18c10a0a 0a0b04b0 c7ce6c45 9d910000 00005004 *..N...........lE......P.*
000076d7 00007366 7463 *..v...sftc *
这是否意味着 Sonicwall 异常挑剔，或者远程服务器上的某些配置有误？我可以从其他远程 LAN 连接到它，没有任何问题。
答案1
啊，搞清楚该死的 Sonicwall 丢包的原因真是让人开心。欢迎拥有一台 NSA 设备。
首先，在 Sonicwall 的管理页面中指向该放置消息。您应该会看到一条弹出消息，其中包含“消息 ID”。您可以将该值与列出的放置代码进行交叉引用这里（适用于固件版本 5.6.0.x）。如果你使用的是旧固件，请参见版本 5.5.0.x或者版本 4.2.0.x。这些代码相当模糊，但它可能会帮助你走上正确的道路。
另外，您可以进行数据包转储，当您查看丢弃的数据包时，丢弃代码和模块 ID 将列在数据包捕获界面中。——
Christopher Karel
答案2
Linux 如何管理 MTU 协商 (tcp_mtu_probing) 存在问题。大多数 Linux 机器都带有一种模式，其中 Linux 不会以与标准不同的替代方式进行协商（从另一方面来说，这是不安全的，这就是 Sonicwall 不接受它的原因）。您可以通过执行以下操作在 Linux 机器中修复此问题：
echo 2 > /proc/sys/net/ipv4/tcp_mtu_probing
因此问题是 Sonicwall 拒绝使用“第一种”也是最标准的方法协商 MTU 大小，因为它不安全，而 Linux 拒绝使用“替代”方法协商 MTU 大小，这种方法更安全但效率较低。
结果，你完蛋了。这种情况只会发生在防火墙无法自行分割数据包的情况下，因为加密的有效载荷需要在源头重新组合，而不是在传输过程中。这就是为什么 SSL、SSH 和其他加密连接似乎存在很多问题。
使用 OpenSSH，您可以通过触碰 openSSH 客户端选项中的某些选项来“破解”它协商调整有效负载大小的方式，但您可能在使用其他应用程序时发现该问题，因此最好通过改变内核管理这种情况的方式来解决问题，如果不行的话，您可以修复 SSH，但后来发现 SSL 或 OpenVPN 存在问题。
来自 Sonicwall 的更多信息： https://support.software.dell.com/kb/sw3798 SonicWALL 不遵守或传递 LAN MTU 路径发现消息，因为没有办法验证这些消息，而且这些消息可能被用作一种攻击形式。例如，有人只需向不受保护的服务器发送路径 MTU 发现数据包，指示服务器将数据包大小限制为 5 个字节，而不是正常的 1500 个字节，即可对服务器发起拒绝服务攻击。这会降低服务器的速度，因为它必须将相同数量的数据处理成更多的数据包，从而产生很大的开销。