이 질문의 끝에 새로운 세부 사항이 추가되었습니다. 원인에 대해 제로에 빠져있을 수 있습니다.

인터넷을 통해 소수의 클라이언트와 함께 UDP OpenVPN 기반 VPN을 tap모드로 설정했습니다 ( 네트워크에서 tap불가능한 멀티 캐스트 패킷을 전달하려면 VPN이 필요 하기 때문에 필요합니다 tun). VPN을 통한 TCP 연결 정지가 자주 발생했습니다. 즉, TCP 연결 (예 : SSH 연결이지만 다른 프로토콜에는 비슷한 문제가 있음)을 설정하고 세션 중 어느 시점에서 트래픽이 해당 TCP 세션을 통한 전송이 중단 된 것 같습니다.

이것은 lsSSH 세션에서 명령을 실행 하거나 cat긴 로그 파일 과 같은 큰 데이터 전송이 발생하는 지점과 관련이있는 것 같습니다 . 일부 Google 검색 은 Server Fault 에서 이전과 같은 많은 답변을 제시 하여 범인이 MTU 문제 일 가능성이 있음을 나타냅니다. 트래픽이 많은 기간 동안 VPN은 VPN 엔드 포인트. 위의 답변은 다음 OpenVPN 구성 설정을 사용하여 문제를 완화 할 것을 제안합니다.

fragment 1400
mssfix

VPN에서 사용되는 MTU를 1400 바이트로 제한하고 TCP 최대 세그먼트 크기를 수정하여 그보다 큰 패킷이 생성되지 않도록해야합니다. 이것은 문제를 약간 완화시키는 것처럼 보이지만 여전히 멈춤을 자주 봅니다. fragment지시문 에 대한 인수로 1200, 1000, 576과 같은 여러 가지 크기를 시도했지만 비슷한 결과가 나타납니다. VPN 서버가 인터넷에 직접 연결된 pfSense 시스템 에서 실행 중이고 클라이언트도 다른 위치의 인터넷에 직접 연결되어 있습니다.

퍼즐의 또 다른 이상한 조각 : tracepath유틸리티를 실행 하면 문제가 해결되는 것 같습니다. 샘플 실행은 다음과 같습니다.

[~]$ tracepath -n 192.168.100.91
 1:  192.168.100.90                                        0.039ms pmtu 1500
 1:  192.168.100.91                                       40.823ms reached
 1:  192.168.100.91                                       19.846ms reached
     Resume: pmtu 1500 hops 1 back 64

위의 실행은 VPN의 두 클라이언트 사이에서 이루어 192.168.100.90졌습니다.에서 대상 까지 추적을 시작했습니다 192.168.100.91. 두 클라이언트는 fragment 1200; mssfix;링크에 사용 된 MTU를 제한하기 위해 구성되었습니다 . 위의 결과는 tracepath두 클라이언트 사이의 경로가 1500 바이트 인 MTU를 감지 할 수 있음을 시사하는 것 같습니다 . OpenVPN 구성에 지정된 조각화 설정으로 인해 다소 작을 것이라고 가정합니다. 나는 그 결과가 다소 이상하다는 것을 알았다.

그러나 낯선 사람조차도 : 정지 상태의 TCP 연결이있는 경우 (예 : 중간에 디렉토리 목록이있는 SSH 세션과 같은) 위 의 tracepath명령 을 실행 하면 연결이 다시 시작됩니다 ! 나는 이것이 왜 그런지에 대한 합리적인 설명을 알아낼 수는 없지만 이것이 궁극적으로 문제를 근절하기위한 해결책을 가리키고 있다고 생각합니다.

다른 사람이 시도해 볼만한 권장 사항이 있습니까?

편집 : 나는 돌아와서 이것을 조금 더 살펴 보았고 더 혼란스러운 정보 만 발견했습니다.

