[Network] traceroute 명령어로 인터넷 경로 추적하기

 

<< 실습 주제의 선택 >>

인터넷이 느리거나, 특정 사이트만 안 열릴 때 가장 먼저 의심할 수 있는 건 중간 네트워크 경로의 문제이다.traceroute 명령어는 패킷이 목적지까지 도달하기까지의 경로를 시각적으로 보여주는 도구이다.
실무에서도 네트워크 지연, 우회 경로, 방화벽 구간을 파악하는 데 필수로 쓰인다고 한다. 따라서 직접 이 명령어를 사용해서, 패킷이 어떤 경로를 통해 돌아(?)다니는지 확인히보고자 한다.

 

1. 패킷의 동작과 traceroute 의 원리

• IP 패킷에는 TTL(Time To Live) 값이 있고, 이 값은 라우터를 하나 지날 때마다 1씩 줄어들어든다.
• TTL이 0이 되면 해당 라우터는 ICMP "Time Exceeded" 메시지를 보낸다.
• traceroute는 TTL을 1부터 늘려가며 전송해서, 각 구간의 라우터 IP와 지연 시간(RTT)을 알아내는 방식이다.
  
  
  

2. 명령어의 사용

동작 원리만 보면 살짝 이해가 안될 수 있으니 직접 명령어를 사용해보고, 반환되는 값을 보고 해석해 보기로 한다.

 

traceroute google.com

 

 

 

2-0. traceroute to google.com (142.250.207.110), 64 hops max

목적지는 google.com (실제 아이피 주소) 이며, 최대 64개의 라우터를 따라갈 수 있도록 설정됨.

2-1.  192.168.0.1 1.016ms 0.847ms 0.740ms

내 공유기(우리집의 게이트웨이) IP 주소. 이 공유기를 통해 외부 네트워크로 패킷이 나간다.

2-2.   211.xxx.xxx.xx  5.302ms  3.961ms  4.139ms

실제 우리집에 할당된 공인IP 주소. (NAT 기술로 집안의 네트워크를 192.168.0.x 로 서브넷팅)

2-3. 100.87.0.17 1.587ms 0.925ms 0.953ms

외부 네트워크지만, 100 번으로 시작하는 것으로 보아 ISP 내부의 공유망 구간으로 추청됨.

 

2-4. 10.xx.xx.xx IP 구간

 

패킷이 ISP의 내부 장비를 거치고 있다는 것을 의미한다.

2-5. 72.14.195.250 59.602ms 59.294ms 59.036ms

google의 글로벌 라우팅망 진입점. 맨 뒤에 시간이 갑자기 늘어난 것으로 보면 패킷이 더 먼 거리에 갔다는 것으로 볼 수 있음.

2-6. * * *

 

가장 인상 깊은 구간!! 이 구간은 방화벽이나 NAT가 적용되는 구간이라고 한다. 즉 보안 설정이 된 라우터에 진입한 과정이라고 볼 수 있다

2-7. 108.170.223.20 ~ 142.250.207.110(목적지)

 

google 의 내부 글로벌 라우팅 인프라 구간으로,  패킷이 내부 망을 돌며 목적지 IP 까지 가고 있음

 

 

-> 패킷이 우리집의 공유기부터 시작하여 ISP 망, google 내부 망까지 돌며
목적지 IP 주소까지 가는 과정과 응답시간을 한 눈에 볼 수 있었다!

 

 

3. 응답시간은 근데 왜 3개나 나오는걸까? 그리고 UDP 패킷을 보낸다?

3-1. traceroute 명령어를 사용하면, 각 홉 마다 3개의 패킷을 보내기 때문이다. 즉 n 번째 라우터에 TTL = n 으로 된 패킷을 3개 보낸다고 한다. 그 이유는? 

• 1. 네트워크의 안정성을 확인할 수 있다
  만약 패킷을 총 1번만 보내면 일시적 지연/손실로 오해할 수 있다.
  따라서 3개의 패킷을 보내면 응답 시간의 평균/편차/손실 유무를 확인할 수 있다.
  
  
