Traceroute Command for Linux | 리눅스 traceroute 커맨드

traceroute로 데이터 패킷 추적하기

미국 북중서 지역에 있는 PC에서 lifewire.com으로 traceroute를 한 실제 결과

리눅스에서 사용하는 traceroute 커맨드는 데이터 패킷이 목적지까지 가는 여정을 확인할 때 사용해요. traceroute를 사용하는 경우 중 하나는 네트워크에서 데이터 손실이 일어날 때 문제 있는 노드를 찾는 경우이지요.

커맨드 결과에 나타나는 각각의 hop은 발신자 PC와 목적지 사이의 새로운 서버나 라우터를 알려주기 때문에, traceroute 스캔의 결과는 네트워크 트래픽에 악영향을 주는 느린 지점을 찾을 수 있게 해줘요.

 

어떻게 작동하는가

네트워크 트래픽이 따라가는 특정 경로(또는 패킷을 손실시키는 잘못된 경로)를 알아내는 것은 쉽지 않아요. traceroute는 목적지 호스트까지의 경로에 있는 각각의 게이트웨이로부터 ICMP의 TIME_EXCEEDED 결과를 얻기 위해 IP 프로토콜의 time to live 필드를 이용해요.

traceroute 커맨드를 실행할 때 반드시 포함해야 하는 것은 목적지의 호스트 이름 또는 IP 주소 뿐이에요.

 

traceroute 주소와 스위치

우분투에서의 traceroute 문법

traceroute [ -dFlnrvx ] [ -f first_ttl ] [ -g gateway ] [ -i iface ] [ -m max-ttl ] [ -p port ] [ -q nqueries ] [ -s src_addr ] [ -t tos ] [ -w waittime ] [ -z pausemsecs ] host [ packetlen ]

커맨드라인에서 traceroute 커맨드를 사용하는 방법은 기본적으로 위와 같고, 옵션 스위치를 더 지정하면 커맨드의 성능 혹은 결과를 바꿀 수 있어요.

  • -f: 가장 먼저 내보내는 probe 패킷의 초기 time-to-live를 설정한다.
  • -F: “don’t fragment” 비트를 설정한다.
  • -d: 소켓 레벨 디버깅을 사용한다.
  • -g: loose source route gateway를 지정한다 (최대 8개).
  • -i: 내보내는 probe 패킷이 발신 IP 주소를 얻을 네트워크 인터페이스를 지정한다. 이 옵션은 주로 multi-homed 호스트에서만 사용한다 (같은 일을 하는 다른 방법을 확인하기 위해서는 -s 플래그를 참조).
  • -I: UDP datagrams 대신에 ICMP ECHO를 사용한다.
  • -m: 내보내는 패킷의 최대 time-to-live(최대 hop 수)를 지정한다. 기본값은 30 hop이다 (TCP 연결을 위해 사용되는 값과 동일).
  • -n: hop 주소를 문자와 숫자가 아닌 숫자로만 출력한다 (경로에서 발견된 각각의 게이트웨이에 대한 주소-이름 검색을 생략).
  • -p: probe에서 사용하는 base UDP 포트 번호를 지정한다. (기본값은 33434) traceroute는 base 부터 base + nhops – 1 까지의 UDP 포트가 아무 것과도 통신 중이지 않기를 바란다 (ICMP의 PORT_UNREACHABLE 메시지가 반환되어 커맨드가 종료될 수 있도록). 만약 기본 범위 내의 포트 중 무언가와 통신 중인 포트가 있다면, 사용되고 있지 않은 포트 범위를 고르기 위해 이 옵션을 사용한다.
  • -r: 일반적인 라우팅 테이블을 우회하여 호스트와 직접 통신한다. 만약 호스트가 직접 연결된 네트워크에 있지 않다면 에러가 발생한다. 이 옵션은 경로가 없는 인터페이스를 통해 로컬 호스트로 핑을 할 때 사용되기도 한다 (예. 인터페이스가 routed에 의해 종료되고 난 후).
  • -s: 이후에 입력하는 IP 주소(주로 호스트 이름이 아닌 IP 숫자)들을 내보내는 probe 패킷의 발신자 주소로 사용한다. IP 주소가 여러 개인 multi-homed 호스트에서 이 옵션을 통해 prove 패킷이 보내지는 주소를 원하는 것으로 정할 수 있다. 만약 지정한 IP 주소가 현재 머신의 IP 중 하나가 아니라면 에러가 발생하고 아무것도 보내지지 않는다 (같은 일을 하는 다른 방법을 확인하기 위해서는 -i 플래그를 참조).
  • -t: 이후에 입력하는 값으로 prove 패킷의 type-of-service를 지정한다 (기본값 0). 입력하는 값은 0에서 255까지의 십진수여야 한다. 이 옵션은 서로 다른 type-of-service를 사용했을 때 서로 다른 경로를 거치는지 확인할 때 쓸 수 있다. 한편, 4.4bsd를 사용 중인 것이 아니라면 이론적인 이야기이다. 텔넷과 ftp와 같은 일반적인 네트워크 서비스는 사용자가 TOS를 건드릴 수 없다. TOS의 모든 값이 사용 가능하거나 의미있는 것은 아니다 – 정의를 보기 위해서는 IP spec을 참조. 유용한 값으로는 ‘-t 16′(적은 지연)과 ‘-t 8′(높은 처리량)이 있다.
  • -v: verbose output을 뜻한다. 수신된 ICMP 패킷 중 TIME_EXCEEDED와 UNREACHABLE을 제외한 패킷들이 표시된다.
  • -w: probe에 대한 응답을 기다릴 시간을 초단위로 정한다 (기본값 5초).
  • -x: IP 체크섬 계산 여부를 바꾼다. 일반적으로, 이 옵션은 traceroute가 IP 체크섬을 계산하지 않도록 한다. 일부 경우에는 내보내는 패킷의 일부를 운영체제가 덮어쓰고 체크섬을 계산하지 않도록 하기 때문에 체크섬을 계산하지 않는 것이 기본값이고 -x 옵션을 쓰면 계산하도록 설정되기도 한다. ICMP ECHO probe (-I)를 사용할 때에는 마지막 hop에서 체크섬이 필요하기 때문에 ICMP를 사용할 때에는 언제나 체크섬이 계산된다.
  • -z: probe들 사이의 시간 간격을 밀리초 단위로 정한다 (기본값 0). 솔라리스, 시스코 라우터와 같은 일부 시스템은 ICMP 메시지의 트래픽 제한이 있다. 500 정도면 괜찮은 값이다 (0.5초).

