점보 프레임이 VPN 경로를 9000바이트 패킷을 나르는 경로로 만들지는 않는다

LAN에서 9000바이트 프레임을 켜고 VPN이 빨라지기를 기대했다. 오히려 느려졌거나, 큰 전송을 아예 통과시키지 못했다. 점보 프레임은 로컬 링크 합의일 뿐이며, 터널이 지나는 경로를 넓혀 주지 않는다.

쓸 수 있는 예산은 터널이 더하는 캡슐화를 포함해 경로상 가장 작은 경계가 정한다.

점보 프레임이 실제로 바꾸는 것

MTU는 인터페이스 하나의 속성이다. 서버와 그 스위치에서 올리면 그 둘은 단편화 없이 더 큰 프레임을 주고받을 수 있다. 스위치 너머의 라우터, ISP, 터널 반대편에 대해서는 아무 말도 하지 않는다. 그 장비들에는 각자의 한계가 있고, 그중 하나를 넘는 패킷은 당신이 정하지 않은 규칙에 따라 버려지거나 단편화된다.

로컬 합의, 전역 결과. 혼란은 전부 여기서 나온다.

캡슐화 세금

터널은 패킷을 다른 패킷 안에 감싼다. IPv4 UDP 위의 WireGuard는 약 60바이트 오버헤드를 더하고, OpenVPN의 UDP 모드도 같은 범위이고, IPsec은 모드와 알고리즘에 따라 달라진다. 그 바이트는 바깥 경로의 예산에서 나오는 것이지 허공에서 생기지 않는다.

그래서 터널 헤더가 붙는 순간 1500바이트 바깥 링크는 1500바이트 내부 패킷을 나를 수 없다.

계산은 한 번 해 볼 가치가 있다. 1500바이트 경로에서 WireGuard 인터페이스는 캡슐화된 패킷이 들어가도록 1420 근처의 MTU를 원한다. 내부 인터페이스를 9000으로 두면 모든 큰 패킷이 터널이 할 수 없는 단편화를 필요로 하거나 버려진다.

경로상 가장 작은 링크를 찾아라

경로를 따라가며 가장 낮은 MTU를 찾아라. LAN은 보통 1500이나 9000이고, WAN은 보통 1500이며, 모바일이나 PPP 링크는 더 낮을 수 있다. 그다음 터널 오버헤드를 빼라. 결과가 내부 인터페이스의 MTU보다 작다면 답이 나온 것이다. 경로 MTU 탐색이 이를 자동으로 찾을 수 있지만, 그것이 의존하는 ICMP 메시지가 통과할 때만 그렇다.

ICMP가 필터링되면 작은 요청은 잘 되는데 큰 전송이 멈추는 것이 전형적인 이유다.

변경을 넓히지 않고 크기 의존성을 시험하라

대표적인 전송을 쓰고 원래 값을 보관해 되돌릴 수 있게 하라. ping -M do -s 1472는 DF 비트를 세운 1500바이트 패킷을 시험하고, 통과할 때까지 크기를 줄여라. 큰 패킷만 실패한다면 경로가 아니라 크기 문제다.

캡처를 읽을 때 호스트 쪽 오프로드를 조심하라. 세그먼테이션 오프로드는 실제로 선로를 지난 것보다 훨씬 큰 프레임을 보여 줄 수 있어, 잘 도는 경로가 고장 나 보이고 고장 난 경로가 멀쩡해 보인다.

큰 MTU가 올바른 설계일 때

통제된 사설망이라면 경로의 모든 장비가 동의하고 터널 오버헤드가 계산에 들어간다는 조건에서 더 큰 프레임을 끝에서 끝까지 정당하게 돌릴 수 있다. 그것은 링크마다 문서화된 값을 가진 조율된 설계이지, 클라이언트에 입력하는 숫자 하나가 아니다.

일반적인 공용 출구라면 1500 이하로 가정하고 터널이 안전한 내부 MTU를 고르게 하라. RFC 8201은 IPv6의 경우에 대한 경로 MTU 탐색을 다루며, 피드백이 어떻게 동작해야 하는지에 관한 유용한 참고 자료다.