주요 콘텐츠로 건너뛰기
Traceroute는 다른 네트워크의 호스트에 대한 연결 문제를 진단하려고 할 때 매우 중요한 도구가 될 수 있습니다. 그러나 효과적으로 사용하려면 작동 방식과 출력의 의미를 이해해야 합니다.

 

추적 경로는 IP 헤더(그림 1)에서 TTL(시간-투-라이브) 값을 조작하여 작동합니다. 나는 Stratus 내부 네트워크를 사용하여 내 예를 만들기 위해했기 때문에 나는 패킷 추적에 IP 주소의 육각형 표현을 X'ed하고 독특한 문자 코드 A를 통해 W를 통해 모든 옥텟을 번역했다. 문자 수는 옥텟의 숫자 수를 나타냅니다. J가 1자리 숫자를 나타내는 동안 AAA는 3자리 숫자를 나타냅니다.

 

Xmit IP Ver/HL 45, ToS 0, Len 5c, ID 5447, Flg/Frg 0, TTL 3c, Prtl 1
Cksum e90c, Src XXXXXXXX, Dst XXXXXXXX
ICMP from AAA.BBB.CC.DDD to EEE.FFF.GGG.HHH echo
그림 1 – TTL 고조명이 있는 packet_monitor 프레임
패킷을 처리하는 모든 라우터는 TTL 값을 1로 감소시키고 TTL 값이 0보다 큰 경우 패킷을 다음 라우터 또는 최종 대상으로 전달합니다. TTL 값이 0이면 라우터가 패킷을 버리고 *수*는 ICMP 시간을 초과한 메시지를 보낸 사람에게 다시 보냅니다. 키는 *may*이며 일부 라우터는 시간을 초과한 메시지를 다시 보내지 않거나 바빠지지 않은 경우에만 메시지를 보낼 수 있습니다. 또한 일부 방화벽은 ICMP 메시지를 차단하므로 라우터가 추적 경로를 실행하는 호스트가 메시지를 초과한 시간을 보내더라도 이를 볼 수 없습니다.
추적 경로는 TTL 값이 1인 대상 대상에 메시지를 전송하여 시작합니다. 응답을 받을 때까지 메시지를 보내는 시간으로부터 걸리는 시간을 시간입니다.

 

17:07:07.797 Xmit IP Ver/HL 45, ToS 0, Len 28, ID 1, Flg/Frg 0, TTL 1, Prtl 11
Cksum 78CC, Src XXXXXXXX, Dst XXXXXXXX
UDP from AAA.BBB.CC.DDD.34611 to EEE.FFF.GGG.HHH.33435 Cksum 0000, 20 data bytes.
17:07:07.799 Rcvd IP Ver/HL 45, ToS c0, Len 38, ID 4a39, Flg/Frg 0, TTL 80, Prtl 1
Cksum 0d1a, Src aXXXXXXXX, Dst XXXXXXXX
ICMP from AAA.BBB.II.J to AAA.BBB.CC.DDD time excdd

 

그림 2 – packet_monitor 추적 경로 프레임 및 응답
기본적으로 추적 경로 명령은 TTL이 있는 세 개의 메시지를 전송하고 세 번 모두 보고하고 응답을 보낸 라우터의 이름과 IP 주소를 모두 보고합니다. 나는 항상 -숫자 인수를 사용하므로 이름 확인 (그림 3)을 기다릴 필요가 없습니다. 그런 다음 추적 경로는 TTL을 1로 증가시키고 다시 수행합니다. 대상 대상에서 응답을 얻거나 일부 제한인 30(기본적으로)에 도달할 때까지 TTL을 계속 증분합니다. OpenVOS STREAMS TCP/IP 관리자 가이드(R419) 설명서에서모든 추적 경로 인수에 대한 설명서를 찾을 수 있습니다.

 