• 위에서 볼 수 있듯이 OpenVPN 연결을 1400 바이트의 조각으로 설정했습니다. 그런 다음 인터넷을 통해 VPN에 연결하고 Wireshark를 사용하여 중단이 발생하는 동안 VPN 서버로 전송 된 UDP 패킷을 확인했습니다. 지정된 1400 바이트 수보다 큰 것이 없으므로 조각화가 제대로 작동하는 것 같습니다.

• 1400 바이트 MTU만으로도 충분하다는 것을 확인하기 위해 다음 (Linux) 명령을 사용하여 VPN 서버를 핑 (ping)했습니다.

  ping <host> -s 1450 -M do
  

  이 (믿습니다)는 조각화가 비활성화 된 1450 바이트 패킷을 보냅니다 (적어도 1600 바이트와 같이 너무 큰 값으로 설정하면 작동하지 않는 것으로 확인되었습니다). 이것들은 잘 작동하는 것 같습니다. 문제없이 호스트로부터 답장을받습니다.

따라서 이것은 아마도 MTU 문제가 아닙니다. 나는 그것이 무엇인지에 관해 혼란스러워합니다!

편집 2 : 토끼 구멍이 계속 깊어지고 있습니다. 이제 문제를 조금 더 격리했습니다. VPN 클라이언트가 사용하는 정확한 OS와 관련이있는 것 같습니다. 적어도 세 개의 우분투 컴퓨터 (버전 12.04 ~ 13.04)에서 문제를 성공적으로 복제했습니다. cat큰 로그 파일을 가져 와서 1 분 안에 SSH 연결 정지를 안정적으로 복제 할 수 있습니다.

그러나 CentOS 6 컴퓨터를 클라이언트로 사용하여 동일한 테스트를 수행하면 문제가 표시되지 않습니다! 우분투 컴퓨터에서 사용하는 것과 동일한 OpenVPN 클라이언트 버전을 사용하여 테스트했습니다. cat연결이 멈추지 않고 몇 시간 동안 파일을 기록 할 수 있습니다 . 이것은 궁극적 인 원인에 대한 통찰력을 제공하는 것처럼 보이지만 그 통찰력이 무엇인지 잘 모르겠습니다.

Wireshark를 사용하여 VPN을 통한 트래픽을 조사했습니다. 나는 TCP 전문가가 아니기 때문에 gory 세부 사항을 어떻게 만들지 잘 모르겠지만 요점은 인터넷 링크의 제한된 대역폭으로 인해 UDP 패킷이 삭제되어 내부에서 TCP 재전송을 유발한다는 것입니다 VPN 터널. CentOS 클라이언트에서는 이러한 재전송이 올바르게 수행되고 작업이 행복하게 진행됩니다. 그러나 우분투 클라이언트의 어느 시점에서, 원격 끝은 동일한 TCP 세그먼트를 계속해서 재전송하기 시작합니다 (각 재전송 사이에 전송 지연이 증가 함). 클라이언트는 각각의 재전송에 유효한 TCP ACK처럼 보이는 것을 보내지 만, 원격 끝은 계속 동일한 TCP 세그먼트를 계속 전송합니다. 이로 인해 광고 기간이 연장되고 연결이 중단됩니다. 내 질문은 다음과 같습니다.

• TCP 문제의 근본 원인을 해결하고 /하거나 결정하는 방법에 대한 권장 사항이 있습니까? 마치 원격 끝이 VPN 클라이언트가 보낸 ACK 메시지를 수락하지 않는 것처럼 보입니다.

CentOS 노드와 다양한 Ubuntu 릴리스 간의 공통적 인 차이점 중 하나는 Ubuntu에 훨씬 최신 Linux 커널 버전이 있다는 것입니다 (Ubuntu 12.04의 3.2에서 13.04의 3.8로). 새로운 커널 버그에 대한 포인터? 나는 그것이 그렇게된다면 문제를 겪는 유일한 사람은 아니라고 가정합니다. 나는 이것이 특별히 이국적인 설정처럼 보이지는 않는다고 생각합니다.

답변

$ sudo ip link set dev tun0 mtu 1350 && echo ":)"

$ ip a s

sysctl -w net.ipv4.tcp_window_scaling=0