![无法访问服务器,可能是由 openvpn mtu 引起的](https://linux22.com/image/766224/%E6%97%A0%E6%B3%95%E8%AE%BF%E9%97%AE%E6%9C%8D%E5%8A%A1%E5%99%A8%EF%BC%8C%E5%8F%AF%E8%83%BD%E6%98%AF%E7%94%B1%20openvpn%20mtu%20%E5%BC%95%E8%B5%B7%E7%9A%84.png)
我尝试实现的目标:通过 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
的MTUip route
。很可能您需要在通信的两个端点和/或网关上调整它。 - 使用 MSS 限制(路径上的网关会降低 TCP 连接上的 MSS)。这是许多 VPN 的功能。当然,它只会修复 TCP 通信。
- 禁用 PMTU。这将停止设置 TCP 和 UDP 通信的 DF(不分段)位,从而允许分段。您可能需要在通信的两个端点和/或网关上禁用 PMTU。在某些情况下,分段可能会出现问题。