¿Cómo rastrear las interfaces salientes?

El comando Unix tracerouterastrea las direcciones IP de los nodos desde un nodo de origen a un nodo de destino. Cada nodo intermedio tiene una interfaz entrante y una saliente.

traceroute

Ejecutar traceroute -n dsten srcmostrará las direcciones IP de src, dst y todas las interfaces entrantes de los saltos intermedios.

Pero, ¿cómo rastrear las direcciones IP de salida?

Actualizar

Intenté la ping -Rsugerencia pero no parece funcionar. Este es el traceroute a un servidor web público:

$ ping -n -c 1 -R 212.227.222.9
PING 212.227.222.9 (212.227.222.9) 56 (124) bytes de datos.
64 bytes desde 212.227.222.9: icmp_req = 1 ttl = 57 tiempo = 47.4 ms
RR: 192.168.2.111
        169.254.1.1
        87.186.224.94
        62.154.76.34
        62.154.12.175
        212.227.117.13
        212.227.117.8
        10.71.3.253
        212.227.222.9


--- 212.227.222.9 estadísticas de ping ---
1 paquetes transmitidos, 1 recibido, 0% de pérdida de paquetes, tiempo 0 ms
rtt min / avg / max / mdev = 47.441 / 47.441 / 47.441 / 0.000 ms

Y esta es la dirección IP de mi conexión de acceso telefónico.

$ curl -s https://toolbox.googleapps.com/apps/browserinfo/info/ | jq -r .remoteAddr
93.192.75.247

Pero no ha sido registrado por el comando ping. cual puede ser la razon?

ping traceroute

— ceving
fuente

Consejo: la forma más rápida de obtener su IP pública es curl ifconfig.me. La cosa más simple en internet. Manos abajo.

— Ryan Foley

ICMP nunca le dará la información que busca obtener con precisión. El comportamiento predeterminado es utilizar la interfaz de salida del mensaje ICMP, pero generalmente se puede configurar para que se obtenga de otras interfaces. Digamos que tengo un enrutador de Internet que utiliza el direccionamiento RFC1918 entre las interfaces de enrutador dentro de mi propia red, pero no quiero proporcionar esas direcciones al público, puedo asignar una IP pública a una interfaz de bucle invertido y obtener todo el tráfico ICMP de esa interfaz No obtiene ni las interfaces "entrantes" ni las "salientes" y nunca las obtendrá de ese dispositivo.

— YLearn

@RyanFoley ifconfig.me no es confiable (1 error en 5 pruebas) y es lento: una consulta toma 2.8s. La caja de herramientas de Google necesita 0.7s.

— ceving

¿Alguna respuesta te ayudó? Si es así, debe aceptar la respuesta para que la pregunta no siga apareciendo para siempre, buscando una respuesta. Alternativamente, puede proporcionar y aceptar su propia respuesta.

— Ron Maupin

Respuestas:

No soy exactamente la respuesta a su pregunta, pero esa es una manera simple (pero limitada) de hacer (en ciertos casos) lo que quiere. Estoy haciendo frente a la opción -R de la página de comando man:

-R Registro de ruta. Incluye la opción RECORD_ROUTE en el paquete ECHO_REQUEST y muestra el búfer de ruta en los paquetes devueltos. Tenga en cuenta que el encabezado IP solo es lo suficientemente grande para nueve de esas rutas. Muchos hosts ignoran o descartan esta opción.

Entonces puede ver también la ruta de retorno de ECHO_REQUEST, que no es la interfaz de salida (sobre la que está preguntando) a menos que la ruta de salida sea la misma que la ruta de regreso. Solo en este caso, la ruta de retorno es la dirección IP de la interfaz de salida que está solicitando.

Ese es un ejemplo real en la red de mi proveedor de Internet, tal vez no sea tan claro, pero ahora no tengo un enrutador para vincular entre sí :) dest 10.2.105.178

traceroute 10.2.105.178
traceroute to 10.2.105.178 (10.2.105.178), 30 hops max, 60 byte packets
 1  192.168.1.254 (192.168.1.254)  3.418 ms  3.575 ms  4.021 ms
 2  10.189.48.1 (10.189.48.1)  11.237 ms * *
 3  10.2.105.178 (10.2.105.178)  15.235 ms * *

ping -R 10.2.105.178 PING 10.2.105.178 (10.2.105.178) 56 (124) bytes de datos.

64 bytes de 10.2.105.178: icmp_req = 5 ttl = 253 tiempo = 74.1 ms NOP RR:

192.168.1.133

10.189.51.61

10.2.105.177

10.2.105.178

10.2.105.178

10.189.48.1

192.168.1.254

192.168.1.133

---- omitido ----

64 bytes de 10.2.105.178: icmp_req = 6 ttl = 253 tiempo = 13.0 ms NOP RR:

192.168.1.133

10.189.51.61

