Ich versuche, einige Zertifikate mit auf meinen Server zu kopieren scp.
$ scp ./cert.* [email protected]:/tmp/
cert.crt 100% 2386 0.1KB/s 00:18
packet_write_wait: Connection to 192.168.0.42 port 22: Broken pipe
lost connection
Die erste Datei wird auf den Server geschrieben, jedoch nicht vollständig, da die Hashsumme nicht mit der Originaldatei übereinstimmt.
Dies passiert jedes Mal, wenn ich versuche, auf scpdiese Dateien ( crt, keyund p12) zuzugreifen.
Getestet mit Ubuntu 16.10 ( OpenSSH_7.3p1 Ubuntu-1, OpenSSL 1.0.2g 1 Mar 2016) und mit Windows 10 ( WinSCP 5.9.4). Bei beiden schlägt das Kopieren der Dateien fehl.
Es ist vielleicht erwähnenswert, dass ich mit einem OpenVPN-Server verbunden bin, um den Zielserver (192.168.0.42) zu erreichen – aber das sollte kein Problem sein.
Warum bricht die Pipe ab und wie kann ich die Dateien erfolgreich per SCP auf den Server übertragen?
bearbeiten:Dies hat, wie in den Kommentaren vorgeschlagen, höchstwahrscheinlich mit der MTU zu tun – ich bin mir jedoch noch nicht ganz sicher, wie ich dieses Problem beheben kann.
Antwort1
Bei mir hat das Verringern der MTU der OpenVPN-Verbindung geholfen.
Aus dem OpenVPN-Handbuch:
--mssfix max Gibt TCP-Sitzungen, die über den Tunnel laufen, bekannt, dass sie die Größe ihrer gesendeten Pakete so begrenzen sollen, dass die resultierende UDP-Paketgröße, die OpenVPN an seinen Peer sendet, nach der Kapselung durch OpenVPN die maximale Bytegröße nicht überschreitet. Der Standardwert ist 1450.
Der Max-Parameter wird auf die gleiche Weise wie der Parameter --link-mtu interpretiert, d. h. die UDP-Paketgröße nach Hinzufügen des Kapselungs-Overheads, jedoch ohne den UDP-Header selbst. Das resultierende Paket wäre für IPv4 höchstens 28 Bytes und für IPv6 48 Bytes größer (20/40 Bytes für den IP-Header und 8 Bytes für den UDP-Header). Der Standardwert von 1450 ermöglicht die Übertragung von IPv4-Paketen über eine Verbindung mit MTU 1473 oder höher ohne Fragmentierung auf IP-Ebene.
Die Option --mssfix ist nur sinnvoll, wenn Sie das UDP-Protokoll für die OpenVPN-Peer-to-Peer-Kommunikation verwenden, also --proto udp.
--mssfix und --fragment können idealerweise zusammen verwendet werden, wobei --mssfix versucht, TCP von vornherein von der Notwendigkeit einer Paketfragmentierung abzuhalten, und wenn trotzdem große Pakete durchkommen (von anderen Protokollen als TCP), werden sie von --fragment intern fragmentiert.
Sowohl --fragment als auch --mssfix sind für den Fall konzipiert, dass die Pfad-MTU-Erkennung auf dem Netzwerkpfad zwischen OpenVPN-Peers unterbrochen ist.
Das übliche Symptom eines solchen Ausfalls ist eine OpenVPN-Verbindung, die erfolgreich gestartet wird, dann aber während der aktiven Nutzung ins Stocken gerät.
Wenn --fragment und --mssfix zusammen verwendet werden, übernimmt --mssfix seinen Standard-Max-Parameter von der Max-Option von --fragment.
Daher könnte man die maximale UDP-Paketgröße mit den folgenden Optionen auf 1300 senken (ein guter erster Versuch zur Lösung von MTU-bezogenen Verbindungsproblemen):
--tun-mtu 1500 --fragment 1300 --mssfix
Ich habe der OpenVPN-Konfiguration Folgendes hinzugefügt:
mssfix 1200
Ich gehe auch davon aus, dass dieser Wert für eine bessere Leistung angepasst werden kann.