[Network] 25. traceroute는 보이지 않는 길을 어떻게 보여줄까?

목차: [Network] TCP/IP를 우편 시스템으로 이해하기
TCP/IP를 우편 시스템으로 이해하기 — Part 8. 편지가 멈춘 곳을 찾는 법

ㅁ 들어가며

ping은 Destination까지 Echo가 왕복했는지 알려 준다.

하지만 중간에 어느 Router를 지났는지는 보여 주지 않는다.

그렇다면 traceroute는 Router의 Routing Table을 차례로 읽어 오는 것일까?

 

그렇지 않다.

Source는 Internet의 전체 지도를 요청할 수 없다.

대신 수명이 짧은 Probe를 보내 일부러 첫 Router에서 끝나게 하고, 다음 Probe는 두 번째 Router에서 끝나게 한다.

TTL 1인 Probe → 첫 번째 Router에서 만료
TTL 2인 Probe → 두 번째 Router에서 만료
TTL 3인 Probe → 세 번째 Router에서 만료

각 Router가 돌려준 ICMP 오류를 모으면 지나간 경로의 일부를 역으로 추론할 수 있다.

 

중요한 단어는 “조회”가 아니라 추론이다.

Router가 답하지 않을 수도 있고,

Probe마다 다른 길을 갈 수도 있으며,

ICMP Reply가 돌아오는 길도 Forward Path와 다를 수 있다.

 

이번 글에서는 TTL/Hop Limit, ICMP Time Exceeded, UDP·ICMP·TCP Probe, Hop RTT, Asymmetric Routing, ECMP, Rate Limiting, Paris Traceroute를 통해 결과가 보여 주는 범위와 빈칸의 의미를 살펴본다.

---

ㅁ traceroute는 왜 일부러 Packet을 만료시킬까?

IPv4 Packet의 TTL은 Router를 통과할 때마다 줄어든다.

Source가 TTL 3으로 전송
R1이 3 → 2
R2가 2 → 1
R3이 1 → 0

 

TTL이 0이 되면 R3은 Packet을 다음 Hop으로 전달하지 않고 폐기한다.

R3은 Source에 다음 ICMP 오류를 보낼 수 있다.

ICMP Time Exceeded
Type 11, Code 0
TTL Exceeded in Transit

Source는 오류를 보낸 Address를 보고 “TTL 3인 Probe가 이 지점에서 끝났다”는 단서를 얻는다.

traceroute는 정상 Packet의 TTL 만료를 기다리는 것이 아니라

TTL을 1부터 의도적으로 늘려 이 안전장치를 관찰 도구로 사용한다.

---

ㅁ 첫 번째 Hop은 어떻게 나타날까?

Source가 TTL 1인 Probe를 보낸다.

Source ── TTL 1 ──> R1

 

R1은 Forwarding 과정에서 TTL을 줄인다.

TTL 1 → 0

 

Probe는 R1을 넘어가지 못한다.

R1이 ICMP Time Exceeded를 보내면 traceroute의 첫 줄에 R1의 응답 Address와 RTT가 표시된다.

1  10.25.1.1  0.401 ms

여기서 1은 Router의 고유 번호가 아니다.

TTL 1인 Probe에 응답한 Hop이라는 뜻이다.

---

ㅁ 두 번째와 세 번째 Hop은 어떻게 찾을까?

다음 Probe의 TTL을 2로 설정한다.

Source ── TTL 2 ──> R1 ── TTL 1 ──> R2

 

R2에서 TTL이 0이 되고 Time Exceeded가 돌아오면 두 번째 Hop을 얻는다.

TTL 3도 같은 방식이다.

Source ── TTL 3 ──> R1 ── TTL 2 ──> R2 ── TTL 1 ──> R3

 

출력은 다음처럼 쌓인다.

1  10.25.1.1     0.401 ms
2  10.25.2.2     0.612 ms
3  10.25.3.2     0.811 ms

각 줄은 하나의 Packet이 모든 Hop을 지나며 남긴 흔적이 아니다.

 

TTL이 서로 다른 별개의 Probe와 Reply를 모은 결과다.

Hop 1 결과 → TTL 1 Probe
Hop 2 결과 → TTL 2 Probe
Hop 3 결과 → TTL 3 Probe

측정 도중 Route가 바뀌면 한 화면에 서로 다른 순간의 경로가 섞일 수 있다.

---

ㅁ Router는 원래 Probe의 무엇을 돌려줄까?

ICMP Time Exceeded에는 문제가 된 원래 IP Header와 상위 Protocol을 식별할 수 있는 원래 Packet 일부가 인용된다.

ICMP Time Exceeded
└─ Original Probe의 IP Header와 일부 Payload

 

traceroute는 인용된 정보를 보고 어느 TTL과 어느 Probe에 대한 응답인지 연결한다.

 

Probe 방식에 따라 다음 값이 단서가 될 수 있다.

• UDP Source와 Destination Port
• ICMP Identifier와 Sequence Number
• TCP Source와 Destination Port 및 Sequence 관련 정보

ICMP 오류가 도착했다는 사실만 보는 것이 아니라

내가 보낸 어느 Probe의 오류인가를 맞추는 과정이 필요하다.

