Cuando uso traceroute(en realidad, tracertel comando para Windows) para diferentes direcciones de destino, siempre obtengo el mismo número de saltos.
Por ejemplo: Para superuser.com, obtengo:
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.
Para microsoft.com, obtengo:
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.
Es similar a todos los demás sitios que he probado hasta ahora.
Quiero saber las posibles razones por las que esto sucede. Tengo un breve conocimiento de cómo traceroutefunciona. Los diferentes destinos deberían tener diferentes conteos de saltos. Mi ISP (angeldrops) puede que no tenga todos los servidores de destinodirectamenteconectado. Creo que mi ISP está haciendo algo aquí. Entonces, ¿cuáles son las razones por las que esto sucede?
Respuesta1
Voy a darte mi mejor oportunidad para explicar esto. Pero no sé por qué su ISP lo hace.
Primero, es importante entender cómo funciona Traceroute. Traceroute funciona configurando el valor TTL (Tiempo de vida) en los paquetes IP que envía. Cada salto que dé su paquete en el camino disminuirá el TTL en 1. Cuando el TTL llega a 0, si su paquete no ha llegado al destino previsto, se envía un mensaje ICMP inalcanzable que contiene la dirección IP del último enrutador alcanzado.
Entonces, cuando emite el tracertcomando, Windows envía una serie de paquetes ICMP con valores TTL incrementales. El primer paquete sale con TTL 1, el siguiente paquete con TTL 2, y así sucesivamente. De esta manera, se puede descubrir cada enrutador a lo largo del camino hacia su destino, si responde con ICMP inalcanzable. Si simplemente descarta el paquete, obtendrá la * * * respuesta de tracert y ninguna información.
Entonces, lo que parece estar sucediendo aquí es que su ISP (AngelDrops) no respeta la configuración TTL. En cambio, parece que están eliminando o filtrando esa información del paquete cuando les llega. Debido a eso, una vez que el paquete llega a AngelDrops, lo reenvían a su destino con un TTL "predeterminado" mucho más alto. Esto hace que el paquete recorra todo el camino hasta su destino y la respuesta final que ve proviene del destino.
TTL en un paquete IP está realmente diseñado para evitar bucles de red en los que un paquete continúa rebotando dentro de la red en un círculo para siempre.
Espero que tenga sentido. Ahora bien, ¿por qué tu ISP hace eso? No estoy particularmente seguro, pero podría ser que vean la manipulación del TTL como un posible riesgo de seguridad para su red y, por lo tanto, lo filtren. Respetar sus datos TTL no es realmente necesario para el correcto funcionamiento de la red.
siendo que no se nada deangeldrops, podría ser que haya algo no estándar en este ISP, tal vez sea inalámbrico, o un servicio VPN, o algo así. Hay una serie de posibles tecnicismos por los que las cosas se ponen raras con ellos.
Según lo que veo en tu traceroute, parece que estás en algún tipo de servicio de Internet compartido. No obtienes una IP pública real, por lo que probablemente estés detrás de algún tipo de red NAT en la que compartes la misma IP pública con varios usuarios. Esto lo explicaría todo.