☰

¿Por qué traceroute terminó con un salto adicional después del destino?

tag-icon • tag-icon traceroute
¿Por qué traceroute terminó con un salto adicional después del destino?

Si nada bloquea el tráfico, traceroutenormalmente finaliza con la IP de destino como último salto. (10.1.1.10 en este caso)

Lo normal traceroutesería así.

user@linux:~$ traceroute 10.1.1.10
traceroute to 10.1.1.10 (10.1.1.10), 30 hops max, 60 byte packets
 1  10.2.8.2 (10.2.8.2)  0.572 ms  0.692 ms  0.837 ms
 2  10.1.9.50 (10.1.9.50)  202.638 ms 10.1.9.78 (10.1.9.78)  202.547 ms 10.1.9.50 (10.1.9.50)  202.139 ms
 3  10.1.4.9 (10.1.4.9)  202.508 ms  202.483 ms 10.1.4.13 (10.1.4.13)  204.149 ms
 4  10.1.1.10 (10.1.1.10)  202.133 ms  202.100 ms  202.692 ms
user@linux:~$

Recientemente, encontré un problema por el cual había un salto adicional (10.1.1.9) en la traceroutesalida (mira el salto 5).

Dirección IP de origen: 10.2.8.8

user@linux:~$ ifconfig | head -2
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.2.8.8  netmask 255.255.255.0  broadcast 10.2.8.255
user@linux:~$

Dirección IP de destino: 10.1.1.10

Salto adicional: 10.1.1.9 ???

user@linux:~$ traceroute 10.1.1.10
traceroute to 10.1.1.10 (10.1.1.10), 30 hops max, 60 byte packets
 1  10.2.8.2 (10.2.8.2)  0.572 ms  0.692 ms  0.837 ms
 2  10.1.9.50 (10.1.9.50)  202.638 ms 10.1.9.78 (10.1.9.78)  202.547 ms 10.1.9.50 (10.1.9.50)  202.139 ms
 3  10.1.4.9 (10.1.4.9)  202.508 ms  202.483 ms 10.1.4.13 (10.1.4.13)  204.149 ms
 4  10.1.1.10 (10.1.1.10)  202.133 ms  202.100 ms  202.692 ms
 5  10.1.1.9 (10.1.1.9)  6201.720 ms !H * *
user@linux:~$

Además, si observa los saltos 2 y 3, hay direcciones IP adicionales (10.1.9.78 y 10.1.9.50).

¿Por qué pasó esto? Nunca antes había visto algo así.

¿Esto se debió a la configuración del servidor?

Respuesta1

traceroutefunciona enviando paquetes UDP o ICMP Echo con campos de tiempo de vida (TTL) que aumentan secuencialmente. El TTL se reduce en 1 por cada enrutador que procesa el paquete.

Espera dos tipos de respuestas a sus investigaciones.

  • Si TTL llega a 0 cuando un enrutador lo disminuye, responde con un mensaje ICMP de tiempo excedido y no reenvía el paquete.
  • El destino final responde con un mensaje ICMP Port-Unreachable (en el caso UDP) o un mensaje ICMP Echo-Response (en el caso ICMP).

Cuando recibe el segundo tipo, sabe que ha llegado al destino y deja de enviar sondas con TTL más altos. Tenga en cuenta quenobasa esta decisión en la dirección de donde proviene la respuesta: si recibe un mensaje de tiempo excedido de la dirección de destino, seguirá incrementándose.

Entonces, su seguimiento indica que un enrutador respondió con tiempo excedido y la dirección de destino como origen. Esto probablemente significa que es un enrutador que realiza NAT y la dirección de destino es la dirección pública correspondiente a una dirección privada detrás de ella.

Lo extraño, sin embargo, es que la respuesta final vino de undiferenteDIRECCIÓN. Normalmente, esperaría que la respuesta regresara a través del enrutador, por lo que su IP privada se traduciría nuevamente a la IP pública. En este caso, verá dos filas con 10.1.1.10 como dirección.

Aparentemente, en este caso, la ruta desde 10.1.1.9 a la máquina original no necesita pasar por el enrutador NAT, por lo que su dirección no se traduce. El enrutamiento asimétrico a menudo puede producir tracerouteresultados anómalos. En este caso, todas sus máquinas están dentro del espacio de direcciones privadas 10.0.0.0/8, por lo que no sorprende del todo que haya rutas directas disponibles.

Respuesta2

Sin conocer la configuración del enrutador, no hay forma de estar seguro; sin embargo, una razón probable es la NAT de destino, también conocida como NAT inversa, también conocida como reenvío de puertos o, en este caso, un host expuesto.

El enrutador 10.1.1.10 puede configurarse para reenviar/DNATtodoal host 10.1.1.9 (=host expuesto), incluidas las solicitudes de IP privadas. Desde una IP pública, vería un último salto doble porque el enrutador NAT oculta el destino real 10.1.1.9. En este caso, es posible que solo se DNAT la solicitud y la respuesta se envíe tal cual.

También es posible que tanto 10.1.1.10 como 10.1.1.9 estén DNAT en otro lugar y esta última sea la dirección de respuesta predeterminada. Eso explicaría el gran aumento del RTT.

Respuesta3

Presta atención a los tiempos. Traceroute envía paquetes que solicitan a los conmutadores o enrutadores que respondan a la fuente con la respuesta "Estoy procesando". Pero estos paquetes pueden tomar su destino, su máquina en este ejemplo, con varios órdenes, dependiendo de las configuraciones de TTL y tiempo de respuesta, dependiendo tanto de la configuración de los dispositivos entre ellos, las tablas de enrutamiento y la topología de la red.

información relacionada