NAT나 Firewall이 Tuple을 바꾸거나 인용 영역을 충분히 전달하지 않으면 매칭이 어려워질 수 있다.

---

ㅁ Destination에 도착한 Probe는 왜 끝나지 않을까?

TTL이 충분히 커지면 Probe는 Destination에 도착한다.

이제 TTL이 만료되지 않으므로 Destination이 다른 방식으로 최종 응답을 보내야 한다.

종료 응답은 Probe Protocol에 따라 다르다.

Classic UDP Probe
→ 닫힌 높은 UDP Port
→ ICMP Destination Unreachable, Port Unreachable

ICMP Echo Probe
→ ICMP Echo Reply

TCP SYN Probe
→ SYN-ACK 또는 RST

 

IPv4 UDP Port Unreachable은 일반적으로 다음 값이다.

ICMP Type 3, Code 3

 

목적지의 닫힌 Port 응답은 실패가 아니라 “Probe가 Destination까지 도착했다”는 종료 신호로 사용된다.

TCP Probe도 Port가 열려 있으면 SYN-ACK, 닫혀 있으면 RST가 돌아올 수 있다.

둘 다 Destination 도달의 단서가 된다.

---

ㅁ traceroute는 왜 운영체제마다 다르게 보일까?

전통적인 Unix 계열 traceroute는 높은 Destination Port의 UDP Probe를 사용하는 경우가 많다.

Windows tracert는 일반적으로 ICMP Echo Probe를 사용한다.

Linux의 여러 traceroute 구현은 Option으로 ICMP 또는 TCP Probe를 선택할 수 있다.

traceroute 기본값
→ 구현에 따라 UDP 등

tracert 기본값
→ ICMP Echo 계열

TCP traceroute
→ 선택한 TCP Port로 SYN Probe

같은 Source와 Destination이라도 Probe Protocol과 Port가 다르면

  Firewall Policy와 ECMP Hash가 달라져 결과도 바뀔 수 있다.

 

“내 traceroute와 상대의 traceroute가 다르다”는 사실을 비교하려면

  먼저 사용한 Protocol, Port, Address Family와 Source Address를 맞춰야 한다.

---

ㅁ 세 개의 시간은 같은 Packet을 세 번 측정한 것일까?

기본 출력에서 한 Hop에 세 개의 RTT가 보일 수 있다.

5  192.0.2.5  12.1 ms  13.4 ms  11.9 ms

일반적으로 같은 TTL을 가진 Probe를 세 번 따로 보내고 각 Reply 시간을 표시한 것이다.

TTL 5, Probe 1 → 12.1 ms
TTL 5, Probe 2 → 13.4 ms
TTL 5, Probe 3 → 11.9 ms

세 Probe가 반드시 같은 Route를 통과한다고 보장할 수 없다.

ECMP가 Transport Header를 Hash에 사용하면 Probe마다 Port가 달라져 다른 Next Hop을 선택할 수도 있다.

한 줄에 서로 다른 Router Address가 나타나는 이유가 될 수 있다.

5  192.0.2.5  12.1 ms  192.0.2.9  13.4 ms  192.0.2.5  11.9 ms

---

ㅁ Hop의 RTT는 어느 구간의 지연일까?

Hop 5의 12 ms는 Hop 4에서 Hop 5로 가는 Link가 12ms라는 뜻이 아니다.

Source
→ TTL 5 Probe가 Hop 5까지 이동
→ Hop 5가 ICMP를 생성·처리
→ ICMP가 Return Path로 Source까지 이동

즉, 해당 Probe의 Source부터 응답 Router까지의 왕복 시간이다.

다음 요소가 섞인다.

• Forward Path의 모든 Link와 Queue
• Router Control Plane의 ICMP 처리와 Scheduling
• ICMP Reply의 Return Path
• Source의 송수신 Scheduling

Hop 4가 10ms이고 Hop 5가 30ms라고 다음처럼 단정하면 안 된다.

Hop 4 → Hop 5 Link Delay = 30 - 10 = 20ms  (확정 불가)

각 Hop의 ICMP Reply가 다른 Return Path와 우선순위를 사용할 수 있기 때문이다.

---

ㅁ 중간 Hop만 느리고 뒤 Hop은 빠를 수 있을까?

다음 결과를 보자.

4  192.0.2.4  8 ms
5  192.0.2.5  80 ms
6  192.0.2.6  10 ms
7  198.51.100.20  11 ms

Hop 5가 지나가는 Data Packet을 80ms씩 늦췄다면 뒤 Hop도 누적된 지연의 영향을 받을 가능성이 크다.

그런데 Hop 6과 Destination RTT는 다시 10~11ms다.

이 패턴은 Hop 5가 Transit Forwarding은 빠르게 하면서 자신에게 향한 ICMP 생성만 낮은 우선순위로 처리했을 가능성을 보여 준다.

중간 Hop의 높은 RTT
+ 이후 Hop의 정상 RTT
→ 해당 Router의 ICMP Control Plane 우선순위 가능성

중간 한 줄의 큰 숫자만 보고 병목이라고 결론 내리지 않는다. 지연이 뒤 Hop과 Destination까지 지속되는지 함께 본다.