결과 해석하기

traceroute는 TTL(time to live)가 짧은 UDP probe 패킷을 보내고 게이트웨이에서 ICMP “time exceeded” 응답을 받아서 IP 패킷이 인터넷 호스트까지 가는 경로를 파악해요. TTL을 1로한 probe로 시작해서 ICMP “port unreachable” (패킷이 목적지에 도달했다는 의미) 응답을 받거나 최대 시도 횟수(기본값은 30이며 -m 플래그로 변경)에 도달할 때까지 때까지 1초씩 늘려나가요.

traceroute는 실행될 때 서로 다른 TTL로 세 개의 probe를 보내고 각 probe의 TTL, 게이트웨이 주소, 왕복 시간을 콘솔에 출력해요. 만약 probe에 대한 응답이 서로 다른 게이트웨이에서 오면 응답한 시스템의 주소가 출력돼요. 5초의 타임아웃(-w 플래그로 변경) 동안 응답이 없으면 해당 probe에 대해서는 *이 출력돼요.

목적지 호스트가 UDP probe 패킷을 과하게 많이 처리하는 것을 방지하기 위하여 목적지 포트는 해당 디바이스가 잘 사용하지 않을 만한 값으로 정해져요. 목적지의 네트워크 또는 서비스가 이미 포트를 사용하고 있다면 -p 플래그로 값을 바꿔야 해요.

사용 및 출력 예시는 다음과 같아요:

[yak 71]% traceroute nis.nsf.net.
traceroute to nis.nsf.net (35.1.1.48), 30 hops max, 38 byte packet
1 helios.ee.lbl.gov (128.3.112.1) 19 ms 19 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 39 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 39 ms
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 39 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 40 ms 59 ms 59 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 59 ms
8 129.140.70.13 (129.140.70.13) 99 ms 99 ms 80 ms
9 129.140.71.6 (129.140.71.6) 139 ms 239 ms 319 ms
10 129.140.81.7 (129.140.81.7) 220 ms 199 ms 199 ms
11 nic.merit.edu (35.1.1.48) 239 ms 239 ms 239 ms

두 번째 줄과 세 번째 줄이 같은 것을 볼 수 있어요. 이 결과는 두 번째 hop에서의 시스템 커널(lbl-scam.arpa)에 버그가 있어서 TTL을 0으로 해서 패킷을 전달하기 때문이에요 (4.3 BSD 배포판 버그). NSFNet (129.140)이 주소-이름 변환을 해주지 않기 때문에 패킷의 경로를 추측해야만 해요.

더욱 흥미로운 예시가 있어요:

