대기 시간이 긴 링크에서 OpenVPN 안정성을 개선하려면 어떻게해야합니까?

핑 시간이 약 3 초인 BGAN 위성 링크를 통해 OpenVPN VPN을 실행하고 있습니다. 우리는 tun 구성 에서 사용 하며 Linux (CentOS)에서 실행 중입니다. 주로 링크를 통해 전송되는 이메일이지만 메일에 큰 첨부 파일이 포함되면 VPN이 정지 된 것 같습니다.

"나는 터널을 통해 Ping 할 수 있지만, 실제 작업은 가두을 야기한다. 이것이 MTU 문제인가?" OpenVPN FAQ의 질문은 내 문제를 정확하게 설명하는 것처럼 보이지만 사용 mssfix하고 fragment여전히 상황을 개선하는 데별로 도움이되지 않는 것 같습니다.

내 주요 테스트는 scp로 VPN을 통해 2MB 파일을 복사하는 것 입니다. 약 192kbyte를 복사 한 후 정지 된 상태 를보고합니다 . 몇 초 기다렸다가 다시 복사를 시작한 다음 다른 몇 kbyte 후에 다시 정지합니다.

이 중단은 OpenVPN 구성에서 fragment또는 mssfix옵션을 설정했는지 여부에 관계없이 발생합니다 (설정 fragment 1000은 중단을 줄이는 것처럼 보이지만 제거하지는 않습니다). OpenVPN mtu-test은 1542를 MTU 크기로보고했습니다.

내가 사용하는 방법과시기에 대한 자세한 조언을 인터넷을 검색 한 mssfix하고 fragment,하지만 난 단지 페이지가 자주 묻는 질문과 같은 말을하고, 어떤 매개 변수를 사용하는 방법 및시기에 관한 세부 사항을 제공하지 찾을 수 있습니다.

내 질문은 다음과 같습니다

• 언제 사용합니까 mssfix와 fragment?
• 사용 mssfix하고 fragment조합 하여 사용 합니까?
• 경우 mssfix및 fragment솔루션이며, 무엇이다 tun-mtu, link-mtu및 mtu-disc매개 변수는?

또한 iperf 도구 를 사용하여 대역폭을 측정했습니다. VPN이 없으면 210Kbits / sec의 순서로 지속적으로 측정됩니다.

VPN ( )을 통해 iperf 를 사용 하는 경우 $ iperf -c remoteserver -t60 -i510Kbits / sec에서 시작한 다음 1.2Mbits / sec를보고 할 때까지 꾸준히 올라간 후 여러 번 반복하여 0kbits / sec를보고합니다 (I 1.2Mbits / sec는 일부 OpenVPN 버퍼링 때문일 수 있습니다.)

가 iperf는 대역폭을 측정하는 가장 좋은 방법은?

이 상황에 대한 도움을 주시면 감사하겠습니다.

MTU로 1542? WAN 링크에 대해서는 들어 본 적이 없습니다. 일반적으로 MTU는 최대 페이로드, ip 패킷 크기에서 IP (20 바이트) 및 ICMP (8 바이트)의 헤더를 뺀 값입니다. 이는 기존 이더넷 LAN의 경우 MTU = 1500을 의미합니다. 또한 대부분의 VPN은 패킷 캡슐화에 오버 헤드를 발생시킵니다. 일반적인 VPN MTU는 1400입니다.

현대 네트워크에서는 수신 및 송신 경로가 다를 수 있으며 자동 경로 재 라우팅으로 인해 변경 될 수 있으므로 MTU의 현재 상태를 결정하기가 어렵습니다. 이와 같은 네트워크의 경우 VPN 링크 양쪽에있는 호스트 (예 : 576)에서 MTU를 낮게 설정하는 것이 더 효과적 일 수 있습니다.

MSS (최대 세그먼트 크기)는 MTU에서 IP + TCP 헤더 (40 바이트)를 뺀 값입니다. 이것은 일반적으로 네트워크 스택에 의해 협상되며 MTU가 잘못되지 않는 한 MTU와 동일한 협상 문제가 없습니다. (MTU 협상은 일반적으로 차단 된 ICMP 또는 블랙홀 라우터에 의해 손상됩니다).

가장 먼저해야 할 일은 보내는 쪽에서 네트워크 패킷 캡처를 수행하고 프레임 크기별로 디스플레이를 정렬하는 것입니다 (Wireshark 에서이 열을 추가해야 할 수도 있습니다). 너무 큰 프레임, 예상 한 프레임을 보내지 않는지 확인해야합니다. 대형 전송 오프로드 또는 점보 프레임과 같은 옵션이 활성화 된 경우 최신 네트워크 카드가 대형 프레임을 전송하는 것은 드문 일이 아닙니다. 이 옵션이 활성화되면 30,000 + 바이트 프레임을 보았습니다.

호기심 때문에 네트워크 인터페이스의 MTU를 낮추려고 시도 했습니까? 아마도 위성 링크가 조각화를 심하게 망칠 수 있습니다. 반 직관적 인 메모로 TCP를 통해 openvpn을 통해 변경을 시도 할 수 있습니다. 성능이 저하되어야한다는 것을 알고 있지만 줄을 따라 조각화를 제어 할 수 없으면 도움이 될 수 있습니다.

TCP를 사용할 때는 TCP의 창 크기를 늘리십시오. 이것은 "공중의 패킷 수"에 도움이됩니다.

내가이 물건을 가지고 놀았 기 때문에 오랜 시간이 지났지 만 여기에 Google이 찾은 링크 가 있습니다.

난 후에 나는 당신이 BGAN을 실행하는 참조 질문을 다시 읽기 - I은 좋은 모양이 것 이 (또는 구글 "BGAN 스푸핑").

대역폭 측정과 관련하여 합리적인 패킷 크기를 사용하는 한 iperf가 꽤 괜찮은 것으로 나타났습니다.

나는 당신이 잘못된 나무를 짖는 것 같아요. 잘못된 MTU 문제가 발생하면 192KB 이전에 트래픽이 중단되었습니다. 나는 그것이 "비행 패킷 내"창, TCP 창 또는 위성 업 링크 자체의 일부 버퍼와 관련이 있다고 생각합니다.

당신은 모든 받고하는 경우 확실히 약간 긴 패킷 캡처를 (모두 '내부'와 VPN의 '외부')를 어떻게 볼 ACK'들