---

ㅁ 별표 하나는 무엇을 뜻할까?

정해진 시간 안에 해당 Probe의 응답을 받지 못하면 *가 표시될 수 있다.

5  *  *  *

별표가 직접 증명하는 것은 다음뿐이다.

해당 TTL의 Probe에 대응하는 응답을 Timeout 안에 관찰하지 못했다.

가능한 원인은 여러 가지다.

• Probe가 Forward Path에서 Drop
• Router가 Time Exceeded를 만들지 않음
• ICMP 생성이 Rate Limit
• ICMP Reply가 Return Path에서 Drop
• Firewall이 특정 Protocol이나 ICMP를 차단
• Reply가 Timeout 뒤 늦게 도착
• traceroute가 Reply를 원래 Probe와 매칭하지 못함

*는 Router가 없다는 표시도, 그 Router가 Down이라는 표시도 아니다.

---

ㅁ 별표 뒤에 다음 Hop이 다시 나타날 수 있을까?

가능하다.

4  192.0.2.4       8 ms
5  * * *
6  192.0.2.6      10 ms
7  198.51.100.20  11 ms

TTL 5인 Probe는 다섯 번째 Router에서 만료되었다. 그 Router가 Time Exceeded에 응답하지 않아 별표가 생겼다.

TTL 6인 다음 Probe는 다섯 번째 Router를 TTL이 남은 상태로 통과한다.

TTL 5 Probe
→ Hop 5에서 만료, ICMP 응답 없음

TTL 6 Probe
→ Hop 5 통과
→ Hop 6에서 만료, ICMP 응답 있음

Hop 5가 Transit Packet을 전달하지 못했다면 뒤 Hop도 보이기 어렵다.

뒤 Hop이 나타난다는 사실은 해당 지점이 Forwarding은 했지만 자신이 응답하지 않았을 가능성을 보여 준다.

---

ㅁ 모든 별표 뒤가 비어 있으면 어디가 끊겼을까?

다음 결과를 보자.

1  10.0.0.1       1 ms
2  192.0.2.1      5 ms
3  * * *
4  * * *
5  * * *
...

마지막 응답 Hop 다음에서 Data Forwarding이 실패했을 수 있다.

하지만 다음 가능성도 남는다.

• 그 뒤 경로 전체가 ICMP Time Exceeded를 차단
• Probe Protocol 자체가 Firewall에서 차단
• Return Path의 ICMP가 Source로 오지 못함
• Destination까지 전달되지만 종료 응답이 차단
• Maximum Hop 안에 Destination에 도달하지 못함

“마지막으로 보인 Router가 문제”라고 단정하면 안 된다.

마지막 응답 Router는 자신이 응답할 수 있었다는 증거일 뿐, 바로 다음 Link에서 Drop했음을 증명하지 않는다.

---

ㅁ Forward Path와 ICMP Return Path는 같을까?

TTL 5 Probe가 Router R5에서 만료되었다.

Probe Forward Path
Source → R1 → R2 → R3 → R4 → R5

R5의 ICMP Time Exceeded는 별도의 IP Packet이다. Source로 돌아가기 위해 R5의 Routing Table을 사용한다.

ICMP Return Path
R5 → X3 → X2 → X1 → Source

traceroute 한 줄의 Address는 Forward Probe가 만료된 지점의 응답 Source다.

그러나 RTT에는 Probe의 Forward Path와 ICMP의 Return Path가 함께 들어 있다.

화면에 보이는 Hop 목록
≠ Reply Return Path까지 모두 펼친 지도

Destination에서 Source 방향으로 실행한 Reverse Traceroute도 원래 Return Path와 같다고 보장할 수 없다. Source Address, Policy와 ECMP Hash가 달라질 수 있다.

---

ㅁ 응답 Address는 Router의 어느 Interface일까?

Router에는 여러 Interface Address가 있다.

R5
├─ Probe가 들어온 Interface Address
├─ Probe가 나가려던 Interface Address
├─ ICMP가 Source로 돌아갈 Interface Address
└─ Loopback Address

ICMP Time Exceeded의 Source Address 선택은 구현과 Route에 따라 달라질 수 있다.

출력된 Address가 반드시 Probe가 들어온 Interface이거나 Source와 직접 연결된 Link Address라고 단정할 수 없다.

Router의 한 Address만 보고 장비 위치와 소유자를 확정하기 어려운 이유다.

---

ㅁ 이름이 보이면 Router의 정체를 알 수 있을까?

기본 traceroute는 응답 IP의 Reverse DNS(PTR)를 조회해 이름을 표시할 수 있다.

5  edge-seoul.example.net (192.0.2.5)  12 ms

PTR 이름은 운영자가 붙인 Label이다.

유용한 단서가 될 수 있지만 물리 위치, 장비 역할과 소유권을 암호학적으로 증명하지 않는다.

Reverse DNS 조회가 느리거나 실패하면 traceroute 출력 자체가 늦게 보일 수도 있다.

숫자 Address만 빠르게 보려면 구현에 따라 -n Option을 사용한다.

traceroute -n 198.51.100.20

