ping은 되는데 웹 페이지가 반쯤 뜨다가 멈춘다. 개발팀은 "서버 문제 아니냐"고 하고, 네트워크팀은 "연결은 되는데 우리 쪽 문제 아니다"라고 한다. 저도 처음 이 증상을 마주쳤을 때 정확히 그 상황이었습니다. VPN 터널 구축 직후 벌어진 일이었는데, 원인은 MTU 불일치였습니다. 이 글은 그때 배운 것들을 정리한 기록입니다.
증상 파악: ping은 되는데 HTTP가 안 되는 이유
네트워크 트러블슈팅에서 가장 헷갈리는 유형이 바로 이겁니다. 연결 자체는 살아 있는데 특정 동작만 안 되는 상황. 저는 VPN 터널을 구축한 직후 내부망에서는 멀쩡하던 웹 애플리케이션이 특정 페이지에서 화면이 반만 뜬 채 멈추는 현상을 겪었습니다. DNS 조회도 되고 작은 API 요청도 잘 됐습니다. 그런데 이미지나 대용량 응답이 포함된 페이지만 문제였습니다.
이 패턴을 보면 경험 있는 엔지니어라면 MTU(Maximum Transmission Unit)를 의심하게 됩니다. MTU란 네트워크 인터페이스가 한 번에 전송할 수 있는 패킷의 최대 크기를 의미합니다. 이더넷 기준 기본값은 1500바이트인데, VPN이나 GRE 같은 터널링 기술이 개입하면 오버헤드가 붙어 실제로 전송 가능한 크기가 줄어들게 됩니다.
진단의 첫 단계는 인터페이스 MTU를 확인하는 것입니다. ip link show 명령으로 각 인터페이스 값을 확인하고, ping에 DF(Don't Fragment) 비트를 설정한 채 다양한 크기의 패킷을 보내봅니다. DF 비트란 패킷을 중간에 쪼개지 말라고 지시하는 플래그로, 이 옵션이 있어야 MTU 한계를 정확히 측정할 수 있습니다. 저희 케이스에서는 1472바이트까지는 응답이 왔지만 그 이상은 묵묵부답이었습니다. GRE 터널 오버헤드 24바이트가 문제였습니다. 숫자를 직접 계산하지 않고 "아마 이 정도겠지"라고 넘어갔다면 원인을 한참 찾았을 겁니다.
PMTUD 블랙홀: 방화벽이 조용히 망가뜨리는 것
MTU 문제가 이렇게 진단하기 어려운 데는 PMTUD(Path MTU Discovery) 실패가 결정적인 역할을 합니다. PMTUD란 송신 측이 목적지까지의 경로에서 허용되는 최대 패킷 크기를 자동으로 파악하는 메커니즘을 말합니다. 정상적으로 동작한다면 큰 패킷이 막혔을 때 라우터나 게이트웨이가 ICMP Type 3, Code 4 메시지, 즉 "Fragmentation Needed"를 돌려보내주고 송신 측이 알아서 패킷 크기를 줄입니다. (IETF RFC 1191)
그런데 문제는 ICMP를 전부 막아버리는 방화벽 정책이 생각보다 많은 현장에 존재한다는 것입니다. 저도 Wireshark로 패킷을 캡처해보니 서버 측은 TCP 세그먼트를 1460바이트씩 정상적으로 내보내고 있었습니다. 그런데 클라이언트에는 도달하지 않고 있었고, ICMP unreachable 응답도 전혀 없었습니다. 방화벽 정책을 열어보니 "ICMP 전체 차단"이 걸려 있었습니다. 이 상태를 PMTUD 블랙홀(Blackhole Routing)이라고 부르는데, 패킷이 조용히 사라지기만 하고 아무런 오류 신호도 없어서 애플리케이션 입장에서는 그냥 응답 없음으로 처리됩니다.
이게 개발팀과 네트워크팀이 서로 "우리 쪽 아니다"를 외치는 핵심 이유입니다. 증상이 딱 애플리케이션 문제처럼 보이거든요. 저는 이 구조를 처음 이해했을 때 "아, 이래서 핑퐁이 생기는구나" 싶었습니다. 네트워크 팀과 개발 팀 사이에서 며칠째 회의만 하던 상황이 한 줄의 Wireshark 분석으로 정리됐습니다. 방화벽 정책을 수정해 ICMP unreachable 메시지만 선택적으로 허용하면 PMTUD가 다시 살아납니다. 이것이 근본 해결책이지만, 현실에서는 정책 변경 승인이 쉽지 않은 경우도 많습니다. 저도 그 과정에서 네트워크팀과 보안팀을 설득하는 데 기술적인 시간보다 더 오래 걸렸습니다.
MSS 클램핑: 방화벽 못 건드릴 때의 현실적인 해법
방화벽 정책을 바꾸기 어려운 환경이라면 MSS 클램핑을 적용하는 것이 현실적인 대안입니다. MSS(Maximum Segment Size)란 TCP 연결에서 한 번에 주고받을 수 있는 데이터의 최대 크기를 의미합니다. MTU에서 IP 헤더(20바이트)와 TCP 헤더(20바이트)를 뺀 값이 기본 MSS가 됩니다.
MSS 클램핑은 TCP 연결 수립 시 주고받는 SYN 패킷의 MSS 값을 강제로 낮춰버리는 방식입니다. 이렇게 하면 ICMP 메시지 없이도 처음부터 작은 크기로 통신하게 되므로 단편화 문제가 원천 차단됩니다. 리눅스에서는 iptables의 TCPMSS 타겟으로 적용합니다. VPN 게이트웨이에 적용할 핵심 포인트를 정리하면, SYN 패킷 MSS를 경로 MTU에 맞게 자동 조정하거나 GRE 터널 오버헤드(24바이트)가 있는 환경에서는 1452 전후로 값을 잡는 것이 안전합니다. Cisco 라우터 환경이라면 해당 인터페이스에 ip tcp adjust-mss 명령으로 동일한 효과를 적용할 수 있습니다.
저는 이 설정을 VPN 게이트웨이에 적용하자마자 문제가 됐던 웹 페이지가 정상 로딩되는 걸 봤습니다. 솔직히 이건 예상보다 빠른 효과였습니다. MSS 클램핑이 근본 원인을 없애는 방법은 아니지만, 운영 환경에서 즉각적인 서비스 복구가 필요할 때는 이만한 방법이 없습니다. 다만 이것만 믿다 보면 구성이 변경될 때 다시 문제가 생기는 경우를 몇 번 경험했습니다. MSS 클램핑과 ICMP 정책 수정을 병행하는 게 가장 안정적이었습니다. 단기 처방과 근본 해결책을 함께 가져가야 한다는 교훈이었습니다.
검증과 장기 모니터링: 고쳤다고 끝이 아닙니다
변경을 적용하고 나서 "됐다"고 끝내버리는 경우가 많은데, 제 경험상 이게 나중에 재발의 원인이 됩니다. 반드시 실제 트래픽으로 검증하고, 모니터링 체계를 갖춰야 합니다.
검증 단계에서는 iperf3로 처리량을 측정하고, Wireshark로 TCP 세그먼트 크기가 실제로 조정됐는지 확인합니다. 특히 소용량 API 요청뿐만 아니라 대용량 파일 전송도 함께 테스트해야 합니다. 작은 패킷은 어차피 MTU 한계에 걸리지 않아서 문제가 드러나지 않기 때문입니다. 2020년 IETF에서 발표한 RFC 8899는 QUIC 같은 UDP 기반 프로토콜에서의 PMTUD 문제를 다루며, 앞으로 클라우드 환경에서 이 이슈가 더 복잡해질 것을 시사합니다.
장기적으로는 PRTG나 Zabbix 같은 네트워크 모니터링 툴에 MTU 불일치로 인한 TCP 재전송률(Retransmission Rate) 지표를 추가하는 것이 좋습니다. 재전송률이 갑자기 올라가는 구간이 보이면 MTU 문제를 의심할 수 있는 조기 신호가 됩니다. 저는 이 지표를 추가한 이후로 실제로 MTU 관련 이슈를 서비스 장애가 생기기 전에 미리 잡은 적이 두 번 있었습니다.
저는 MTU를 운영 중 트러블슈팅 항목이 아니라 설계 단계에서부터 고려해야 할 요소로 봐야 한다고 생각합니다. 클라우드 하이브리드 환경이 많아지면서 온프레미스와 클라우드 사이에 VXLAN, IPsec, GRE 같은 터널링 레이어가 중첩되는 구성이 늘고 있고, 그만큼 MTU 오버헤드 계산 실수가 서비스 장애로 이어지는 사례도 함께 늘고 있습니다. 이 부분을 설계 체크리스트에 항목으로 넣지 않는 팀을 여전히 자주 봅니다.
MTU 문제는 증상이 애매해서 사람을 지치게 만드는 유형입니다. ping이 되니 네트워크는 산 거고, 개발 코드엔 이상이 없으니 개발자도 억울하고, 결국 아무도 원인을 못 찾고 재부팅으로 때우다 반복되는 경우를 여러 번 봤습니다. 처음 의심할 수 있는 눈을 키우는 것이 전부입니다. VPN이나 터널을 새로 붙였다면, 그 시점부터 MTU부터 확인하는 습관을 들이시길 권합니다.
출처 및 참고
'IT적응기' 카테고리의 다른 글
| 홈서버 외부접속 (포트포워딩, CG-NAT, Tailscale) (0) | 2026.04.19 |
|---|---|
| MTU 최적화 (단편화, MSS 클램핑, 점보 프레임) (0) | 2026.04.18 |
| 컨테이너 네트워킹 (Bridge, Overlay, CNI) (0) | 2026.04.17 |
| SDN 입문 (제어평면 분리, 컨트롤러, 프로그래머블 네트워크) (0) | 2026.04.17 |
| SDN 네트워크 (컨트롤 플레인, 트래픽 엔지니어링, 단일 장애점) (0) | 2026.04.16 |
