SSHFS über VPN friert große Teile ein

562
Alfe

Ich verwende SSHFS über eine VPN-Verbindung. Beim Versuch, einen Block von 1270 Bytes in eine Datei in diesem Remote-Dateisystem zu senden:

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

Das gesamte Dateisystem bleibt stehen und lässt jeden Prozess hängen, der versucht, darauf zuzugreifen. Dies kann nur behoben werden, indem der sshfs-Prozess beendet wird.

Wenn ich versuche, stattdessen 1269 Bytes zu senden, tritt kein Problem auf.

Ich habe viel mit den Kommandozeilenoptionen von sshfs herumgespielt und festgestellt, dass nur eine Option Einfluss darauf hat:

-o max_write=1240 

Wenn ich hier einen Wert unter 1270 übergebe, wird die Grenze, an der der Fehler auftritt, auf diesen Wert + 1 abgesenkt (ein Wert von 300 reduziert ihn jedoch auf 1183). Leider hilft das Erhöhen des Werts nicht, das Limit bleibt bei 1270 Bytes.

Es ist eine Sache mit Puffern, irgendwie. Wenn ich nacheinander schreibe, funktioniert alles gut:

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

Es scheint auch kein Problem der zugrundeliegenden SSH zu sein, weil a

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

funktioniert gut und druckt 2000wie erwartet.

Die X-Weiterleitung scheint jedoch ebenfalls nicht zu funktionieren, daher handelt es sich im Folgenden möglicherweise um ein ssh-Problem.

Ich habe versucht, die MTU-Größe von 1412 auf 1500 zu ändern:

ifconfig tun0 mtu 1500 

aber ohne Wirkung.

Ist das ein bekanntes Problem? Kann ich das irgendwie beheben / verhindern / umgehen?

EDIT: Ich verwende eine FritzBox (einen Heimrouter), ein VPN (anscheinend "cisco" -Stil, aber ich bin kein Experte für dieses Thema) und eine Ubuntu 16.04, um von außen darauf zuzugreifen.

Mir ist auch aufgefallen, dass das Problem nicht auftritt, wenn ich dies über ein Mobiltelefon mit einem Laptop teste. Es tritt nur auf, wenn ich mich an einem entfernten Standort befinde, der sich hinter einer restriktiven Firewall befindet. Beachten Sie jedoch, dass das VPN im Allgemeinen funktioniert. Nur der sshfs-Aspekt (und die X-Weiterleitung) scheinen problematisch zu sein.

1

1 Antwort auf die Frage

2
davidgo

Sie haben höchstwahrscheinlich ein MTU-Problem, das durch den Overhead des VPNs verursacht wird. Wenn Sie die MTU wie Sie erhöhen, wird das Problem nicht behoben, da die MTU dadurch größer wird als die maximal verfügbare Paketgröße für die Medien (ich nehme an, Sie verwenden keine Jumbo-Frames in einer LAN-Umgebung).

In der Tat könnte es eine Lösung sein, das mtu des Tunnelgeräts ZU VERMEIDEN.

Sie haben das VPN oder die Router nicht angegeben. Wir lösen dieses Problem mit der MTU-Klemmung auf OS-Ebene. Alternativ / zusätzlich, wenn Sie OpenVPN verwenden, gibt es Anweisungen, die Sie zum Fragmentieren von Paketen verwenden können, z. B. mit mssfix. Möglicherweise möchten Sie https://www.sonassi.com/help/troubleshea/setting-correct-mtu-for-openvpn nachschlagen und auch die Fragment-Option - https://blog.hambier.lu/post/solving-openvpn-mtu-issues

Danke für deine Antwort. Ich habe ein paar Details zu meinem VPN usw. hinzugefügt. Kann die MTU im laufenden Betrieb gewechselt werden, während die Verbindung läuft? Es spiegelt sich in der Ausgabe von 'ifconfig' wider, aber ich bin nicht sicher, ob es verwendet wird. Ich sehe noch keine Wirkung (zu Hause); Auch wenn ich die MTU auf große Werte wie 10000 eingestellt habe, kann ich das Problem hier nicht erzeugen. Ich werde morgen versuchen, die MTU am Remote-Standort zu reduzieren, um zu testen, ob sie dort hilft. Alfe vor 6 Jahren 0
Nach der Reduzierung der MTU-Größe auf 1000 Bytes war das Problem behoben. Auch die X-Weiterleitung funktioniert jetzt. Ein Mitarbeiter erwähnte auch, dass er solche Probleme durch Verringerung der MTU-Größe gelöst habe. Das scheint also eine ziemlich solide Lösung zu sein ;-) Danke! Alfe vor 6 Jahren 0