无法访问服务器，可能是由 openvpn mtu 引起的

2024-6-1 • tag-icon

我尝试实现的目标：通过 OpenVPN 访问 LAN 上的服务器症状：SSH 连接在 SSH2_MSG_KEXINIT 上挂起

ssh -vvv [email protected]
OpenSSH_8.2p1 Ubuntu-4ubuntu0.2, OpenSSL 1.1.1f  31 Mar 2020
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to 10.0.0.101 [10.0.0.101] port 22.
debug1: Connection established.
[...]
debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 10.0.0.101:22 as 'emmy'
debug1: SSH2_MSG_KEXINIT sent
^C

服务器端日志：

May  4 16:35:58 emmy sshd[39003]: Connection from 10.10.8.6 port 55592 on 10.0.0.101 port 22 rdomain ""
May  4 16:35:58 emmy sshd[39003]: debug1: Local version string SSH-2.0-OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
May  4 16:35:58 emmy sshd[39003]: debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.2
May  4 16:35:58 emmy sshd[39003]: debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.2 pat OpenSSH* compat 0x04000000
[...]
May  4 16:35:58 emmy sshd[39003]: debug1: SSH2_MSG_KEXINIT sent [preauth]
May  4 16:35:58 emmy sshd[39003]: debug3: receive packet: type 20 [preauth]
May  4 16:35:58 emmy sshd[39003]: debug1: SSH2_MSG_KEXINIT received [preauth]
May  4 16:35:58 emmy sshd[39003]: debug2: local server KEXINIT proposal [preauth]
[...]
May  4 16:35:58 emmy sshd[39003]: debug2: peer client KEXINIT proposal [preauth]
[...]
May  4 16:35:58 emmy sshd[39003]: debug1: kex: algorithm: curve25519-sha256 [preauth]
May  4 16:35:58 emmy sshd[39003]: debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth]
May  4 16:35:58 emmy sshd[39003]: debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none [preauth]
May  4 16:35:58 emmy sshd[39003]: debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none [preauth]
May  4 16:35:58 emmy sshd[39003]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
May  4 16:36:09 emmy sshd[39003]: Connection closed by 10.10.8.6 port 55592 [preauth]
[...]

对我来说这听起来像是路径 mtu 的问题所以我尝试测量它。

第一次尝试：tracepath

sudo tracepath 10.0.0.101
 1?: [LOCALHOST]                      pmtu 1500
 1:  DESKTOP-6STOO94.mshome.net                            0.218ms
 1:  DESKTOP-6STOO94.mshome.net                            0.165ms
 2:  no reply
 3:  no reply
 4:  no reply
 5:  [...]
^C

这似乎不起作用。我们先测试一下连通性：

ping 10.0.0.101
PING 10.0.0.101 (10.0.0.101) 56(84) bytes of data.
64 bytes from 10.0.0.101: icmp_seq=1 ttl=62 time=14.2 ms
64 bytes from 10.0.0.101: icmp_seq=2 ttl=62 time=13.9 ms
64 bytes from 10.0.0.101: icmp_seq=3 ttl=62 time=13.9 ms
64 bytes from 10.0.0.101: icmp_seq=4 ttl=62 time=14.4 ms
64 bytes from 10.0.0.101: icmp_seq=5 ttl=62 time=14.3 ms
64 bytes from 10.0.0.101: icmp_seq=6 ttl=62 time=13.8 ms
64 bytes from 10.0.0.101: icmp_seq=7 ttl=62 time=14.1 ms
64 bytes from 10.0.0.101: icmp_seq=8 ttl=62 time=14.1 ms
^C
--- 10.0.0.101 ping statistics ---
8 packets transmitted, 8 received, 0% packet loss, time 7012ms
rtt min/avg/max/mdev = 13.835/14.087/14.392/0.184 ms

好的，这似乎可行，让我们尝试使用 traceroute 获取路径 mtu

sudo traceroute -I --mtu 10.0.0.101
traceroute to 10.0.0.101 (10.0.0.101), 30 hops max, 65000 byte packets
 1  DESKTOP-6STOO94.mshome.net (192.168.176.65)  0.140 ms F=1500  0.133 ms  0.092 ms
 2  * * *
 3  * * *
 4  * * *
 5  [...]^C

即使正常的跟踪路由有效，也没有运气

sudo traceroute -I 10.0.0.101
[sudo] password for benedikt:
traceroute to 10.0.0.101 (10.0.0.101), 30 hops max, 60 byte packets
 1  DESKTOP-6STOO94.mshome.net (192.168.176.65)  0.316 ms  0.284 ms  0.280 ms
 2  * * *
 3  * * *
 4  * * *
 5  * * 10.0.0.101 (10.0.0.101)  14.195 ms

所以我必须手动检查

ping -M do -s 1500 -c 1 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 1500(1528) bytes of data.
ping: local error: message too long, mtu=1500

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 0 received, +1 errors, 100% packet loss, time 0ms

MTU 1500 显然太高了。让我们从这里往下看：

ping -M do -s 500 -c 1 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 500(528) bytes of data.

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 0 received, 100% packet loss, time 0ms

没有任何答案是奇怪的。但让我们进一步探讨。

ping -M do -s 256 -c 1 10.0.0.1
PING 10.0.0.1 (10.0.0.1) 256(284) bytes of data.
264 bytes from 10.0.0.1: icmp_seq=1 ttl=63 time=14.4 ms

--- 10.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 14.431/14.431/14.431/0.000 ms

最佳值似乎是 285。这解释了我的问题。SSH 数据包大于该值，出于安全原因不允许分段。

我现在的问题是：我该如何克服这个问题？

答案1

最有可能的是，您已启用 PMTUD（路径 MTU 发现），但“需要分段”ICMP 消息被丢弃，并且它们不会返回到您的计算机来调整 MTU。

选项：

修复网络路径以不阻止 ICMP 消息。
手动调整 MTU。在 Linux 上，您可以使用可选参数调整每个路由mtu的MTU ip route。很可能您需要在通信的两个端点和/或网关上调整它。
使用 MSS 限制（路径上的网关会降低 TCP 连接上的 MSS）。这是许多 VPN 的功能。当然，它只会修复 TCP 通信。
禁用 PMTU。这将停止设置 TCP 和 UDP 通信的 DF（不分段）位，从而允许分段。您可能需要在通信的两个端点和/或网关上禁用 PMTU。在某些情况下，分段可能会出现问题。

答案1

相关内容