ping 이 성공해도 서비스는 안 될 수 있다

한 줄 요약

ping 은 IP 계층까지의 도달성만 증명한다. 그 위의 포트도, 그 위의 애플리케이션도, 심지어 큰 패킷이 지나갈 수 있는지도 증명하지 않는다.

왜 이게 필요했나

"ping 은 되는데 접속이 안 돼요" 는 모순이 아니라 정상적인 상태다. ping 은 ICMP echo 를 주고받을 뿐이다. TCP 8080 이 열려 있는지는 전혀 다른 질문이고, 그 포트가 열려 있어도 애플리케이션이 5xx 를 뱉을 수 있다.

반대 방향도 중요하다. ping 이 실패해도 서비스는 멀쩡할 수 있다. 많은 조직이 ICMP echo 를 차단하기 때문이다. 그러니 "ping 이 안 되니 서버가 죽었다" 는 판단은 위험하다.

어떻게 동작하나

세 도구의 역할이 다르다.

| 도구 | 무엇을 보나 | 이 환경에서의 주의 |
| --- | --- | --- |
| ping | 목적지까지 IP 왕복이 되는가 | 동작함 (ping_group_range 허용) |
| traceroute | 어느 홉까지 가는가 | UDP 모드만 동작 (ICMP 모드는 raw socket 필요) |
| mtr | 홉별 손실률과 지연을 지속 관찰 | --udp 필요 |

traceroute 의 원리는 TTL 을 1부터 올려 가며 보내는 것이다. TTL 이 0이 된 지점의 라우터가 ICMP time exceeded 를 돌려주고, 그 출발지 주소가 곧 그 홉의 정체다. 그래서 traceroute 는 "경로를 조회하는" 것이 아니라 "일부러 실패시켜 응답을 모으는" 도구다.

*** * * 는 장애가 아니다.** 그 홉의 라우터가 ICMP 응답을 제한하거나 만들지 않는 것뿐이다. 판정 규칙은 이렇다.

• 중간 홉에서만 손실이 보이고 최종 목적지에서 손실이 없다면 ICMP rate limiting 일 가능성이 높다
• 특정 홉부터 지연이 급증한다면 그 구간이 병목이다
• 마지막 몇 홉에서 손실이 증가한다면 실제 문제일 가능성이 높다

ping 이 놓치는 것: 경로 MTU

가장 고약한 사례가 MTU 블랙홀이다. ping 은 기본 페이로드가 56바이트라 항상 통과한다. 그런데 응답이 조금만 커지는 API 는 그대로 멈춘다. 오류도 아니고 그냥 멈춘다. 크기가 임계값을 넘는 패킷만 사라지기 때문에 증상이 크기에 따라 갈린다.

확인은 조각화 금지 비트를 세운 ping 으로 한다.

ping -M do -s 1472 -c 1 10.20.0.5# From 10.0.1.1 icmp_seq=1 Frag needed and DF set (mtu = 1420)

-s 값에 28(ICMP 8 + IP 20)을 더한 것이 실제 MTU 다. 이분 탐색으로 통과 최대치를 찾으면 경로 MTU 가 나온다.

터널을 쓰면 오버헤드만큼 실효 MTU 가 줄어든다.

| 캡슐화 | 추가 헤더 | 실효 MTU | 권장 MSS 클램프 |
| --- | --- | --- | --- |
| PPPoE | 8 | 1492 | 1452 |
| GRE | 24 | 1476 | 1436 |
| VXLAN (IPv4) | 50 | 1450 | 1410 |
| WireGuard (IPv4) | 60 | 1440 | 1400 |
| IPsec ESP + NAT-T | 약 81 | 1419 | 1379 |

현장에서 만나는 모습

"VPN 을 켜면 특정 사이트만 안 열립니다." 터널 오버헤드로 실효 MTU 가 줄었는데 MSS 클램핑이 없는 전형적인 상황이다. 작은 페이지는 열리고 큰 페이지는 멈춘다. ping 은 100% 성공한다.

클라우드에서 ICMP 를 다 막아 놓고 traceroute 를 돌리는 경우. 전부 * * * 로 나와 "경로가 끊겼다" 고 결론 내리기 쉽다. 이때는 TCP 모드 traceroute(-T -p 443)나 nc -zv 로 목적 포트를 직접 두드리는 편이 정확하다.

다음 실습에서 할 것

인터페이스와 라우팅을 확인하고, ping 통계에서 손실률과 RTT 를 읽고, UDP 모드 traceroute 와 mtr 을 돌린다. 마지막에는 ICMP 는 되는데 TCP 는 어떤가 를 직접 비교해 표로 만든다.