10.2.105.177

10.2.105.178

10.2.105.218 ## cambia cada vez, no sé por qué ##

10.189.48.1

192.168.1.254

192.168.1.133

— feligiotti
fuente

No estoy seguro de haber entendido correctamente lo que RECORD_ROUTE hace, pero no parece ser lo que necesito. Lo probé con una conexión de acceso telefónico. Sé la dirección pública de mi enrutador de acceso telefónico y tengo una ruta de nueve saltos a un servidor web público. Para cada uno de los saltos probé la -Ropción. El cuarto salto fue el primero, que respondió a la solicitud. Pero la respuesta no contiene mi dirección pública. Y aunque fue solo el cuarto salto, la respuesta contiene 9 direcciones.

— ceving

solo un momento, estoy preparando un ejemplo

— feligiotti

El ping -Rserá útil solo para salto muy limitado. Antes digo que es una forma restringida

— feligiotti

El mismo ejemplo no funciona para mi red de acceso telefónico. No tengo ni idea de porqué. Tal vez NAT?

— ceving

Hola @Ceving, haz una traceroute 212.227.222.9y luego haz una ping -R hasta el tercer salto que encontraste en el trazado de ruta. De esa manera tienes el mismo esquema que hice para leer la respuesta. El total de las nueve rutas significa ir y volver, así que si lo haces, ping -R 212.227.222.9no puedes ver el camino completo, pero solo la última parte

— feligiotti

De acuerdo con RFC1812, la dirección de origen del mensaje ICMP generado por el enrutador debe ser la de la interfaz de salida a través de la cual el paquete normalmente volvería al remitente.

En realidad, es muy probable que enfrente un comportamiento no estándar donde el enrutador obtendrá la respuesta ICMP con la fuente de la interfaz de ingreso. Esto generalmente hace que el traceroute sea mucho más fácil de leer.

Como seguimiento a la pregunta de YLearn, estoy publicando un diagrama de red y algunas salidas. Muestra de topología para ilustrar cómo funciona el traceroute

Supongamos que estamos agriando el traceroute del loopback 5.5.5.5 de R5 al loopback 1.1.1.1 de R1. Como puede ver, la ruta de avance es a través de R4-R2, mientras que la ruta de retroceso es R3-R4.

R4#sh ip route 1.1.1.1
Routing entry for 1.1.1.1/32
Known via "bgp 4", distance 20, metric 0
Tag 2, type external
Last update from 10.1.24.2 00:02:42 ago
Routing Descriptor Blocks:
* 10.1.24.2, from 10.1.24.2, 00:02:42 ago
  Route metric is 0, traffic share count is 1
  AS Hops 2

R1#sh ip route 5.5.5.5
Routing entry for 5.5.5.5/32
Known via "bgp 1", distance 20, metric 0
Tag 3, type external
Last update from 10.1.13.3 00:14:18 ago
Routing Descriptor Blocks:
* 10.1.13.3, from 10.1.13.3, 00:14:18 ago
  Route metric is 0, traffic share count is 1
  AS Hops 2
  Route tag 3
  MPLS label: none

La salida de traceroute de R5 tiene el siguiente aspecto:

R5#traceroute
Protocol [ip]:
Target IP address: 1.1.1.1
Source address: 5.5.5.5
Numeric display [n]:
Timeout in seconds [3]:
Probe count [3]:
Minimum Time to Live [1]:
Maximum Time to Live [30]:
Port Number [33434]:
Loose, Strict, Record, Timestamp, Verbose[none]:
Type escape sequence to abort.
Tracing the route to 1.1.1.1
VRF info: (vrf in name/id, vrf out name/id)
1 10.1.45.4 208 msec 140 msec 100 msec
2 10.1.24.2 96 msec 44 msec 104 msec
3 10.1.12.1 224 msec 220 msec 112 msec

Entonces, mientras el tráfico ICMP real generado por R1 vuelve a R5 a través de R3, el encabezado IP del mensaje ICMP inalcanzable tendrá la fuente de la interfaz de entrada 10.1.12.1.

En mi experiencia, así es como se comportan los enrutadores Cisco y Juniper, no estoy seguro acerca de otros proveedores.

— mkurek
fuente

Probablemente solo yo, pero la segunda oración me tiene un poco confundido. ¿Está diciendo que es común que un dispositivo en Internet responda usando la interfaz de ingreso del tráfico que causó la generación del mensaje ICMP? Entonces, si el tráfico se recibe en Int1 y el mensaje ICMP sale Int2, ¿proviene de Int1? ¿O se refiere a una interfaz de ingreso diferente (y si es así, cuál)? En mi experiencia, la mayoría de los enrutadores funcionan como los estados RFC, utilizando la interfaz de salida del mensaje de forma predeterminada, y que en la mayoría de los casos esta es la misma interfaz en la que se recibió el tráfico.

— YLearn