Windows에서는 tracert -d처럼 다른 Option을 사용한다.

---

ㅁ ECMP는 한 Hop에 여러 주소를 어떻게 만들까?

Router가 같은 Destination Prefix로 비용이 같은 Next Hop을 여러 개 가지고 있다고 하자.

            ┌→ Path A
Source → R1 ┤
            └→ Path B

ECMP는 일반적으로 Flow의 5-Tuple 같은 Header 값을 Hash해 한 Flow의 Next Hop을 선택한다.

Classic UDP traceroute가 Probe마다 Destination Port를 바꾸면 ECMP Hash도 달라질 수 있다.

TTL 5 Probe 1, UDP Dst Port 33450 → Path A
TTL 5 Probe 2, UDP Dst Port 33451 → Path B
TTL 5 Probe 3, UDP Dst Port 33452 → Path A

한 번의 출력에 실제로 동시에 사용되지 않은 여러 Flow의 경로가 섞일 수 있다.

Paris Traceroute 계열의 접근은 Flow Identifier를 일정하게 유지하면서 Probe를 구분해 Per-Flow Load Balancing이 만든 경로 혼합을 줄이려 한다.

그래도 Per-Packet Load Balancing, Route 변화와 Reply Path 차이까지 모두 제거하는 것은 아니다.

---

ㅁ 실제 HTTPS와 같은 길을 시험하려면 TCP 443이면 충분할까?

UDP traceroute가 차단되고 TCP 443은 허용되는 Network가 있다.

TCP Probe를 Destination Port 443으로 보내면 실제 HTTPS와 더 비슷한 Firewall Policy와 ECMP 입력을 사용할 수 있다.

Linux 구현의 예시는 다음과 같다.

sudo traceroute -T -p 443 -n server.example

하지만 완전히 같은 Flow라고 보장할 수는 없다.

• Source Port가 실제 Application 연결과 다를 수 있다.
• Probe의 TCP Flag와 Option이 실제 TLS 연결과 다르다.
• Route가 측정 사이에 바뀔 수 있다.
• Load Balancer가 Application 상태에 따라 다른 Backend를 선택할 수 있다.
• Destination의 SYN-ACK 또는 RST Policy가 다를 수 있다.

Probe Protocol을 실제 Traffic과 가깝게 맞추는 것은 가설을 개선하지만 실제 Application Packet의 완전한 복제는 아니다.

---

ㅁ UDP, ICMP, TCP 결과가 다르면 어느 것이 맞을까?

세 결과가 서로 다를 수 있다.

UDP traceroute  → Hop 4부터 별표
ICMP traceroute → Destination까지 표시
TCP 443 trace   → Destination까지 표시

이는 하나가 거짓이고 하나가 참이라는 뜻이 아니다.

각 Probe가 다른 Policy와 Hash 조건을 통과했을 수 있다.

UDP 결과
→ UDP Probe의 관찰 경로와 응답 정책

ICMP 결과
→ ICMP Echo Probe의 관찰 경로와 응답 정책

TCP 결과
→ 해당 TCP Port Probe의 관찰 경로와 응답 정책

문제가 HTTPS라면 TCP 443 결과에 더 무게를 둘 수 있지만 실제 curl과 Packet Capture 증거를 함께 봐야 한다.

---

ㅁ MPLS와 Tunnel은 Hop을 숨길 수 있을까?

IP Packet이 MPLS나 Tunnel 구간을 지날 때 내부 Hop의 TTL 또는 Hop Limit이

외부 Header와 어떻게 연동되는지는 구성에 따라 다르다.

IP Router → Tunnel Ingress ═════ Tunnel Egress → IP Router
                         내부 Hop 여러 개

Tunnel 내부 Router가 traceroute에 모두 나타날 수도 있고 하나의 긴 구간처럼 숨을 수도 있다.

MPLS Label 정보가 ICMP Extension으로 보이는 환경도 있지만 모든 장비가 제공하는 것은 아니다.

따라서 Hop 수가 적다고 물리 장비와 전달 단계가 반드시 적은 것은 아니다.

Overlay Network에서는 Virtual Router와 Underlay Router의 경로를 별도로 관찰해야 할 수 있다.

---

ㅁ NAT를 지나면 Probe 연결 정보는 어떻게 달라질까?

NAT는 Probe의 Source Address와 UDP/TCP Port, ICMP Identifier를 바꿀 수 있다.

Return ICMP에는 변환 전후 Tuple을 연결할 State가 필요하다.

내부 Probe
10.0.0.10:33450
        ↓ NAT
203.0.113.5:40001

정상적인 Stateful NAT는 ICMP 오류에 인용된 외부 Tuple을 내부 Probe와 연결해 Source로 돌려줄 수 있다.

하지만 Fragment, 짧은 ICMP 인용, Timeout과 비대칭 경로 때문에 매칭이 실패할 수 있다.

일부 NAT 경계가 Hop으로 보이거나 내부 Address가 ICMP Payload에 남는 등 구현별 결과도 나타날 수 있다.

---

ㅁ Routing Loop는 어떤 모습으로 나타날까?

R1과 R2가 Destination Route를 서로에게 가리킨다고 하자.