traceroute -numeric EEE.FFF.GGG.HHH
traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.II.LLL 2 ms 1 ms 1 ms
2 AAA.BBB.II.J 1 ms 1 ms 1 ms
3 AAA.BBB.MM.NN 12 ms 5 ms 6 ms
4 BBB.OOO.PPP.QQQ 76 ms 76 ms 76 ms
5 BBB.RRR.SSS.TTT 80 ms 80 ms 80 ms
6 BBB.RRR.SSS.UUU 87 ms 82 ms 79 ms
7 EEE.FFF.V.J 89 ms 89 ms 86 ms
8 EEE.FFF.GGG.HHH 82 ms 87 ms 80 ms
ready 15:19:12

 

그림 3 – 추적 경로 출력
TTL이 증가하면 시간이 증가하고 일반적으로 경우는 아니지만 항상 는 아니지만, 홉 6 (79 ms)과 홉 5 (80 ms)의 세 번째보고 된 시간을 그림 3에서 비교할 것으로 예상됩니다. 이에 대한 몇 가지 이유가 있습니다. 첫째, 네트워크는 결정적이지 않으며 때로는 시간이 오래 걸립니다. 둘째, 홉 N-1의 라우터는 홉 N의 라우터보다 바쁠 수 있으며 ICMP 메시지를 보내는 데 시간이 오래 걸릴 수 있습니다. 마지막으로 라우터 N의 반환 경로는 라우터 N-1의 반환 경로보다 빠를 수 있습니다. 예를 들어 4번째 라우터가 라우터 3, 2 및 1을 통해 소스에 응답을 다시 보낼 필요는 없습니다. 그것은 훨씬 더 빠를 수 있습니다 라우터 1에 직접 응답을 보낼 수 있습니다. 즉, 추적 경로는 패킷이 전송 호스트에서 대상 호스트로 걸리는 경로를 보고하는 데 매우 능숙하지만 대상 호스트에서 전송 호스트로 보낸 패킷에 의존할 수 없습니다. 이를 비대칭 라우팅이라고 합니다.

 

Traceroute는 메시지를 초과한 것으로 예상되는 시간 이외의 다른 것을 수신했음을 나타내는 시간에 플래그를 부수수 있습니다. 플래그는 다음과 같습니다.
! H – 호스트에 연결할 수 없습니다.
! N – 네트워크에 연결할 수 없는
! P – 프로토콜에 연결할 수 없는
예를 들어 그림 4는 첫 번째 라우터가 대상 네트워크에 도달하는 방법을 모르므로 네트워크에 연결할 수 없는 메시지를 반환하고 추적 경로가 해당 시점에서 종료됩니다.

 

traceroute EEE.FFF.GGG.HHH -numeric
traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.CC.KKK 2 ms !N 0 ms !N 1 ms !N
ready 15:40:03

 

그림 4 네트워크에 연결할 수 없는 메시지
시간 대신별표(*)는 추적 경로가 응답을 받지 못했음을 나타냅니다. 위에서 언급했듯이 라우터가 ICMP 시간을 초과한 메시지를 보내지 않는 것 일 수 있으므로 방화벽이 돌아오는 길에 메시지를 초과하거나 방화벽이 나가는 메시지를 차단한 시간을 차단할 수 있습니다. 또한 네트워크가 나가는 메시지 나 반환 메시지를 방금 삭제했을 수도 있습니다.

 

홉(그림 5)에서 단일 또는 두 번의 시간 아웃은 라우터가 사용 중이거나 네트워크가 패킷(또는 둘 다)을 삭제했기 때문에 메시지를 보내지 않았음을 나타냅니다. 그림 5에서 8번째 홉을 알 수 있으며, IP 주소 앞에 있는 별표는 세트의 첫 번째 메시지가 시간 지정되었다는 것을 의미합니다.

 

traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.II.LLL 1 ms 0 ms *
2 AAA.BBB.II.J 1 ms 1 ms 1 ms
3 AAA.BBB.MM.NN 1 ms * 1 ms
4 BBB.OOO.PPP.QQQ 7 ms 8 ms 8 ms
5 BBB.RRR.SSS.TTT 76 ms 76 ms 75 ms
6 BBB.RRR.SSS.UUU 79 ms 77 ms 77 ms
7 EEE.FFF.V.J 79 ms * *
8 * EEE.FFF.W.253 79 ms 79 ms
9 EEE.FFF.GGG.HHH 80 ms 80 ms 80 ms
ready 14:43:16

 