• 2. 패킷 손실을 탐지할 수 있다.
  예를 들어 응답이 1.2ms 1.3ms  * → 세 번째 패킷이 응답이 없었음 → 패킷 손실 가능성을 유추할 수 있다.
  
  
• 3. 라우터 성능 편차 확인가능.
  지연 편차가 크면 부하가 많은 장비일 수 있다는 것을 의심해볼 수 있다.
  예를들어 응답이 1.5ms 2.0ms 9.5ms → 마지막 응답만 이상하다면→ "특정 순간만 부하가 있나" 를 의심할 수 있다.
  
  
• traceroute -q n
  n 개의 패킷을 보낼 수 있는 옵션도 존재한다.
  
  

-> 좀 더 신뢰있는 정보를 얻고자 3개의 패킷을 보내는 것으로 이해했다!
그런데 신뢰있는 정보를 얻고 싶으면 TCP 패킷 1~2개만 보내보면 되는 것 아닌가?

3-2. 응답시간 같은 정보는, 정보 사용자에게 신뢰할 수 있는 정보를 제공해야 할 것 같은데, 왜 TCP 를 사용하지 않고, 100% 신뢰할 수 없는 UDP 를 사용하는 걸까?

 

• 고의적으로 TTL 값을 조절해 패킷을 “중간에 일부러 죽이면서” 경로를 드러나게 하는 방식이기 때문이다.
  즉 TTL 값이 남았는데 도착지에 도달하는 상황이 발생하는 경우, 도착지에 제대로 패킷이 도착했는지 알 수 없다.
  
  
• traceroute는 목적지에 도달했는지 확인하기 위해, 의도적으로 도달 불가능한 UDP 포트를 사용한다.
  서버(목적지) 에서 대체로 사용하지 않고 닫아두는 포트 (UDP 33434 ~ 33456) 로 패킷을 전송하고, TTL 이 살아 있을 경우엔 Time Exceeded 응답을 받으며 경로를 기록하고, 도착지에 도착하게 되면 "Port unreachable" (ICMP Type 3, Code 3) 응답을 받는 것으로 목적지에 도착한 것을 판단하는 방식이다.
  
  
• ICMP Echo Request(ping) 을 사용하지 않는 이유는, 일부 라우터가 ICMP Echo Response 를 차단하는 경우가 있고, 목적지 서버도 ICMP Echo Response 를 무시하거나 필터링 하는 경우가 많기 때문이라고 한다. ( ICMP 방식으로 tarceroute 하는 방법도 있긴 하다.)

 

-> 만약 TCP 를 사용한다면, 목적지 까지 가는 라우터를 하나하나 모두 응답하며 가야 하고, (혹시라도 라우터와의 연결이 지연되거나 응답이 없을 경우), 응답을 끝까지 기다려야 하는 일이 생긴다. 하지만 UDP 를 사용하면 예상치 못한 지연 상황은 지나치고 Port Unreachable 응답을 받으면 목적지 까지 도달한 것 임을 증명하기 때문에 UDP 를 사용한다고 이해하였다.

 

 

4. traceroute 는 언제 사용하면 좋을까?

• 인터넷 연결, 특정 도메인, 혹은 VPN 등. 연결 속도가 느릴때 ->  어느 구간에서 지연이 발생하는 지 확인할 수 있다
  
  
• 특정 서버에 접속이 되지 않을 때 -> 경로의 중간 지점에서 끈힌 지점을 파악할 수 있다.( 지점 및 방화벽 )
  
  
• 내부망과 외부망을 거칠 때 라우팅 경로를 확인할 수 있다.

 

5. 마무리

traceroute 는 간단(?)한 명령어 였지만, 네트워크의 실질적인 연결상태를 시각화 해서 보여주는게 매우 신통방통 하였다.
앞으로 특정 네트워크 상태를 진단할 때 ping 으로 기기간 연결 상태를 확인한 것 보다 먼저 traceroute 로 경로를 점검하고, 어떤 구간에서 문제가 생겼느지를 빠르게 추척하는게 중요하다고 생각한다!