WireGuard MTU를 고르는 주체: wg-quick, 커널, 아니면 당신

WireGuard에는 MTU 협상이 없다. 인터페이스가 넘겨준 것을 그대로 암호화해 보내고, 캡슐화된 패킷이 경로를 넘으면 보이지 않는 어딘가에서 버려지거나 조각난다. 인터페이스의 MTU는 누군가 골라야 하며, 그 누군가는 인터페이스를 올린 도구다.

후보는 세 가지이며, 서로 혼동하기 쉽다.

값이 나올 수 있는 세 곳

값은 인터페이스 설정에서 명시적으로 지정할 수 있고, 설정 도구가 경로 정보로 계산할 수도 있으며, 인터페이스를 소유한 네트워크 관리자가 지정할 수도 있다. 평범한 wg 호출은 wg가 키와 피어만 관리하기 때문에 이 중 어느 것도 하지 않는다. MTU는 네트워크 인터페이스에 살기 때문에 ip link show wg0가 그 값을 읽는 곳이다.

어느 경우인지 확실하지 않으면 먼저 MTU를 읽고, 그다음 인터페이스를 누가 시작했는지 알아내라.

인터페이스를 누가 운용하는지로 판단하라

wg-quick이 시작한다면 명시적인 MTU 행이 우선하고, 아니면 값을 계산한다. 네트워크 관리자가 시작한다면 그 관리자의 프로필이 결정한다. 컨테이너 런타임이나 공급자 클라이언트가 시작한다면 wg-quick의 동작을 가정하지 말고 그쪽 문서를 읽어라.

결정은 추상적으로 어느 숫자가 최선인가가 아니다. 실제로 어떤 구성 요소를 설정할 수 있는가다.

기본 계산이 하는 일

wg-quick은 피어의 엔드포인트까지 경로를 찾아 그 출력 인터페이스의 MTU를 가져오고 캡슐화 오버헤드를 뺀다. 외부 헤더가 IPv4면 약 60바이트, IPv6면 약 80바이트다. 결과는 상한이 걸려 1500바이트 경로에서 1420이 나오며, 한 주소 체계에서만 통하는 값이 되지 않는다. 이것은 합리적인 기본값이지 당신 경로의 측정값이 아니다.

나중에 생기는 터널, 모바일 링크, 또는 필터링된 ICMP 경로는 알 수 없다.

이 상한은 진짜 질문을 가린다. 경로가 정말 처음부터 끝까지 9000바이트라면 1420은 성능을 탁자 위에 남기고, 경로가 1400이라면 1420은 이미 너무 크다. 기본값은 타협이며, 그렇게 다뤄야 한다.

경로가 당신 아래에서 바뀔 때

이더넷에서 Wi-Fi로, 다시 휴대폰 핫스팟으로 옮겨 다니는 노트북은 시작할 때의 인터페이스 MTU를 그대로 유지한다. 바깥 경로는 이제 더 작을 수 있고, 아무것도 다시 협상하지 않는다. 터널을 겹치면 각 계층이 같은 예산에서 자기 오버헤드를 빼기 때문에 더 나빠진다. 사무실에서 통하던 값이 공항에서 통하는 값은 아니다.

최근의 핸드셰이크는 키가 동작함을 증명한다. 큰 패킷이 들어가는지는 아무것도 증명하지 않는다.

한 번에 숫자 하나만 시험하라

같은 애플리케이션과 목적지를 유지한 채 값 하나만 바꾸고 측정하라. ping -M do -s 1372는 DF 비트를 세운 1400바이트 패킷을 시험하며, 이것이 원하는 시험 형태다. 작은 요청은 되고 큰 요청이 멈춘다면 경로 문제가 아니라 크기 문제다.

MTU만 바꿔라. 여러 패킷 옵션을 한꺼번에 조정하면 어느 것이 중요했는지 알 수 없다.

그리고 MTU 변경이 빠진 반환 경로, 포워딩 규칙, DNS 실패를 고쳐 주리라 기대하지 마라. 그것들도 트래픽이 없는 증상을 만들며 각자의 시험이 있다. wg-quick 매뉴얼에 자동 선택이 문서화되어 있다.