traceroute다른 대상 주소에 대해 (실제로는 Windows용 명령) 을 사용할 때 tracert항상 동일한 홉 수를 얻습니다.
예를 들면 다음과 superuser.com같습니다.
Tracing route to superuser.com [151.101.1.69]
over a maximum of 30 hops:
1 6 ms 1 ms 1 ms 192.168.0.1
2 2 ms 3 ms 3 ms 10.201.0.1
3 4 ms 2 ms 2 ms angeldropsltd.com [103.242.217.37]
4 8 ms 4 ms 4 ms 151.101.1.69
Trace complete.
에 대해서는 microsoft.com다음을 얻습니다.
Tracing route to microsoft.com [23.100.122.175]
over a maximum of 30 hops:
1 3 ms 3 ms 1 ms 192.168.0.1
2 5 ms 2 ms 2 ms 10.201.0.1
3 4 ms 2 ms 2 ms angeldropsltd.com [103.242.217.37]
4 7 ms 4 ms 4 ms 23.100.122.175
Trace complete.
지금까지 시도한 다른 모든 사이트에서도 비슷합니다.
이런 일이 발생하는 가능한 이유를 알고 싶습니다. 나는 어떻게 작동하는지 간략하게 알고 있습니다 traceroute. 대상마다 홉 수가 달라야 합니다. 내 ISP(엔젤드롭스)에 모든 대상 서버가 없을 수도 있습니다.곧장연결되었습니다. 제 생각에는 ISP가 여기서 뭔가를 하고 있는 것 같습니다. 그렇다면 이런 일이 일어나는 이유는 무엇입니까?
답변1
나는 이것을 설명하는 데 최선을 다할 것입니다. 하지만 귀하의 ISP가 왜 그렇게 하는지 모르겠습니다.
먼저 Traceroute의 작동 방식을 이해하는 것이 중요합니다. Traceroute는 전송하는 IP 패킷에 TTL(Time To Live) 값을 설정하여 작동합니다. 패킷이 이동하는 각 홉은 TTL을 1씩 감소시킵니다. TTL이 0에 도달할 때 패킷이 의도한 대상에 도달하지 않은 경우 마지막으로 도달한 라우터의 IP 주소가 포함된 ICMP 연결할 수 없음 메시지가 다시 전송됩니다.
따라서 tracert명령을 실행하면 Windows는 TTL 값이 증가하는 일련의 ICMP 패킷을 보냅니다. 첫 번째 패킷은 TTL 1로 나가고, 다음 패킷은 TTL 2로 나가는 식입니다. 이러한 방식으로 목적지까지의 경로를 따라 있는 각 라우터가 ICMP 도달 불가능으로 응답하는 경우 발견될 수 있습니다. 패킷을 삭제하는 경우에는 Tracert로부터 * * * 응답을 받지만 정보는 얻지 못합니다.
따라서 여기서 일어나는 현상은 귀하의 ISP(AngelDrops)가 TTL 설정을 따르지 않는 것입니다. 대신, 패킷이 도착하면 해당 정보를 패킷에서 제거하거나 필터링하는 것으로 보입니다. 따라서 패킷이 AngelDrops에 도달하면 훨씬 더 높은 "기본" TTL을 사용하여 대상으로 전달됩니다. 이로 인해 패킷은 목적지까지 계속 이동하게 되며 최종 응답은 목적지로부터 나옵니다.
IP 패킷의 TTL은 실제로 패킷이 네트워크 내부에서 영원히 계속해서 바운스되는 네트워크 루프를 방지하도록 설계되었습니다.
그게 말이 되기를 바랍니다. 그렇다면 ISP가 왜 그렇게 할까요? 특히 확실하지는 않지만 TTL을 변조하는 것을 네트워크에 대한 보안 위험으로 간주하여 필터링할 수도 있습니다. 네트워크의 올바른 작동을 위해 TTL 데이터를 존중하는 것이 실제로 필요한 것은 아닙니다.
내가 아무것도 모르니까.엔젤드롭스, 이 ISP에 대해 비표준적인 요소가 있을 수 있습니다. 무선이거나 VPN 서비스 등일 수 있습니다. 상황이 이상해지는 데에는 여러 가지 가능한 기술이 있습니다.
귀하의 추적 경로에 따르면 귀하는 일종의 공유 인터넷 서비스를 사용하고 있는 것으로 보입니다. 실제 공용 IP를 얻지 못했기 때문에 여러 사용자와 동일한 공용 IP를 공유하는 일종의 NAT 네트워크 뒤에 있을 가능성이 높습니다. 이것은 모든 것을 설명합니다.