TTL을 늘린 Probe는 두 Router 사이에서 반복해서 만료된다.

4  192.0.2.1
5  192.0.2.2
6  192.0.2.1
7  192.0.2.2
8  192.0.2.1

같은 Address가 번갈아 반복되는 패턴은 Routing Loop의 강한 단서다.

그러나 Address 반복 하나만으로 확정하지 않는다.

• ICMP Source Address 선택 때문에 같은 Address가 여러 위치처럼 보일 수 있다.
• ECMP Probe가 서로 다른 Path를 오갈 수 있다.
• NAT와 Tunnel이 Address 표시를 바꿀 수 있다.

실제 Router의 Route Lookup, TTL별 Capture와 Interface Counter로 확인해야 한다.

TTL을 크게 늘리는 것은 Loop를 고치지 않고 Packet이 더 오래 돌게 할 뿐이다.

---

ㅁ 경로가 실행할 때마다 바뀌면 장애일까?

Internet Routing과 Load Balancing은 동적이다.

첫 실행: A → B → C → Destination
다음 실행: A → D → E → Destination

변화 가능한 원인은 다음과 같다.

• ECMP Hash 입력 변화
• BGP 또는 IGP Route 변화
• Anycast Site 선택 변화
• Link 장애와 Convergence
• Traffic Engineering Policy
• Mobile과 VPN 경로 전환

경로가 다르다는 사실만으로 장애라고 할 수 없다.

변화 시점과 Packet Loss, Destination RTT, Application Error가 함께 발생했는지 시간축으로 연결한다.

---

ㅁ !H, !N, !X 같은 표시는 무엇일까?

일부 traceroute 구현은 ICMP 오류 Code를 짧은 기호로 표시한다.

!N  Network Unreachable
!H  Host Unreachable
!P  Protocol Unreachable
!X  Communication Administratively Prohibited
!F  Fragmentation Needed 관련 표시 가능

정확한 기호와 의미는 구현마다 다르다.

이 표시는 응답 장비가 명시적인 오류를 보냈다는 단서다.

오류를 보낸 Source Address와 인용된 Probe, Type과 Code를 Capture에서 확인한다.

!H가 보였다고 반드시 최종 Destination Host가 자신이 Down이라고 답한 것은 아니다. 중간 Router가 다음 Hop에 전달하지 못해 오류를 만들 수 있다.

---

ㅁ IPv6 traceroute는 무엇을 바꿀까?

IPv6에서는 TTL 대신 Hop Limit을 사용한다.

Hop Limit이 Transit 중 0이 되면 Router는 다음 ICMPv6 오류를 보낼 수 있다.

ICMPv6 Time Exceeded
Type 3, Code 0
Hop Limit Exceeded in Transit

 

UDP Probe가 IPv6 Destination의 닫힌 Port에 도착하면 ICMPv6 Destination Unreachable, Port Unreachable을 받을 수 있다.

IPv4와 IPv6 Route, Firewall, Source Address가 다르므로 결과도 별도로 확인한다.

traceroute -4 server.example
traceroute -6 server.example

 

일부 운영체제는 traceroute6나 다른 Option을 사용한다.

IPv6에 필요한 ICMPv6를 일괄 차단하면 Hop 관찰뿐 아니라 PMTUD 같은 정상 기능도 깨질 수 있다.

---

ㅁ traceroute의 Maximum Hop은 경로의 끝일까?

도구는 무한히 TTL을 늘리지 않는다.

Maximum Hop Limit에 도달하면 Destination 응답이 없어도 측정을 끝낸다.

30  * * *
traceroute 종료

 

이는 Destination이 정확히 30 Hop 밖에 있다는 뜻이 아니다.

• 실제 경로가 더 길 수 있다.
• Routing Loop로 Destination에 도달하지 못할 수 있다.
• Destination 종료 응답이 차단될 수 있다.
• 중간부터 모든 ICMP가 보이지 않을 수 있다.

Maximum Hop과 Timeout은 측정의 종료 조건이지 Network의 물리적 경계를 선언하는 값이 아니다.

---

ㅁ traceroute와 mtr은 무엇이 다를까?

traceroute는 TTL을 늘린 Probe를 일정 횟수 보내 한 시점의 경로 단서를 얻는다.

mtr 계열 도구는 traceroute와 반복 측정을 결합해 Hop별 응답률과 RTT 변화를 시간에 따라 보여 줄 수 있다.

traceroute
→ 짧은 경로 Snapshot

mtr
→ 반복 Probe를 통한 변화 관찰

 

하지만 중간 Router의 ICMP Rate Limiting 문제는 mtr에서도 남는다.

중간 Hop Loss 80%
뒤 Hop과 Destination Loss 0%
→ 중간 Router의 ICMP 응답 제한 가능성

 

중간 Hop의 Loss가 뒤 Hop에 이어지지 않으면 Transit Data Loss로 곧바로 해석하지 않는다.

반복 Probe는 장비에 부담을 줄 수 있으므로 횟수와 간격을 제한하고 허가된 대상에서 사용한다.

---

ㅁ traceroute 결과를 어떻게 문장으로 남길까?

관찰보다 넓은 결론을 피한다.

