expecting SSH2_MSG_KEX_ECDH_REPLY就上下文而言，我最初的问题是，当我通过 VPN（在本例中，在 pfSense 中运行的 OpenVPN）连接到服务器时，我与服务器的 ssh 连接挂起。
互联网表明这可能与 MTU 问题有关。
尝试调试此问题时，发生了以下情况：
ping -s 297 -M do $HOST
工作正常，但是
ping -s 298 -M do $HOST
只是挂了。
我的机器、主机和 pfSense 接口上的 MTU 都设置为 1500（尽管该接口在 pfSense 的 UI 中被禁用，但我不确定是否应该这样）。
为什么会发生这种情况？是不是有什么东西阻止了过大的数据包？我在哪里可以找到更多线索？
mtr $HOST表示两跳：到 pfSense，然后到服务器本身
答案1
事实上，您在控制的主机上设置了 MTU 并不意味着什么，因为它们之间的数据包 - 理论上 - 可以通过任何具有任何 MTU 的介质传输。
为了解决这个问题（除了 IP 分片机制），所谓的“路径 MTU 发现”机制是存在的。
请注意，它依赖于 ICMP 协议才能正常工作。除了其他事项之外，这意味着如果您的防火墙设置严格，则必须具有类似
iptables -t nat -A $CHAIN -m state --state RELATED -j ACCEPT
在您的INPUT链规则中（FORWARD如果您的防火墙也为其客户端执行 SNAT，则在链中）。
“相关”状态意味着，当收到类型 3、代码 4（目标不可达/需要分片）的 ICMP 数据包时，conntrack 子系统将决定它与哪个连接与...有关然后将其进一步传递到 netfilter 堆栈。此类数据包的状态为“RELATED”，这是已知的
iptables¹，因此如果您拒绝传递此类数据包（当人们全面禁用所有内容然后打出最小的漏洞时经常发生这种情况），P-MTU 发现将无法正常工作。
还要注意，即使您“取消”对 P-MTU 的正确支持，它仍然可能在某处被破坏。
为了解决这个问题，至少有两个方法：
- 将 MSS 限制为 MTU在 IP 堆栈中。
tun-mtu通过其、tun-mtu-extra和旋钮在 OpenVPN 级别限制这些内容mssfix。
请注意，这些设置确实会影响性能，因此请作为最后的手段使用。
¹ 因为虽然它不是 IP 交换的一部分，但显然与之相关。
答案2
我遇到了完全相同的问题：使用大小 297 执行 ping 操作有效，但使用大小 298 执行 ping 操作无效。
我们的客户端配置为不使用压缩：
comp-lzo no
将其更改为使用压缩解决了该问题：
comp-lzo yes
我不明白为什么这有效，但事实确实如此。
答案3
我在家里也遇到过类似的问题，SSH 连接挂在（我记得）连接设置的完全相同的位置。对我来说，调整本地 MTU 设置有助于在一定程度上减少问题，但要使问题消失，我必须打开 TCP MTU 探测。这样做之后，我再也没有遇到类似的问题。仅允许RELATED数据包通过 iptables，如kostix 的回答，沒有幫助。
对于 Linux，尝试
sudo sysctl net.ipv4.tcp_mtu_probing=1
可能的值包括：
0= 已禁用1= 默认情况下禁用，当检测到 ICMP 黑洞时启用2= 始终启用，使用 tcp_base_mss 的初始 MSS
其他操作系统将会类似又有所不同。
请注意，这需要在客户端系统上完成，而不是防火墙（因此不在 pfSense 框上）——除非您从防火墙启动 SSH 连接。