を使用していくつかの証明書をサーバーにコピーしようとしています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
最初のファイルはサーバーに書き込まれますが、ハッシュサムが元のファイルと一致しないため、完全には書き込まれません。
scpこれは、これらのファイル ( crt、keyおよび)にアクセスしようとするたびに発生しますp12。
Ubuntu 16.10 ( OpenSSH_7.3p1 Ubuntu-1, OpenSSL 1.0.2g 1 Mar 2016) および Windows 10 ( WinSCP 5.9.4) でテストしました。どちらもファイルのコピーに失敗しました。
ターゲット サーバー (192.168.0.42) に到達するために OpenVPN サーバーに接続していることを言及する価値があるかもしれませんが、これは問題にならないはずです。
パイプが壊れるのはなぜですか? また、ファイルをサーバーに正常に scp するにはどうすればよいですか?
編集：コメントで示唆されているように、これはおそらく MTU に関係していますが、この問題を解決する方法はまだよくわかりません。
答え1
OpenVPN 接続の MTU を下げるとうまくいきました。
OpenVPN マニュアルより:
--mssfix max トンネル経由で実行されている TCP セッションに対して、OpenVPN がパケットをカプセル化した後、OpenVPN がピアに送信する UDP パケットのサイズが最大バイトを超えないように、送信パケット サイズを制限するように通知します。デフォルト値は 1450 です。
max パラメータは --link-mtu パラメータと同じように解釈されます。つまり、カプセル化オーバーヘッドが追加された後の UDP パケット サイズですが、UDP ヘッダー自体は含まれません。結果のパケットは、IPv4 の場合は最大 28 バイト、IPv6 の場合は最大 48 バイト大きくなります (IP ヘッダーの場合は 20/40 バイト、UDP ヘッダーの場合は 8 バイト)。デフォルト値の 1450 では、IPv4 パケットを IP レベルの断片化なしで MTU 1473 以上のリンク経由で送信できます。
--mssfix オプションは、OpenVPN ピアツーピア通信に UDP プロトコル (つまり --proto udp) を使用している場合にのみ意味を持ちます。
--mssfix と --fragment は理想的には一緒に使用することができ、--mssfix は最初から TCP がパケットの断片化を必要としないようにし、大きなパケットが (TCP 以外のプロトコルから) 何らかの理由で通過すると、--fragment はそれらを内部的に断片化します。
--fragment と --mssfix はどちらも、OpenVPN ピア間のネットワーク パスでパス MTU 検出が壊れている場合を回避するように設計されています。
このような障害の一般的な症状は、OpenVPN 接続が正常に開始されるものの、アクティブな使用中に停止することです。
--fragment と --mssfix を一緒に使用する場合、--mssfix は --fragment max オプションからデフォルトの max パラメータを取得します。
したがって、次のオプションを使用して、最大 UDP パケット サイズを 1300 に下げることができます (MTU 関連の接続問題を解決するための最初の試みとして適切です)。
--tun-mtu 1500 --フラグメント 1300 --mssfix
OpenVPN 設定に以下を追加しました:
mssfix 1200
また、パフォーマンスを向上させるためにこの値を微調整できるとも考えられます。