SCP 可重現地破壞 SSH 管道
我正在嘗試使用 .將一些證書複製到我的伺服器上
scp。$ scp ./cert.* sshuser@192.168.0.42:/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) 測試。兩者都無法複製文件。值得一提的是，我已連接到 OpenVPN 伺服器，以便訪問目標伺服器 (192.168.0.42) - 但這應該不是問題。
為什麼管道會中斷，我怎樣才能成功地將文件 scp 到伺服器上？
*編輯：*正如評論中所建議的，這很可能與 MTU 有關 - 但是，我不太確定如何解決此問題。
降低 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 允許通過具有 MTU 1473 或更高的鏈路傳輸 IPv4 數據包，而無需 IP 級別分段。
–mssfix 選項僅在您使用 UDP 協議進行 OpenVPN 對等通信時才有意義，即 –proto udp。
–mssfix 和 –fragment 可以理想地一起使用，其中 –mssfix 將首先嘗試阻止 TCP 需要數據包分段，並且如果大數據包無論如何通過（來自 TCP 以外的協議）， –fragment 將在內部將它們碎片化。
–fragment 和 –mssfix 都旨在解決路徑 MTU 發現在 OpenVPN 對等點之間的網路路徑上被破壞的情況。
這種故障的常見症狀是 OpenVPN 連接成功啟動，但在活動使用期間停止。
如果–fragment 和–mssfix 一起使用，–mssfix 將從–fragment max 選項中獲取其預設的max 參數。
因此，可以使用以下選項將最大 UDP 數據包大小降低到 1300（解決與 MTU 相關的連接問題的一個很好的第一次嘗試）：
–tun-man 1500 –fragment 1300 –mssfix
我在 OpenVPN 配置中添加了以下內容：
mssfix 1200我還假設可以調整此值以獲得更好的性能。