MTU인가 MSS인가? VPN 변경이 실제로 고치는 것

핑은 성공하고, 큰 전송은 멈추며, 터널은 스스로 건강하다고 보고합니다. 누군가는 인터페이스의 MTU를 낮추고, 다른 누군가는 MSS를 제한하며, 때로는 아무도 기록하지 않는 이유로 문제가 사라집니다. 두 숫자는 서로 다른 대상을 설명하므로 잘못된 쪽을 바꾸면 우연처럼 보이는 수정이 됩니다. 절차는 이렇습니다: 계층을 식별하고, 맞는 조정을 적용한 뒤, 새 연결에서 테스트하세요.

두 숫자, 두 대상

MTU는 링크나 인터페이스에 속합니다: 분할하지 않고 전달할 수 있는 가장 큰 패킷입니다. MSS는 TCP에 속합니다: 세그먼트가 나를 수 있는 TCP 페이로드의 최대량이며 TCP와 IP 헤더를 모두 제외합니다. IPv4를 쓰는 일반 이더넷 링크에서 1500바이트 MTU는 잘 알려진 1460바이트 MSS를 만듭니다. 이 숫자들은 서로 다른 계층을 설명하고 서로 다른 메커니즘으로 교환됩니다. 둘 다 바이트로 측정되고 둘 다 1500 근처에 있어 혼동하기 쉽습니다.

하나는 인터페이스 설정으로 도착합니다. 다른 하나는 SYN 세그먼트 안의 옵션으로 도착하며, 당신의 인터페이스를 결코 보지 못하는 두 끝점 사이에서 협상됩니다.

바깥쪽 추가 부담은 어디로 가는가

VPN은 안쪽 패킷을 다른 패킷 안에 넣고, 바깥 패킷은 물리적 경로에 맞아야 합니다. 캡슐화 헤더, 바깥 IP 헤더, 전송 헤더, 그리고 어떤 인증 태그든 안쪽 패킷이 쓸 수 없는 바이트를 소비합니다. 터널 인터페이스를 1500으로 두면 바깥 패킷이 경로가 나를 수 있는 양을 일상적으로 초과합니다. '분할 금지' 비트가 설정되면 라우터는 그것을 버리고 ICMP 오류를 돌려보내야 합니다. 그 오류가 필터링되면 송신자는 결코 알지 못합니다.

그래서 장애가 선택적으로 보입니다. 작은 요청은 완료되고 세그먼트를 채우는 것은 멈춥니다. 큰 패킷만 버려지기 때문입니다. 핑을 통과시키는 터널은 데이터를 나르는 터널이 아닙니다.

MSS 제한, 그리고 적용되는 곳

MSS 클램핑은 선택한 지점을 지날 때 SYN 세그먼트의 값을 다시 쓰며, 그래서 양쪽 끝점은 이유도 모른 채 더 작은 페이로드를 고릅니다. Linux에서는 명시적 규칙으로 적용되는 mangle 테이블의 대상이며, 의도한 방향의 SYN 패킷에 맞아야 합니다. 터널 인터페이스와 주소 범위로 한정하세요. 넓은 규칙은 터널에 들어오지 않는 트래픽의 동작까지 바꿉니다.

효과는 TCP에만 있습니다. UDP 애플리케이션, QUIC 세션, 자체 데이터그램을 만드는 프로토콜은 영향을 받지 않습니다.

고정된 경로로 진단하세요

한 번에 변수 하나만 유지하세요. 크기를 직접 고른 패킷으로 테스트하고, 커널이 결과를 숨기지 않고 보고하도록 '분할 금지' 플래그를 설정하세요.

장애가 어디서 시작되는지 기록하세요: 터널 안쪽인지, 터널 인터페이스인지, 캡슐화 후 물리적 경로인지. 그다음 숫자 하나를 바꾸고 다른 테스트가 아니라 같은 테스트를 반복하세요. 기존 연결은 협상한 MSS를 유지하므로 정책 변경은 새 연결에서만 보이며, 그래서 캐시된 페이지는 어느 방향으로도 아무것도 증명하지 못합니다. 큰 업로드 하나가 작동하기 시작한다면 당신은 그 경로에 대해 배운 것이지 그 위의 모든 프로토콜에 대해 배운 것이 아닙니다.

각 변경이 고치지 않는 것

인터페이스 MTU를 낮추는 것은 이미 설정된 세션의 MSS를 바꾸지 않습니다. MSS를 제한해도 UDP 흐름에는 도움이 되지 않고, ICMP 오류가 한 방향으로만 필터링되는 경로도 고치지 못합니다. 각 변경은 문제의 한 부류를 고치고 나머지는 그대로 둡니다.

어떤 조정을 어디에 적용했고 어떤 테스트가 차이를 보였는지 적으세요. 그렇지 않으면 다음 엔지니어가 둘 다 적용하고 어느 것이 중요했는지 말할 능력을 잃습니다. 제약이 실제이고 영구적이라면 그것을 감추는 클램프보다 그것을 반영하는 터널 MTU를 선택하세요. 클램프해야 한다면 규칙을 범위로 한정하고 주석을 남기세요, 설명 없는 mangle 규칙은 기본적으로 영구화되기 때문입니다.