MTU 1420: 일부 사이트가 멈추는 이유와 해결 방법

MTU는 네트워크에서 단편화 없이 전송할 수 있는 최대 패킷 크기예요. 이더넷에서 일반적인 값은 1500바이트예요. 트래픽이 터널을 통과하면 터널 자체의 헤더가 공간의 일부를 차지해서 페이로드가 줄어들어요. 일반적인 값은 1420이에요.

그 자체로는 문제가 되지 않아요. 문제는 한쪽이 1500을 보낼 수 있다고 믿는데 경로 상에 1420인 구간이 있고, 그 사실을 알리는 메시지가 유실될 때 시작돼요.

증상은 이렇게 나타나요

• SSH는 연결되고 인사말도 도착하지만, 큰 디렉터리에서 ls를 실행하면 세션이 멈춰요.
• 페이지가 로딩을 시작하다가 중간에 멈춰요.
• curl -I(헤더만)는 작동하지만 전체 curl은 멈춰요.
• apt update는 성공하지만 apt upgrade는 다운로드 중에 멈춰요.
• 작은 요청은 잘 오가지만 큰 응답은 도착하지 않아요.

공통된 징후는 같아요. 작은 패킷은 통과하고, 큰 패킷은 오류 없이 사라져요. 연결이 끊기지는 않고, 그저 조용해질 뿐이에요.

원인은 패킷 크기 협상 메커니즘이 ICMP 서비스 메시지에 의존하기 때문이에요. 경로 상에서 누군가 이 메시지를 필터링하면, 송신자는 패킷이 너무 크다는 사실을 알지 못한 채 계속 다시 보내요.

확인

단편화 금지 비트를 설정한 패킷을 보내고, 통과할 때까지 크기를 줄여보세요.

ping -M do -s 1472 -c 2 1.1.1.1
ping -M do -s 1392 -c 2 1.1.1.1

-s 크기에는 헤더 28바이트가 더해져요. 1472는 MTU 1500에, 1392는 MTU 1420에 해당해요. 첫 번째 옵션이 실패하고 두 번째가 성공하면 한계를 찾은 거예요.

현재 인터페이스 값은 이렇게 확인해요.

ip link show
ip route get 1.1.1.1

해결 방법

일회성 확인:

ip link set dev eth0 mtu 1420

systemd-networkd를 통한 영구 설정 — 파일 /etc/systemd/network/10-eth0.network:

[Match]
Name=eth0

[Link]
MTUBytes=1420

systemctl restart systemd-networkd

NetworkManager가 네트워크를 관리한다면:

nmcli connection modify "System eth0" 802-3-ethernet.mtu 1420
nmcli connection up "System eth0"

MTU를 건드릴 수 없을 때 유용한 두 번째 방법은 경계에서 TCP 세그먼트 크기를 제한하는 거예요. nftables에서는 이렇게 해요.

tcp flags syn tcp option maxseg size set rt mtu

언제 영향을 받나요

Millida VDS 머신 자체에서는 네트워크가 제대로 구성되어 있어서 보통 MTU를 직접 건드릴 필요가 없어요. 직접 터널을 설정할 때 다뤄야 해요. WireGuard, OpenVPN, GRE, 사무실로 연결하는 VPN, 또는 머신 간 연결 같은 경우예요. 터널 내부에서는 MTU가 항상 더 작고, 명시적으로 설정해야 해요.

WireGuard의 [Interface] 섹션에서는 이렇게 해요.

MTU = 1420

흔한 실수

ping -M do 명령으로 증상을 재현하기 전까지는 MTU를 건드리지 마세요. 그 확인 없이 추측으로 작동하는 구성을 바꾸면, 기존 문제 대신 새로운 문제를 얻게 돼요. ICMP를 완전히 차단하지 마세요. nftables를 참고하세요.