☰

VPN 上的 SSHFS 在大块上冻结

tag-icon • tag-icon vpn sshfs
VPN 上的 SSHFS 在大块上冻结

我正在通过 VPN 连接运行 SSHFS。当尝试将 1270 字节的块发送到此远程文件系统上的文件中时：

head -c 1270 /dev/urandom > /path/into/the/sshfs/foo

整个文件系统冻结，任何试图访问它的进程都会挂起。只能通过终止 sshfs 进程来解决此问题。

如果我尝试发送 1269 个字节，则不会出现任何问题。

我尝试了很多 sshfs 的命令行选项，发现只有一个选项对此有影响：

-o max_write=1240

如果我在这里传递一个小于 1270 的值，错误开始发生的限制将降低到此值 + 1（尽管值 300 将其降低到 1183）。不幸的是，增加该值没有帮助，限制仍然保持在 1270 字节。

不知何故，这是与缓冲区有关的事情。如果我使用连续写入，则一切正常：

(head -c 1269 /dev/urandom
 head -c 1269 /dev/urandom) > /path/into/the/sshfs/foo

这似乎也不是底层 ssh 的问题，因为

ssh remote_host "bash -c 'head -c 2000 /dev/zero | tr \\\0 0'" | wc -c

运行良好2000并按预期打印。

但是，X 转发似乎也不起作用，所以也许它是下面是一个 ssh 问题。

我尝试将 MTU 大小从 1412 更改为 1500：

ifconfig tun0 mtu 1500

但没有任何效果。

这是一个已知问题吗？我能以某种方式修复/预防/规避这个问题吗？

编辑：我正在使用 FritzBox（家用路由器）VPN（显然是“思科”风格，但我不是这个主题的专家）和 Ubuntu 16.04 从外部访问它。

我还注意到，当我使用笔记本电脑通过移动电话线进行测试时，问题没有发生。只有当我在受限制的防火墙后面的远程站点时，才会发生此问题。但请注意，VPN 通常可以正常工作，只有 sshfs 方面（和 X 转发）似乎存在问题。

答案1

您很可能遇到了由 VPN 开销引起的 MTU 问题。像您那样增加 MTU 并不能解决问题，因为这会使 MTU 大于媒体可用的最大数据包大小（我假设您没有在仅限局域网的环境中使用巨型帧）。

事实上，解决方案可能是减少隧道设备的 mtu。

您尚未指定 VPN 或路由器。我们解决这个问题的方法是在操作系统级别使用 MTU 限制。或者/另外，如果您使用的是 OpenVPN，您可以使用指令来分割数据包，例如使用 mssfix - 您可能需要查看https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn以及片段选项 -https://blog.hambier.lu/post/solving-openvpn-mtu-issues

相关内容