VPN을 통한 경로 MTU 탐색: 크기 산정과 ICMP 공백

터널이 핸드셰이크를 마치고 작은 요청은 돌아오는데 첫 대용량 전송이 멈춥니다. 이 패턴은 처리량보다 훨씬 먼저 경로 MTU를 가리킵니다. 경로상의 모든 링크가 패킷 크기를 제한하고, 캡슐화는 그 허용량의 일부를 외부 헤더에 쓰기 때문에 내부 패킷은 원시 경로가 시사하는 것보다 작아야 합니다. 실패는 조용하며, 그래서 진단 비용이 큽니다.

경로 MTU가 실제로 측정하는 것

경로 MTU는 두 호스트 사이 경로에서 가장 작은 링크 MTU이지, 로컬 인터페이스에 인쇄된 MTU가 아닙니다. 로컬 값은 추정이 시작되는 지점이고, 경로는 그것이 어디서 끝나야 하는지를 결정합니다. 그래서 동일한 터널이 한 액세스 네트워크에서는 작동하고 다른 곳에서는 멈출 수 있습니다. 바뀐 것은 경로이지 구성이 아닙니다. 한 번 측정하고 어디서나 가정하는 것이 이 문제를 살려 두는 실수입니다.

터널의 경우 중요한 숫자는 내부 MTU이며, 외부 경로의 허용량에서 캡슐화가 소비하는 만큼을 뺀 값입니다. WireGuard는 외부 IP 헤더와 UDP 헤더를 추가합니다. 다른 전송 방식은 자체 헤더를 추가합니다. 내부 크기를 너무 높게 설정하면 모든 전체 크기 패킷에 결코 일어나지 않을 조각화가 필요합니다.

터널이 사용 가능한 패킷을 줄이는 이유

터널 인터페이스가 물리 링크의 MTU를 유지하면 모든 큰 패킷은 하류의 누군가가 기꺼이 조각화해 주는지에 달려 있습니다. IPv4는 원칙적으로 이를 허용하지만, 조각화하지 말라는 지시를 받은 라우터는 대신 오류를 반환합니다. IPv6 라우터는 전송 중에 전혀 조각화하지 않으므로 같은 설정이 주소 체계에 따라 다르게 동작합니다. 어느 쪽이든 무언가가 돌아와 보고하기 전까지 송신자는 아무것도 배우지 못합니다.

실질적인 결과는 핸드셰이크에는 맞고 페이로드에는 맞지 않는 크기입니다. TLS ClientHello나 DNS 쿼리는 축소된 경로를 그대로 통과할 만큼 작지만 대량 전송은 그렇지 않습니다. 그래서 증상은 특정 호스트가 아니라 특정 작업 주변에 모입니다.

피드백이 도착해야만 탐색이 작동한다

IPv4 탐색은 don't-fragment 비트에 의존합니다. 패킷을 전달할 수 없는 라우터는 다음 홉 MTU와 함께 ICMP fragmentation-needed를 반환하고, 송신자는 추정치를 낮춥니다. IPv6는 대신 Packet Too Big 메시지를 사용합니다. 라우터가 전송 중에 조각화하지 않기 때문입니다. 두 메커니즘 모두 메시지가 터널을 지나 반환 경로의 모든 방화벽을 넘어 송신자에게 돌아갈 길을 찾는다고 가정합니다. 그 가정이 무너지면 송신자는 경로가 감당할 수 없는 크기를 계속 재시도합니다.

echo request와 echo reply를 허용하는 방화벽이 반드시 그 오류 유형까지 허용한 것은 아닙니다. ICMP는 하나의 가족이며, 여기서 중요한 구성원은 에코 쌍이 아니라 오류입니다. 터널 양 끝과 그 사이 경로에서 제어 트래픽 정책을 확인하고, 모든 곳에서 모든 ICMP 유형을 허용하는 대신 플랫폼이 지원하는 지침을 따르십시오.

같은 필터링이 터널 안에 있을 수도 있습니다. 내부 경로가 오류를 버리지만 외부 경로가 그것을 운반하면, 송신자는 캡슐화된 트래픽이 실제로는 결코 보지 못하는 한계에 적응할 수 있습니다.

숫자를 추측하지 말고 경로를 시험하라

목적지, 액세스 네트워크, 터널을 고정한 채 패킷 크기만 바꿉니다. MTU 힌트와 함께 실패하는 don't-fragment 시험은 다음 홉의 한계를 알려 줍니다. 어떤 크기가 통과할 때까지 반복하고, 크기와 주소 체계를 모두 기록하십시오.

ping -M do -s 1400 10.60.20.10
ping -M do -s 1300 10.60.20.10
ping -6 -M do -s 1300 2001:db8::10

맞는 ping은 실제 애플리케이션의 전체 크기 세그먼트가 맞는다는 것을 증명하지 않으므로 실제로 실패한 전송으로 시험을 반복하십시오. 가장 큰 성공한 시험과 구성한 터널 MTU를 비교하고, 두 숫자를 메모에 따로 보관하십시오. 그것들이 대략 헤더 하나만큼 다르면 결함이 아니라 캡슐화 오버헤드를 찾은 것입니다.

RFC 4821에 설명된 PLPMTUD는 위쪽으로 시험하고 전달된 오류를 신뢰하는 대신 전송 계층 확인 응답을 사용합니다. ICMP를 필터링하는 경로에서 도움이 되지만 지원은 스택과 애플리케이션에 따라 다릅니다. TCP 흐름은 스스로 회복될 수 있지만 고정된 데이터그램 크기를 가진 UDP 애플리케이션은 계속 실패합니다.

값을 선택하고 근거를 기록하라

경로를 알게 되면 터널 MTU를 낮추는 것은 진단이자 정당한 수정입니다. 어떤 경로와 어떤 피드백 메커니즘이 관련되었는지 아는 것을 대체하지는 않습니다. 모바일 링크에 맞춘 값은 광섬유 연결에서 불필요하게 작을 것이기 때문입니다. 선택한 크기, 그것을 정당화한 시험, 롤백 단계를 기록하십시오.

IPv4 메커니즘은 RFC 1191에, IPv6 패킷화 지침은 RFC 8201에 설명되어 있습니다. 둘을 모두 언급하면 다음 엔지니어가 가정을 다시 도출하지 않게 됩니다. 선택한 크기에서도 전송이 멈춘다면 숫자를 낮추는 것을 멈추고 다음 계층을 보십시오. 모든 크기에서 실패하는 경로는 MTU 문제가 아닙니다.