Linux 클라이언트의 세 가지 설정은 모두 «패킷을 더 작게»처럼 들리지만 서로 다른 계층에서 작동합니다. 인터페이스 MTU는 장치가 보내는 모든 패킷을 제한합니다. 경로 MTU는 그 경로를 쓰는 패킷을 제한하며, VPN 목적지 하나에는 대개 이것이 정말 원하는 값입니다. TCP MSS 클램프는 두 끝이 협상하는 내용을 바꾸고 UDP에는 아무것도 하지 않습니다.

같은 손잡이처럼 보이는 세 가지 제어

고르기 전에 나란히 놓아 보십시오, 잘못된 줄을 고르는 것이 작동하지 않는 조언 대부분을 설명합니다:

ControlScopeWhat it cannot fix
Interface MTUEvery packet the device sendsNothing, but it over-constrains unrelated traffic
Route MTUPackets using that routeA send that the lookup never routes there
MSS clampTCP handshake on that pathUDP payload sizes and ICMP

머신 전체의 Ethernet MTU를 낮추는 것은 이 수정의 거친 버전입니다. 작동하지만 호스트의 다른 모든 애플리케이션에도 불이익을 주며, 경로가 멀쩡했던 것들도 포함합니다. 경로별 값은 같은 의도를 부작용 없이 표현합니다.

이 비교는 호스트가 스스로 만드는 트래픽에만 유효합니다. 다른 클라이언트를 위해 패킷을 전달하는 일에는 그 클라이언트 자신의 경로와 터널의 바깥 예산이 관련되며, 이 호스트의 경로 메트릭은 그 경계를 넘지 못합니다.

예산을 조회에서 이기는 경로에 붙이십시오

예시 IPv4 경로 레코드는 이렇게 생겼습니다:

ip -4 route get 10.60.0.20
ip -4 route add 10.60.0.0/16 dev tun-office src 10.90.0.2 mtu 1380

레코드는 붙여 넣을 값이 아니라 의도의 설명으로 읽으십시오. 프리픽스, 장치, 선호 소스는 실제 구성과 맞아야 하고, 숫자는 블로그 글이 아니라 캡슐화된 경로에 관한 증거에서 나와야 합니다. 경로 MTU는 안쪽 IP 패킷을 제한하며, 이는 1380바이트 TCP 페이로드나 1380바이트 암호화된 바깥 패킷과 같지 않습니다.

무엇이든 더하기 전에 조회가 실제로 어디서 해결되는지 보십시오. 정책 규칙이 있는 호스트는 특정 목적지를 main 가 아닌 다른 테이블로 라우팅할 수 있고, 오직 main 에만 있는 메트릭은 그 요청에 보이지 않습니다. ip -4 route show table all 와 ip route get 의 답을 비교하십시오. 규칙이 쓸 때는 마크나 네임스페이스 문맥도 포함하고, 둘이 맞지 않으면 메트릭이 필요한 쪽은 답한 테이블이며 더 정돈되어 보이는 쪽이 아닙니다.

mtu는 mtu lock이 아닙니다

기본적으로 커널은 ICMP 피드백으로 경로 MTU를 여전히 갱신할 수 있으며, 경로 MTU 탐색이 바로 그런 용도입니다. lock 를 더하면 그것이 멈춥니다. 다른 결정이며 같은 숫자를 지키는 더 강한 방법이 아니고, IPv4에서는 «단편화하지 않음» 비트의 문서화된 처리가 달라집니다.

경로를 측정했고 무엇이 오든 값을 고정하고 싶다면 잠금은 합리적입니다. 네트워크가 정당한 크기 피드백을 보낼 때는 나쁜 기본값입니다, 커널이 더 이상 조정할 수 없고 장애가 다른 증상으로 옮겨가기 때문입니다.

경로 어딘가에서 ICMP가 필터링되면 어떤 경로 설정도 그것을 고치지 못합니다. 수정은 필터 쪽의 일이고, 더 작은 MTU는 다음 경로 변경까지 실제 결함을 숨기는 우회책입니다.

터널 소프트웨어는 자체 크기 손잡이를 더합니다

OpenVPN의 mssfix 는 문서화된 UDP 터널 사례에 대해 TCP 세그먼트 크기를 조정합니다. TCP 대화에 작동하므로 운영체제 경로 MTU의 다른 표기가 아니며, 협상을 무시하는 UDP 서비스에는 도움이 되지 않습니다.

경로 MTU, 인터페이스 MTU 변경, MSS 클램프를 같은 변경 창에 겹쳐 두지 마십시오. 문제가 사라져도 어느 것이 중요했는지 알 수 없고, 남긴 것들은 아무도 기억하지 못하는 이유로 수년간 트래픽을 제한합니다.

되돌릴 수 있게 만든 다음 증명하십시오

경로의 진짜 주인이 변경이 재연결 후에도 남는지 결정합니다. 경로를 동적으로 설치하는 VPN 클라이언트는 보통 당신의 메트릭 없이 다시 만들고, 수동 ip route add 은 하루 뒤에 실패한 수정처럼 보입니다. 값을 관리자 구성에 넣고, 일시적 실험이 필요하면 먼저 원래 경로를 기록하십시오.

멈췄던 작업을 수행하는 새 연결로 시험한 뒤, 의도한 사설 경로가 여전히 이기고 무관한 목적지가 바뀌지 않았는지 확인하고, 터널을 다시 연결해 경로를 다시 읽으십시오. 재연결에서 사라지는 값은 수정이 아닙니다.

증거가 변경을 뒷받침하지 않으면 관리자를 통해 덮어쓰기를 제거하고 경로를 삭제하는 대신 원래 경로 속성을 복원하십시오. 그런 다음 무엇을 어느 경로에서 측정했는지 적어 두어, 다음 사람이 진짜 개선과 방치된 실험을 구별할 수 있게 하십시오.

관련 글