을 사용하여 일부 인증서를 내 서버에 복사하려고 합니다 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을 사용하면 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 옵션에서 기본 최대 매개변수를 가져옵니다.
따라서 다음 옵션을 사용하면 최대 UDP 패킷 크기를 1300(MTU 관련 연결 문제를 해결하기 위한 좋은 첫 번째 시도)으로 낮출 수 있습니다.
--tun-mtu 1500 --조각 1300 --mssfix
OpenVPN 구성에 다음을 추가했습니다.
mssfix 1200
또한 더 나은 성능을 위해 이 값을 조정할 수도 있다고 가정합니다.