OpenVPN mssfix: 큰 전송에서 한 클라이언트만 멈추는 이유

같은 서버의 다른 모든 기기는 계속 작동하는데 노트북 한 대만 터널을 통한 업로드에서 멈춥니다. 이 패턴은 서버 구성이 아니라 하나의 경로를 가리키며, mssfix 질문으로 들어가는 흔한 입구입니다. 이 옵션은 도움이 될 수 있지만 실제로 다시 쓰는 TCP 연결에만 해당합니다. 그 범위를 알면 클라이언트 하나를 구하려고 작동하는 서버를 바꾸지 않게 됩니다.

옵션이 다시 쓰는 것

mssfix는 터널을 지나는 TCP 핸드셰이크에서 알리는 최대 세그먼트 크기를 편집하여, 보내는 쪽이 캡슐화 예산에 맞는 세그먼트를 고르도록 합니다. 핸드셰이크에 작용하므로 변경 전에 열린 연결은 협상된 값을 유지합니다.

UDP 데이터그램을 줄이지 않고 터널 MTU도 설정하지 않습니다. 서로 다른 두 문제, 즉 경로 한계를 무시하는 TCP 송신자와 크기와 무관하게 큰 패킷을 조용히 버리는 경로가 같은 증상을 만듭니다. mssfix는 전자를 다루고 후자에는 아무것도 하지 않습니다.

이 구분이 실망스러운 실험을 설명합니다. 블랙홀 경로에서 더 작은 값을 설정하면 세그먼트 크기는 바뀌지만 뒤따르는 드롭은 바뀌지 않아, 전송은 다른 지점에서 실패합니다.

범위는 터널 내부의 TCP

TCP 트래픽만 다시 씁니다. QUIC 세션, 게임 또는 큰 UDP 데이터그램을 보내는 애플리케이션은 자체 패킷 크기를 유지하며, 그런 전송이 멈춘다면 해결책은 오히려 터널이나 경로의 MTU에 있습니다. 잘못된 계층에는 그 나름의 해결책이 있으므로 TCP 옵션을 찾기 전에 실패한 전송이 어느 프로토콜을 쓰는지 읽으십시오.

방향도 중요합니다. 클라이언트 설정은 그 클라이언트가 터널로 보내는 트래픽에 영향을 주고, 서버는 클라이언트 쪽으로 전달하는 흐름을 담당합니다. 들어오는 다운로드만 멈춘다면 클라이언트 측 값이 전부는 아닙니다.

숫자와 키워드는 이식 가능하지 않다

OpenVPN 2.6 커뮤니티 버전은 값 뒤에 선택적 키워드를 받습니다. mtu을 붙이면 숫자는 IP와 UDP 헤더를 포함한 바깥 패킷 크기를 뜻하고, 붙이지 않으면 인수는 다른 계산 관례를 따릅니다. 따라서 버전 간에 복사한 행은 같은 패킷 예산을 뜻하지 않습니다. 다른 릴리스용 자습서 대신 실제로 실행하는 빌드에 포함된 설명서 페이지를 확인하십시오.

구문은 다음과 같습니다:

mssfix 1400 mtu

1400은 경로에 대한 권장값이 아니라 자리 표시자로 다루십시오. 값을 측정한 경로와 실제 사용하는 캡슐화에서 도출하고, 이전 버전이나 다른 구현의 클라이언트가 키워드를 거부하거나 다르게 해석할 수 있음을 기억하십시오.

먼저 그 한 클라이언트에서 확인하라

무엇이든 바꾸기 전에 실패한 기기에서 경로를 측정하십시오. 경로가 단편화 없이 나를 수 있는 페이로드가 바로 찾는 숫자입니다:

ping -M do -s 1472 10.8.0.1
ping -M do -s 1400 10.8.0.1

첫 번째 프로브는 28바이트 헤더를 더하면 1500바이트 패킷에 들어갑니다. 단편화 오류로 실패하고 더 작은 것이 성공한다면 사용 가능한 크기는 그 사이 어딘가에 있으며, 터널 오버헤드는 위에서 빠집니다.

그다음 멈췄던 전송을 새 연결에서 반복하고 비교하십시오. 한 클라이언트만 개선되고 나머지는 그대로라면 문제의 범위를 찾은 것입니다. 모든 클라이언트가 멈춘다면 서버 측 값을 검토해야 합니다. 두 결과 모두 실패 경로에 한 번도 없었던 하드웨어를 바꿀 이유가 되지 않습니다.