리눅스 네트워크 진단 · 경로와 MTU · 이론

작은 요청은 되고 큰 응답은 멈춘다

LabHub 에서 이어서 보기

한 줄 요약

curl 로 헤더는 오는데 본문에서 멈춘다면, 십중팔구 MTU 블랙홀입니다.
연결이 되는 것과 큰 패킷이 지나가는 것은 다른 문제입니다.

왜 이게 필요했나

이런 증상은 사람을 아주 오래 붙잡습니다.

curl -I (헤더만) → 즉시 성공
curl (전체) → 몇 초 멈췄다가 타임아웃
작은 API 응답은 정상, 목록 조회만 실패
VPN 을 켜면 재현되고 끄면 안 됨

"연결은 되는데" 라서 방화벽을 의심하지 않고, "가끔 되니까" 라서 DNS 도
아니라고 판단합니다. 원인은 경로 어딘가에서 **큰 패킷이 조용히 버려지는
것**입니다.

MTU 와 PMTUD

MTU(Maximum Transmission Unit)는 한 번에 보낼 수 있는 패킷의 최대 크기
입니다. 이더넷은 보통 1500 바이트입니다.

문제는 경로 중간에 더 작은 MTU 를 가진 구간이 있을 때입니다.

클라이언트(1500) → 라우터 → VPN 터널(1400) → 서버(1500)

TCP 는 연결할 때 서로 "나는 1460바이트까지 받을 수 있다(MSS)" 고 알립니다.
하지만 이건 양 끝의 사정이지 중간 구간의 사정이 아닙니다.

정상이라면 이렇게 동작합니다 — 1500바이트 패킷이 1400 구간에 도달하면,
그 라우터가 ICMP "Fragmentation Needed" 를 보내 "너무 크다, 1400으로
줄여라" 라고 알려 줍니다. 발신자가 크기를 줄여 다시 보냅니다. 이 과정을
Path MTU Discovery 라고 합니다.

블랙홀은 ICMP 를 막을 때 생긴다

많은 조직이 "ICMP 는 위험하다" 며 방화벽에서 전부 막습니다. 그러면
이렇게 됩니다.

1. 큰 패킷이 작은 MTU 구간에 도달
2. 라우터가 버리고 ICMP 를 보냄
3. ICMP 가 방화벽에서 차단됨
4. 발신자는 아무 소식도 못 듣고 계속 같은 크기로 재전송
5. 영원히 실패. 에러 메시지도 없음

이게 PMTUD 블랙홀입니다. 작은 패킷(핸드셰이크, 헤더 요청)은 통과하고
큰 패킷(본문)만 사라지니 증상이 그렇게 헷갈리는 것입니다.

진단 — 특권 없이 확인하는 법

ping -M do -s 로 크기를 바꿔 가며 재는 것이 교과서적 방법이지만,
ping 은 NET_RAW capability 가 필요해 잠긴 환경에서는 쓸 수 없습니다.
다행히 다른 길이 있습니다.

1. 경로와 MTU 를 확인한다

ip route get 8.8.8.8# 8.8.8.8 via 10.0.0.1 dev eth0 src 10.0.0.5ip -o link show          # 각 인터페이스의 mtu 값cat /sys/class/net/eth0/mtu

2. 응답 크기를 바꿔 가며 재현한다

curl -s -o /dev/null -w '%{size_download} %{time_total}\n' \  'https://api.example.com/items?limit=1'curl -s -o /dev/null -w '%{size_download} %{time_total}\n' \  'https://api.example.com/items?limit=1000'

작은 응답만 성공한다면 강한 신호입니다.

3. 헤더와 본문을 나눠 본다

curl -I https://target/            # 헤더만 → 성공?curl --max-time 5 https://target/  # 전체 → 멈춤?

4. 소켓 상태를 본다

ss -tin dst 10.0.3.20# ... mss:1460 ... retrans:0/14 ...

retrans 가 계속 늘어나면 같은 패킷을 반복해서 보내고 있다는 뜻입니다.
MTU 블랙홀의 전형적인 지문입니다.

대응

| 대응 | 방법 | 비고 |
| --- | --- | --- |
| ICMP 를 허용 | 방화벽에서 type 3 code 4 만이라도 열기 | 근본 해결 |
| 인터페이스 MTU 하향 | ip link set eth0 mtu 1400 | 특권 필요 |
| MSS 클램핑 | 라우터/방화벽에서 MSS 를 경로에 맞춤 | 흔한 현장 해법 |
| 애플리케이션 응답 축소 | 페이지네이션 | 우회일 뿐 |

현장에서 가장 자주 쓰이는 건 MSS 클램핑입니다. 게이트웨이가 TCP
핸드셰이크의 MSS 값을 경로 MTU 에 맞게 낮춰 주면, 애초에 큰 패킷이
만들어지지 않습니다.

라우팅도 함께 본다

MTU 가 아닌 경우도 있습니다. ip route get 이 예상과 다른 인터페이스를
가리키면 경로 자체가 문제입니다.

ip route get 10.0.5.10# dev eth1 이 나온다면 — eth0 로 갈 줄 알았는데 아니었다ip rule show           # 정책 라우팅이 있는가ip route show table all

VPN 을 켜면 기본 경로가 통째로 바뀌는 경우가 흔하고, 그때 사내망으로
가야 할 트래픽이 VPN 으로 빠지거나 그 반대가 됩니다.

현장에서 만나는 모습

VPN 접속자만 파일 다운로드가 멈춤 → 터널 MTU + ICMP 차단.
클라우드 이전 후 특정 API 만 타임아웃 → 오버레이 네트워크의 MTU 감소.
컨테이너에서만 재현 → CNI 의 MTU 설정이 호스트와 다름.

이어지는 퀴즈에서 확인할 것

작은 요청만 성공하는 현상이 왜 MTU 블랙홀을 가리키는지, ss -tin의
재전송 증가를 다른 정상 지표와 구분할 수 있는지 확인합니다.