VPN接続を介してSSHFSを実行しています。このリモートファイルシステム上のファイルに1270バイトのチャンクを送信しようとすると、次のようになります。
head -c 1270 /dev/urandom > /path/into/the/sshfs/foo
ファイルシステム全体がフリーズし、それにアクセスしようとするプロセスがハングします。これは、sshfsプロセスを強制終了することによってのみ修正できます。
代わりに1269バイトを送信しようとしても、問題は発生しません。
Sshfsのコマンドラインオプションをいろいろ試してみましたが、これに影響を与えるオプションは1つだけでした。
-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転送も機能していないようです。そのため、おそらくそれはis以下のsshの問題です。
MTUサイズを1412から1500に変更してみました。
ifconfig tun0 mtu 1500
しかし、効果はありません。
これは既知の問題ですか?どういうわけかこれを修正/防止/回避できますか?
編集:私はFritzBox(ホームルーター)VPN(明らかに「Cisco」スタイルですが、このトピックの専門家ではありません)とUbuntu16.04を使用して外部からアクセスしています。
また、ラップトップを使って携帯電話回線でこれをテストしても、問題が発生しないことにも気づきました。これは、制限付きファイアウォールの背後にあるリモートサイトにいる場合にのみ発生します。ただし、VPNは一般的に機能しますが、問題があるのはsshfsアスペクト(およびX転送)のみであることに注意してください。
VPNのオーバーヘッドが原因でMTUの問題が発生している可能性があります。 MTUを増やしても問題は解決しません。これは、MTUがメディアで使用可能な最大パケットサイズよりも大きくなるためです(LANのみの環境でジャンボフレームを使用していないと想定しています)。
実際、解決策は、トンネルデバイスのmtuを減らすことかもしれません。
VPNまたはルーターを指定していません。この問題を解決する方法は、OSレベルでのMTUクランプを使用することです。あるいは/さらに、OpenVPNを使用している場合は、たとえばmssfixを使用してパケットをフラグメント化するために使用できるディレクティブがあります https://www.sonassi.com/help/troubleshooting/setting-correct-mtu -for-openvpn およびフラグメントオプション- https://blog.hambier.lu/post/solving-openvpn-mtu-issues