Hop 8부터 별표다.
→ Hop 8 Router가 Down이다.  (근거 부족)

증거 범위에 맞는 기록은 다음과 같다.

10:30 KST, Client 10.0.0.10에서 Destination 198.51.100.20으로
UDP 기반 traceroute를 실행했다.
TTL 1~7 Probe에는 ICMP Time Exceeded가 돌아왔고
TTL 8 이후에는 Timeout 안에 대응 응답을 관찰하지 못했다.
같은 Source의 TCP 443 연결은 성공했다.
UDP Probe 또는 ICMP Reply Policy 차이를 우선 비교한다.

 

다음 정보도 함께 기록한다.

• Source Host와 Address
• Destination Name과 실제 선택된 Address
• IPv4 또는 IPv6
• Probe Protocol과 Destination Port
• Probe 수, Timeout과 Maximum Hop
• 실행 시각
• 실제 Application의 성공 여부

도구 출력만 붙이지 말고 어떤 질문으로 실행했는지 남긴다.

---

ㅁ 진단할 때 어떤 순서로 비교할까?

1. DNS가 선택한 Destination Address를 확인한다.
2. Local Routing Table과 실제 Source Address를 확인한다.
3. 숫자 출력으로 Reverse DNS 지연을 분리한다.
4. 기본 UDP, ICMP, 실제 Service와 가까운 TCP Probe를 비교한다.
5. 별표가 뒤 Hop까지 계속되는지, 다음 Hop이 다시 보이는지 확인한다.
6. 중간 Hop의 높은 RTT와 Loss가 Destination까지 이어지는지 본다.
7. 반대 방향 Host에서도 측정하되 원래 Return Path와 같다고 가정하지 않는다.
8. 문제가 발생한 시각의 Route 변화와 Application Error를 연결한다.
9. 필요한 지점에서 Packet Capture와 Router Counter를 확인한다.

traceroute는 원인을 확정하는 마지막 명령이 아니라 Capture할 지점과 비교할 Protocol을 정하는 도구다.

---

ㅁ 우편 비유를 네트워크 용어로 바꾸면

비유를 실제 Probe와 응답으로 다시 연결해 보자.

우편 이야기	실제 용어	정확한 의미
중계 가능 횟수를 1로 적은 시험 편지	TTL 1 Probe	첫 Router에서 수명이 끝나도록 전송
중계 가능 횟수를 하나씩 늘림	Incrementing TTL	각 Hop에서 차례로 Probe를 만료시킴
수명이 끝났다는 반송 안내	ICMP Time Exceeded	IPv4 Type 11 Code 0 또는 ICMPv6 Type 3 Code 0
반송장에 포함된 원래 봉투 일부	Quoted Original Packet	응답을 특정 Probe와 연결할 Header 정보
해당 중계소까지 갔다 돌아온 시간	Hop RTT	Probe Forward Path와 ICMP Return Path의 왕복 시간
반송 안내가 오지 않은 칸	* Timeout	해당 Probe의 응답을 시간 안에 관찰하지 못함
같은 횟수 편지가 서로 다른 길로 감	ECMP	Flow Hash에 따라 여러 Next Hop 중 하나를 선택
접수 번호를 고정해 길 혼합을 줄임	Paris Traceroute	Flow Identifier 변화를 줄여 Per-Flow ECMP 영향 완화
목적지의 닫힌 창구 반송	UDP Port Unreachable	Classic UDP Probe가 Destination에 도착한 종료 신호
실제 서비스 창구로 보내는 시험	TCP Traceroute	선택한 TCP Port와 유사한 Policy 경로를 관찰
안내가 돌아오는 별도 길	Asymmetric Return Path	ICMP Reply가 Probe Forward Path와 다른 Route 사용 가능

 

traceroute가 만드는 지도는 다음처럼 이해해야 한다.

TTL 1 Probe + Reply ─┐
TTL 2 Probe + Reply ─┤
TTL 3 Probe + Reply ─┼─> 서로 다른 관찰을 한 화면에 조합
TTL 4 Probe + Reply ─┤
...                  ┘

결과
→ 각 TTL에서 응답한 지점의 단서
→ Router의 전체 Routing Table이나 고정된 물리 지도는 아님

---

ㅁ Packet Capture에서 직접 확인해 보기

Classic UDP traceroute를 Capture하면 TTL이 증가하는 Probe와 ICMP Reply를 함께 볼 수 있다.

Wireshark Display Filter 예시는 다음과 같다.

icmp.type == 11 || udp.dstport >= 33434

 

TCP Probe를 함께 본다면 다음처럼 좁힐 수 있다.

icmp || tcp.port == 443

 

확인할 Field는 다음과 같다.

ip.ttl 또는 ipv6.hlim
icmp.type와 icmp.code
icmpv6.type와 icmpv6.code
인용된 Original IP Header
UDP 또는 TCP Source / Destination Port
Probe와 Reply Timestamp
ICMP Reply Source Address

한 Router에서 Capture한 Probe의 수신 TTL과 다음 Interface로 Forward된 TTL도 비교할 수 있다.

ICMP Reply는 별도의 Packet이므로 새로운 TTL, Source와 Destination, Return Route를 갖는다는 점을 확인한다.

