Traceroute-모든 패킷에는 TTL == 1

컴퓨터 네트워킹 에서 Wireshark lab-IP를 작업 중입니다. 하향식 접근 방식 으로 정상적으로 만료 된 모든 패킷의 TTL이 1 인 이유를 이해하지 못합니다.

다음은 Wireshark 캡처 ​​파일입니다. https://www.dropbox.com/s/rr5wgze9j20gzvu/traceroute-56.pcapng?dl=0

traceroute다음 명령을 사용하여 Linux 에서 프로그램 실행 (옵션 56 바이트)을 캡처했습니다 .

traceroute http://gaia.cs.umass.edu 56

모든 패킷의 TTL == 1임을 알 수 있으며 그 이후의 모든 홉의 TTL이 +1 (또는 그 이상)이라는 것을 알았 기 때문에 이유를 모르겠습니다.

추신:

• 호스트에 브리지 된 네트워크로 VMware에서 Lubuntu를 사용하고 있습니다.
• 호스트 컴퓨터에서 wireshark로 캡처했습니다 (Windows).
• NAT 프로토콜 위에 자체 DHCP 서버를 사용하여 무선 AP에 연결되어 있습니다.

나를 보자 하려고 조금 더가 처음 보일 수 있음을 복잡 때문에,이 대답 할 수 있습니다.

당신은 이미 기본 작동을 알고있는 것 같지만 traceroute다른 것보다 전에는 매우 작은 요약이 있습니다.

traceroute호스트에서 대상 호스트까지의 모든 중간 단계 또는 호스트에서 대상 호스트까지의 거리, 즉 홉 수를 결정합니다. 이를 위해 "랜덤"대상 포트 번호와 1부터 시작하여 계속 증가하는 TTL을 사용하여 대상 호스트로 패킷을 보내기 시작합니다.
그 사이의 각 라우터는 TTL을 1 씩 줄입니다. 따라서 TTL이 0에 도달하면 (실제로 0으로 줄이려는 라우터가 그 전에 오류를 생성하므로 실제로는 그렇지 않습니다) 라우터는 ICMP를 반환합니다 캡처 시간 파일의 패킷 번호 24 와 같은 " Time-to-live 초과 "오류 메시지 당신이 얻는 것은 목적지가 멀어지고 TTL을 계속 늘리는 이유입니다.
패킷에 대상에 도달하기에 충분히 큰 TTL이 있으면 다른 ICMP 오류 메시지가 나타납니다. " 대상에 연결할 수 없음 (포트에 연결할 수 없음) "(예 : 캡처 파일의 패킷 번호 208) . 여기서 얻은 것은 마지막으로 사용한 TTL이 실제로 사용자와 대상 노드 사이의 홉 수라는 것입니다. 오류가 발생하는 이유는 단순히 대상 노드가 수신하지 않는 "임의"포트로 메시지를 보내기 때문입니다.

이제 캡처 파일에 대한 세부 사항을 살펴보십시오
. 매뉴얼 페이지에서 각 TTL이 3 번 (옵션 '-q') 사용되고 기본 프로토콜이 UDP (옵션 '-P') traceroute임을 알 수 있습니다 . 처음 3 개의 UDP 패킷, 즉 패킷 8-9-10 을 검사하면 실제로 TTL이 1 임을 알 수 있습니다 . 다음 3, 즉 11-12-13 은 TTL 2 등을 갖 습니다. 소스 관점에서 보면 모든 것이 잘되는 것처럼 보입니다.

그런 다음 네트워크 지연에 따라 일정 시간이 지나면 예상되는 오류 메시지가 나타납니다. 따라서 24-24-26 패킷 은 " Time to live over over "오류 패킷이므로 대상이 더 멀리 있다는 것을 알 수 있습니다.

이 시도와 오류의 연속은 마지막으로 패킷 208 과 계속해서 " Port Unreachable "오류 메시지를 볼 수 있을 때까지 계속 됩니다.

전송 한 패킷과 응답을 세면 실제로 TTL이 실제로 작동했지만 지루한 작업을 추적 할 수 있습니다. :)

도움이 되었으면하는 희망

클라이언트는 TTL이 1 인 처음 세 개의 패킷 만 전송합니다. 다음 세 개는 TTL이 2로 전송됩니다. 다음 세 개는 TTL이 3으로 전송됩니다.

이것을 쉽게 볼 수있는 방법은 IP TTL 필드를 Wireshark에서 자체 열로 설정하는 것입니다. 패킷에서 TTL 값을 마우스 오른쪽 버튼으로 클릭하고 "열로 적용"을 선택하십시오.

여기에서 패킷 8,9,10의 TTL이 1이고 패킷 11,12,13의 TTL이 2 등임을 알 수 있습니다.

이것은 Traceroute가 작동하는 방식이기 때문에 발생합니다. 라우터는 TTL을 0으로 줄일 때 수행하는 기능을 활용합니다. 패킷을 계속 전달하는 대신 "ICMP TTL Expired in Transit 메시지"를 원래 클라이언트로 다시 보냅니다 (캡처의 패킷 # 24 참조) .

따라서 클라이언트로서 TTL이 1 인 첫 번째 패킷 세트를 보내면 경로의 첫 번째 라우터가 TTL Expired 메시지로 응답합니다. 그런 다음 초기 메시지를 보낼 때 TTL Expired 메시지를받는 데 걸리는 시간을 측정하여 Traceroute 출력에서 ​​처음 세 값을 제공합니다.

그런 다음 TTL이 2 인 다른 세 개의 패킷 세트를 보냅니다. 경로의 첫 번째 라우터는이 값을 1로 줄이고 경로의 다음 라우터로 전달합니다. 수신하면 두 번째 라우터가 라우터를 가져 오면 TTL을 0으로 낮추어 패킷을 삭제하고 전송중인 TTL을 전송하라는 메시지를 표시합니다.

클라이언트와 추적 경로를 실행중인 최종 대상간에 전송되는 모든 라우터로부터 클라이언트가 (잘, 세 가지) TTL 만료 메시지를 수신 할 때까지 프로세스가 계속됩니다.