을 사용하여 일부 인증서를 내 서버에 복사하려고 합니다 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 OpenVPN이 캡슐화한 후 OpenVPN이 피어에 보내는 결과 UDP 패킷 크기가 최대 바이트를 초과하지 않도록 전송 패킷 크기를 제한해야 함을 터널에서 실행 중인 TCP 세션에 알립니다. 기본값은 1450입니다.
max 매개변수는 --link-mtu 매개변수, 즉 캡슐화 오버헤드를 추가한 후의 UDP 패킷 크기와 동일한 방식으로 해석되지만 UDP 헤더 자체는 제외됩니다. 결과 패킷은 IPv4의 경우 최대 28바이트, IPv6의 경우 최대 48바이트(IP 헤더의 경우 최대 20/40바이트, UDP 헤더의 경우 최대 8바이트) 증가합니다. 기본값 1450을 사용하면 IP 수준 조각화 없이 MTU 1473 이상의 링크를 통해 IPv4 패킷을 전송할 수 있습니다.
--mssfix 옵션은 OpenVPN P2P 통신에 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
또한 더 나은 성능을 위해 이 값을 조정할 수 있다고 가정합니다.