☰

Los paquetes regresan pero el traceroute falla

tag-icon • tag-icon wireshark networking
Los paquetes regresan pero el traceroute falla

Obtengo este resultado de traceroute:

#traceroute -i eth1 -s 192.168.12.14 192.168.1.72

1  192.168.12.1 (192.168.12.1)  1.410 ms  2.076 ms  2.251 ms
2  * * *
3  * * *
etc..

Pero en otra terminal puedo ver las respuestas correctas (Puerto inalcanzable) que llegan del host de destino:

9.964867 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)     
9.964879 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964886 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964904 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964923 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)
9.964927 192.168.1.72 -> 192.168.12.14 ICMP 102 Destination unreachable (Port unreachable)

Al principio pensé que era un problema de firewall, pero lo verifiqué y no se descarta ningún paquete. Lo único que me viene a la mente es que esta es la segunda NIC...

Si ejecuto traceroute en el mismo host en la primera NIC, obtengo el mismo seguimiento de Wirehark que el anterior (obviamente con una IP de origen diferente), pero el comando traceroute tiene éxito.

No entiendo cómo Wireshark puede ver las respuestas pero el traceroute falla en la segunda NIC.

Creo que me estoy perdiendo algo bastante básico aquí....

Respuesta1

Wireshark mostrará lo que llega a la interfaz de red. El núcleo obviamente ha visto esos paquetes, pero por alguna razón decidió que no deben entregarse al comando traceroute.

Hay algunas cosas que podrían haber salido mal y provocar que el kernel decidiera no entregar esos paquetes.

  • Es posible que tenga un enrutamiento asimétrico que no es adecuado para el filtrado de ruta inversa, pero lo ha dejado rp_filterhabilitado.
  • Es posible que el kernel no pueda hacer coincidir el contenido del mensaje de error ICMP con un socket local. Esto podría ocurrir debido a que el paquete se haya truncado sin suficiente información disponible para tomar dicha decisión. Esto también podría suceder debido a alguna configuración NAT rota donde los paquetes en una dirección se enrutan a través de una NAT pero no en la otra dirección.
  • El kernel puede descartar los paquetes debido a una suma de comprobación incorrecta.

De ellas, creo que ésta rp_filterparece la explicación más probable. No especificaste un sistema operativo, pero parece que podría ser un sistema Linux, así que prueba este comando: head /proc/sys/net/ipv4/conf/*/rp_filter. Probablemente verás 1en cada uno de ellos, lo que significa que el filtro está habilitado. Intente escribir a 0en el correspondiente a la interfaz desde la que se descartan los paquetes, así como en el allnombre del dispositivo.

Respuesta2

¿Puedes publicar aquí el resultado de la tabla de enrutamiento de cada cuadro? Si tiene una ruta predeterminada inválida o faltante, los paquetes no tendrán una ruta de retorno. Por favor publique el resultado de:

# lista de rutas ip

en cada caja de Linux.

información relacionada