[yak 72]% traceroute allspice.lcs.mit.edu.
traceroute to allspice.lcs.mit.edu (18.26.0.115), 30 hops max
1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 19 ms 19 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 19 ms 39 ms 39 ms
5 ccn-nerif22.Berkeley.EDU (128.32.168.22) 20 ms 39 ms 39 ms
6 128.32.197.4 (128.32.197.4) 59 ms 119 ms 39 ms
7 131.119.2.5 (131.119.2.5) 59 ms 59 ms 39 ms
8 129.140.70.13 (129.140.70.13) 80 ms 79 ms 99 ms
9 129.140.71.6 (129.140.71.6) 139 ms 139 ms 159 ms
10 129.140.81.7 (129.140.81.7) 199 ms 180 ms 300 ms
11 129.140.72.17 (129.140.72.17) 300 ms 239 ms 239 ms
12 * * *
13 128.121.54.72 (128.121.54.72) 259 ms 499 ms 279 ms
14 * * *
15 * * *
16 * * *
17 * * *
18 ALLSPICE.LCS.MIT.EDU (18.26.0.115) 339 ms 279 ms 279 ms

12, 14, 15, 16, 17번째 hop에서의 게이트웨이들이 ICMP “time exceeded” 메시지를 보내지 않았거나 너무 짧은 TTL로 보내서 발신자까지 도착하지 못한 것을 볼 수 있어요. 14번째에서 17번째 줄까지의 호스트는 “time exceeded” 메시지를 보내지 않는 MIT C 게이트웨이에요.

위 예시에서 조용한 12번째 게이트웨이는 4.[23] BSD 네트워크 코드, 또는 관련된 버그로 인한 결과일 거에요: 4.3 혹은 이전 버전의 코드를 실행하는 원래 데이터그램의 TTL과 상관없이 unreachable 메시지를 보내요. 게이트웨이에게는 남은 TTL이 0이기 때문에 ICMP “time exceeded”가 발신자에게 돌아오는 것이 보장되지 않아요. 이 버그는 목적지 시스템에서 나타날 때 조금 더 흥미롭지요:

1 helios.ee.lbl.gov (128.3.112.1) 0 ms 0 ms 0 ms
2 lilac-dmc.Berkeley.EDU (128.32.216.1) 39 ms 19 ms 39 ms
3 lilac-dmc.Berkeley.EDU (128.32.216.1) 19 ms 39 ms 19 ms
4 ccngw-ner-cc.Berkeley.EDU (128.32.136.23) 39 ms 40 ms 19 ms
5 ccn-nerif35.Berkeley.EDU (128.32.168.35) 39 ms 39 ms 39 ms
6 csgw.Berkeley.EDU (128.32.133.254) 39 ms 59 ms 39 ms
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
13 rip.Berkeley.EDU (128.32.131.22) 59 ms ! 39 ms ! 39 ms !

12개의 “게이트웨이”(13번째는 최종 목적지)가 있고 뒤 절반의 결과가 없는 것을 볼 수 있어요. 실제로는 rip라는 이름의 서버(Sun OS 3.5를 사용하는 Sun-3 서버)가 ICMP 응답에서와 똑같은 TTL을 도착하는 데이터그램에서의 TTL로 사용하고 있어요. 따라서 경로 길이의 두 배 이상인 TTL을 probe에 사용하지 않는 한, 돌아오는 경로에서 응답이 타임아웃돼요 (ICMP에 대해서 ICMP가 보내지지 않기 때문에 누구도 응답을 볼 수 없ㄷ) – 다시 말해, rip는 실제로 7개 hop만큼 떨어져있어요.

TTL이 1인 응답은 이 문제에 대하 실마리를 주지요. traceroute는 TTL이 1보다 작거나 같으면 “!”를 출력해요. DEC의 Ultrix, Sun 3.x와 같이 단종되었거나 HPUX와 같이 표준을 따르지 않는 다양한 시스템이 사용되기 때문에, 이 문제는 자주 나타날 수 있으며 probe의 목적지를 정할 때 주의해야 해요.

시간 뒤에 표시될 수 있는 다른 것으로는 !H, !N, 또는 !P (호스트, 네트워크, 또는 프로토콜이 unreachable), !S (발신자 라우트가 실패), !F- (프래그먼테이션 필요 – RFC1191 Path MTU Discovery 값을 표시), !X (관리자에 의한 통친 차단), !V (호스트 우선순위 불만족), !C (우선순위 cutoff 발생), ! (ICMP unreachable 코드)가 있다. 이 코드들은 RFC1716보다 우선하는 RFC1812에 정의되어 있어요. 만약 대부분의 probe 응답 어떤 형태로든 unreachable 호스트라면 traceroute는 포기하고 종료돼요.

이 프로그램은 네트워크 테스트, 특정, 관리를 위한 것이에요. 직접 문제 원인을 찾을 때 주로 사용해요. 네트워크에 부하를 줄 수 있기 때문에 traceroute를 평상시에 사용하거나 자동화된 스크립트에서 사용하는 것은 좋지 않아요.

 

#.

네트워크는 용어를 정말 모르겠네요.

 

원문.

https://www.lifewire.com/traceroute-linux-command-4092586

1,329 Comments