그림 5 – 바쁜 라우터 또는 삭제 된 패킷
세 메시지 모두 시간 초과하지만 후속 홉 보고서 시간(그림 6)이 해당 홉의 라우터가 ICMP 시간을 초과하여 메시지를 보내지 않을 가능성이 높습니다.

 

traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.II.LLL 1 ms 0 ms 1 ms
2 AAA.BBB.II.J 1 ms 1 ms 1 ms
3 AAA.BBB.MM.NN 1 ms 1 ms 1 ms
4 BBB.OOO.PPP.QQQ 7 ms 8 ms 8 ms
5 BBB.RRR.SSS.TTT 76 ms 76 ms 75 ms
6 BBB.RRR.SSS.UUU 79 ms 77 ms 77 ms
7 * * *
8 * * *
9 EEE.FFF.GGG.HHH 80 ms 80 ms 80 ms
ready 14:47:01

 

그림 6 – 응답하지 않는 라우터
모든 홉이 특정 포인트 시간 시간(그림 7)을 지나면 외향또는 반환되는 메시지를 차단하는 방화벽이 있을 수 있습니다.

 

traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.II.LLL 1 ms 0 ms 0 ms
2 AAA.BBB.II.J 1 ms 1 ms 1 ms
3 AAA.BBB.MM.NN 1 ms 1 ms 1 ms
4 BBB.OOO.PPP.QQQ 7 ms 6 ms 8 ms
5 * * *
6 * * *
7 * * *
8 * * *
. . . .
29 * * *
30 * * *
ready 14:51:05

 

그림 7 – 방화벽 차단
모든 것이 특정 포인트 를 지나가는 또 다른 이유가 있습니다. 대상이 응답하지 않는 경우입니다. 모든 대상이 응답하는 것은 아니며, 그런 경우 그림 8과 같은 것을 가지고 있습니다. 그림 7과 8의 차이점은 그림 8에서 응답을 보낼 마지막 라우터가 대상에 로컬라우터라는 것입니다. 이 경우어떻게 알 수 있습니까? 때로는 주소 지정이 명백하게, 예를 들어 대상은 192.168.1.12 및 192.168.1.1이 응답하는 마지막 라우터입니다. 그림 9, EEE에서 그다지 분명하지 않습니다. Fff. W.XXX EEE 전에 마지막 라우터가 될 수 있습니다. Fff. Ggg. HHH, 그들은 공통점이 처음 16 비트를 가지고 있다. 그러나 대상 네트워크에서 사용하는 서브넷 킹 스키마를 알지 못하면 묻지 않고 는 확신할 방법이 없습니다.

 

traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.II.LLL 1 ms * 0 ms
2 AAA.BBB.II.J 1 ms 1 ms 1 ms
3 AAA.BBB.MM.NN 1 ms 1 ms 0 ms
4 BBB.OOO.PPP.QQQ 10 ms 7 ms 6 ms
5 BBB.RRR.SSS.TTT 77 ms 76 ms 75 ms
6 BBB.RRR.SSS.UUU 79 ms 80 ms 81 ms
7 EEE.FFF.V.J 82 ms 78 ms 79 ms
8 EEE.FFF.W.XXX 78 ms 95 ms 77 ms
9 * * *
. . . .
29 * * *
30 * * *
ready 15:00:20

 

그림 8 – 응답하지 않는 대상
동일한 홉(그림 9)에 대해 두 개 이상의 라우터에서 응답을 얻을 수도 있습니다. 라우터가 부하 밸런싱또는 네트워크가 불안정하고 경로가 변경되거나 그림 9, 라우터 AAA의 경우와 같이 발생할 수 있습니다. Bbb. Cc. KKK는 최적의 라우터가 아니었으며 패킷을 AAA로 전달한 후였습니다. BBB.II. J 라우팅 테이블을 변경하기 위해 원본으로 리디렉션 메시지를 다시 보냈습니다.

 