---

ㅁ 격리된 Linux 환경에서 3-Hop 경로를 만들어 보기

다음 실습은 ip, iptables, tcpdump, traceroute가 있는 개인 Linux VM에서 수행한다. 네 개의 Network Namespace와 가상 Link만 사용한다.

trace-client       trace-r1          trace-r2        trace-server
10.25.1.2 ── 10.25.1.1 | 10.25.2.1 ── 10.25.2.2 | 10.25.3.1 ── 10.25.3.2

 

Namespace와 세 가상 Link를 만든다.

sudo ip netns add trace-client
sudo ip netns add trace-r1
sudo ip netns add trace-r2
sudo ip netns add trace-server

sudo ip link add veth-tc type veth peer name veth-r1c
sudo ip link add veth-r1r2 type veth peer name veth-r2r1
sudo ip link add veth-r2s type veth peer name veth-ts

sudo ip link set veth-tc netns trace-client
sudo ip link set veth-r1c netns trace-r1
sudo ip link set veth-r1r2 netns trace-r1
sudo ip link set veth-r2r1 netns trace-r2
sudo ip link set veth-r2s netns trace-r2
sudo ip link set veth-ts netns trace-server

Address를 설정한다.

sudo ip -n trace-client addr add 10.25.1.2/24 dev veth-tc
sudo ip -n trace-r1 addr add 10.25.1.1/24 dev veth-r1c
sudo ip -n trace-r1 addr add 10.25.2.1/24 dev veth-r1r2
sudo ip -n trace-r2 addr add 10.25.2.2/24 dev veth-r2r1
sudo ip -n trace-r2 addr add 10.25.3.1/24 dev veth-r2s
sudo ip -n trace-server addr add 10.25.3.2/24 dev veth-ts

Loopback과 Interface를 올린다.

sudo ip -n trace-client link set lo up
sudo ip -n trace-r1 link set lo up
sudo ip -n trace-r2 link set lo up
sudo ip -n trace-server link set lo up

sudo ip -n trace-client link set veth-tc up
sudo ip -n trace-r1 link set veth-r1c up
sudo ip -n trace-r1 link set veth-r1r2 up
sudo ip -n trace-r2 link set veth-r2r1 up
sudo ip -n trace-r2 link set veth-r2s up
sudo ip -n trace-server link set veth-ts up

 

Route를 설정한다.

sudo ip -n trace-client route add default via 10.25.1.1
sudo ip -n trace-r1 route add 10.25.3.0/24 via 10.25.2.2
sudo ip -n trace-r2 route add 10.25.1.0/24 via 10.25.2.1
sudo ip -n trace-server route add default via 10.25.3.1

 

두 Router Namespace에서 IPv4 Forwarding을 활성화한다.

sudo ip netns exec trace-r1 \
  sysctl -w net.ipv4.ip_forward=1

sudo ip netns exec trace-r2 \
  sysctl -w net.ipv4.ip_forward=1

 

Capture Terminal에서 R1을 지나는 Probe와 Reply를 저장한다.

sudo ip netns exec trace-r1 \
  tcpdump -n -vv -i any -s 0 -w /tmp/traceroute-lab.pcap \
  'icmp or udp or tcp port 8080'

Client에서 숫자 출력과 Probe 하나씩으로 Classic UDP traceroute를 실행한다.

 

sudo ip netns exec trace-client \
  traceroute -n -q 1 -w 1 10.25.3.2

환경이 정상이라면 R1, R2와 Destination의 응답을 차례로 기대할 수 있다.

1  10.25.1.1
2  10.25.2.2
3  10.25.3.2

ICMP Source Address 선택에 따라 표시 Address가 달라질 수 있으므로 Capture와 함께 확인한다.

---

ㅁ 응답하지 않는 Hop 뒤가 보이는 장면을 만들기

R2가 자신이 생성한 ICMP Time Exceeded만 Drop하게 한다.

sudo ip netns exec trace-r2 \
  iptables -I OUTPUT 1 \
  -p icmp --icmp-type time-exceeded -j DROP

 

같은 traceroute를 다시 실행한다.

sudo ip netns exec trace-client \
  traceroute -n -q 1 -w 1 10.25.3.2

 

예상 결과는 다음과 같다.

1  10.25.1.1
2  *
3  10.25.3.2

TTL 2 Probe는 R2에서 만료되지만 Time Exceeded가 R2의 OUTPUT Rule에서 Drop된다.

TTL 3 Probe는 R2를 통과해 Server에 도착하고 Server의 UDP Port Unreachable이 돌아오므로 Destination은 표시될 수 있다.

 

Rule Counter를 확인한다.

sudo ip netns exec trace-r2 \
  iptables -L OUTPUT -n -v --line-numbers

 

Rule을 제거한다.

sudo ip netns exec trace-r2 \
  iptables -D OUTPUT \
  -p icmp --icmp-type time-exceeded -j DROP

---

ㅁ TCP Probe와 비교해 보기

Server Terminal에서 TCP 8080을 Listen한다. nc Option은 구현마다 다를 수 있다.

sudo ip netns exec trace-server nc -l 8080