traceroute EEE.FFF.GGG.HHH -numeric
traceroute to EEE.FFF.GGG.HHH (EEE.FFF.GGG.HHH), 30 hops max, 40 byte packets
1 AAA.BBB.CC.KKK 7 ms 1 ms 0 ms
2 AAA.BBB.II.J 1 ms AAA.BBB.MM.NN 1 ms 1 ms
3 BBB.OOO.PPP.QQQ 9 ms 8 ms 8 ms
4 BBB.RRR.SSS.TTT 81 ms 81 ms 77 ms
5 BBB.RRR.SSS.UUU 80 ms 79 ms 78 ms
6 EEE.FFF.V.J 81 ms 77 ms 77 ms
7 EEE.FFF.W.253 78 ms 80 ms 80 ms
8 EEE.FFF.GGG.HHH 84 ms 83 ms 80 ms
ready 15:47:51

 

그림 9 – 동일한 홉에 대한 두 가지 응답
보내는 메시지 유형으로 구분되는 두 가지 유형의 추적 경로 명령이 있습니다. 일부 추적 경로, 마이크로소프트 Windows 시스템에서 발견 하는 것과 같은 ICMP 에코 요청 (ping) 메시지를 보냅니다. STCP에서 실행되는 것과 같은 다른 사람들은 UDP 메시지를 보냅니다. 패킷을 통해 또는 프로토콜 분석기 필터를 작성하도록 방화벽을 구성해야 하는 경우 어떤 유형의 추적 경로를 사용하는것이 중요합니다. 또한 대상의 응답은 다를 것입니다. 대상이 ping 요청을 받으면 ping 응답을 다시 보냅니다. UDP 메시지를 받으면 응답은 포트 번호에 따라 달라집니다. 포트가 사용 중이면 응용 프로그램의 메시지 구조 요구 사항을 충족하지 못하기 때문에 수신 대기 응용 프로그램이 패킷을 삭제할 가능성이 더 큽니까. 포트가 사용되지 않는 경우 호스트 *may*는 ICMP 대상 포트에 연결할 수 없는 메시지를 다시 보냅니다. 이러한 이유로 추적 경로는 일반적으로 사용되지 않는 포트를 선택합니다.

 

대상 호스트에서 볼 수 있는 포트 번호는 도달하는 데 필요한 홉 수에 따라 달라집니다. Traceroute는 대상 포트를 33435(기본적으로)로 시작하고 각 메시지에 대한 포트 번호를 증가시합니다(그림 10). 따라서 대상은 3 개의 다른 포트를 보고, 기회는 세 가지 모두 사용 되지 않습니다. 소스 포트는 전송 프로세스의 프로세스 ID를 기반으로 합니다. 지정된 프로세스는 항상 동일한 소스 포트를 사용합니다.

 

dir len proto source destination src port dst port
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33435
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33436
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33437
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33438
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33439
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33440
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33441
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33442
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33443
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33444
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33445
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33446
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33447
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33448
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33449
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33450
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33451
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33452
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33453
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33454
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33455
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33456
R 28 ICMP EEE.FFF.GGG.HHH AAA.BBB.CC.DDD unreach
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33457
R 28 ICMP EEE.FFF.GGG.HHH AAA.BBB.CC.DDD unreach
T 40 UDP AAA.BBB.CC.DDD EEE.FFF.GGG.HHH 34737 33458
R 28 ICMP EEE.FFF.GGG.HHH AAA.BBB.CC.DDD unreach

 

Figure 10 - (edited) packet traces showing port number changes
마지막으로, 첫 번째 홉에 문제가 없다면 문제를 해결하기 위해 할 수있는 일이 많지 않을 것입니다. STCP(또는 호스트의 네트워크 스택)가 로컬 라우터에 패킷을 전송하면 해당(및 귀하의) 손이 부족합니다. 그러나 응답하는 마지막 홉의 IP 주소 또는 시간 외가 갑자기 발생하기 시작하는 홉을 알고 있다면 문제가 있는 위치에 대한 아이디어를 가지고 있으며 올바른 네트워크 관리자 그룹에 문의하여 해결할 수 있습니다.

© 2024 스트라투스 테크놀로지스.