Client에서 TCP SYN Probe를 사용한다. 이 Option은 Linux traceroute 구현 기준이다.

sudo ip netns exec trace-client \
  traceroute -T -p 8080 -n -q 1 -w 1 10.25.3.2

UDP 결과와 TCP 결과의 Hop과 종료 응답을 Capture에서 비교한다.

UDP Destination 종료: ICMP Port Unreachable
TCP Open Port 종료   : SYN-ACK

TCP traceroute가 SYN-ACK을 받은 뒤 연결을 완성하지 않고 정리하는 방식은 구현에 따라 달라질 수 있다.

Server Application이 반드시 accept()까지 완료했다는 뜻은 아니다.

 

실습을 마치면 Namespace를 삭제한다.

내부 Firewall Rule과 가상 Interface도 함께 제거된다.

sudo ip netns del trace-client
sudo ip netns del trace-r1
sudo ip netns del trace-r2
sudo ip netns del trace-server

실제 Internet Host에 많은 Probe를 반복하지 않는다.

traceroute Option과 기본 Protocol은 운영체제와 구현마다 다르므로 Manual을 확인한다.

---

ㅁ 핵심 정리

• traceroute는 Router의 지도를 읽는 것이 아니라 TTL 또는 Hop Limit이 다른 Probe의 만료 응답을 모아 경로를 추론한다.
• IPv4 Router는 Transit 중 TTL이 끝나면 ICMP Type 11 Code 0 Time Exceeded를 보낼 수 있다.
• Destination의 종료 응답은 UDP Port Unreachable, ICMP Echo Reply, TCP SYN-ACK 또는 RST처럼 Probe 방식에 따라 다르다.
• 한 Hop의 여러 RTT는 같은 TTL의 별도 Probe 결과이며 서로 다른 ECMP 경로를 탈 수 있다.
• Hop RTT는 앞 Hop과의 Link 지연이 아니라 Source에서 해당 Router까지 갔다가 ICMP가 돌아온 왕복 시간이다.
• 중간 Hop만 느리고 뒤 Hop이 정상이라면 해당 Router의 ICMP Control Plane 우선순위 차이일 수 있다.
• *는 해당 Probe의 응답을 Timeout 안에 보지 못했다는 뜻이며 Router Down이나 Forwarding 실패를 직접 증명하지 않는다.
• 응답하지 않는 Hop도 Transit Packet은 전달할 수 있으므로 별표 뒤의 Hop과 Destination이 다시 나타날 수 있다.
• ICMP Reply는 별도 Return Route를 사용하므로 출력과 RTT에는 Asymmetric Path가 영향을 준다.
• ECMP와 Probe Port 변화는 한 실행에 여러 Flow의 경로를 섞을 수 있고 Paris Traceroute는 이를 줄이려 한다.
• UDP, ICMP와 TCP Probe는 Firewall Policy와 Hash가 달라 서로 다른 결과를 만들 수 있다.
• MPLS, Tunnel, NAT와 ICMP Source Address 선택 때문에 실제 장비와 출력 Hop이 1:1로 보이지 않을 수 있다.
• Reverse DNS 이름과 ICMP Address는 물리 위치와 장비 소유권의 확정적인 증명이 아니다.
• IPv6에서는 Hop Limit과 ICMPv6 Type 3 Code 0 Time Exceeded를 사용한다.
• traceroute는 원인을 확정하는 마지막 명령이 아니라 다음 Capture 지점과 비교할 Protocol을 정하는 도구다.

 

핵심 용어: traceroute, tracert, TTL, Hop Limit, Probe, Hop, ICMP Time Exceeded, ICMP Type 11 Code 0, ICMPv6 Type 3 Code 0, Quoted Packet, UDP Port Unreachable, ICMP Echo Probe, TCP SYN Probe, Hop RTT, Timeout, Rate Limiting, Control Plane, Data Plane, Asymmetric Routing, ECMP, Flow Hash, Paris Traceroute, Reverse DNS, MPLS, Tunnel, Maximum Hop, mtr

 

traceroute가 보여 주는 것은 고정된 길의 사진이 아니다.
서로 다른 수명의 Probe가 각 지점에서 돌려준 응답을 시간 순서로 이어 붙인 추론이다.
빈칸과 RTT도 그 응답이 보이지 않거나 늦었다는 범위 안에서 해석해야 한다.

 

---

ㅁ 다음 이야기

ping과 traceroute는 Endpoint와 중간 Router가 돌려준 응답으로 Network를 간접 관찰한다.

더 자세히 보려면 Interface를 지나는 실제 Frame과 Packet을 Capture해야 한다.

그렇다면 Wireshark에 Packet이 보이기만 하면 원인을 모두 알 수 있을까? Capture 지점 밖에서 일어난 Drop, 암호화된 Payload, Offload와 누락된 Packet은 어떻게 구분할까?

 

다음 글에서는 「패킷을 직접 보면 모든 원인을 알 수 있을까?」라는 질문을 통해

ip, dig, curl, nc, tcpdump, Wireshark를 계층별 질문에 연결하고

Multi-point Evidence로 원인 범위를 줄이는 방법을 살펴본다.