Ping no funciona, pero Wirehark detecta la solicitud y respuesta ICMP

Question

Me encuentro con un problema extraño y agradecería que alguno de ustedes pudiera agregar información.

He configurado dos subredes diferentes y a modo de prueba. Estoy intentando hacer ping a una máquina en 10.10.11.9/30 (en una subred) desde otra máquina 10.10.11.1/30 (en una subred diferente). El ping no funciona (con razón).

Sin embargo, cuando intento detectar lo mismo en Wireshark, en lugar de mostrar mensajes "inalcanzables", muestra solicitudes y respuestas ICMP normales. Es como si los paquetes estuvieran encontrando su camino...

Adjunto captura de pantalla para ping y Wireshark

Intenté calcular la suma de verificación del encabezado en los paquetes IP, pero incluso al hacerlo, las sumas de verificación de los paquetes capturados en Wireshark parecen correctas, mientras que el ping muestra que todos los paquetes se han perdido.

¿Alguien puede agregar información?

Muchas gracias

Answer 1

Suponiendo que su configuración sea realmente como la describe (nada está mal configurado accidentalmente): a menos que el cliente 10.10.11.1/30 tenga alguna información sobre cómo enrutar a 10.10.11.9/30 (a través de la puerta de enlace predeterminada, rutas estáticas, etc.), no hay ICMP Los paquetes deben enviarse.

Pruébelo en Cisco Paket Tracer. Configure una red con dos clientes y un conmutador en el medio. Mientras no haya una puerta de enlace predeterminada configurada (y los clientes estén en diferentes dominios de transmisión), el cliente ni siquiera enviará ningún paquete ARP.

Esto significa que su configuración actual proporciona algún tipo de "resolución de enrutamiento" para que los paquetes ICMP realmente se envíen y reciban. Posiblemente a través de la puerta de enlace predeterminada, una ruta estática, etc. Verifique la capa 2, ¿a qué dirección MAC se están configurando las tramas? ¿Directamente al cliente o a un enrutador? Como escribí en mi comentario:

el paquete ICMP tuvo que enviarse a través de un enrutador, una ruta estática, alguna configuración "exótica" como "proxy-arp", etc. ¿Qué sucede en la capa 2? ¿Cómo se resuelve la dirección IP en una dirección MAC? Creo que esto lo llevará a la solución de por qué hay una respuesta en primer lugar (que no debería ser así).

Por qué los paquetes recibidos no se muestran en las estadísticas de ping es otra cuestión. Podría ser un firewall que los bloquee (supongo que ya que el comando ping no proporciona ningún error ni confirmación sobre los pings individuales, solo le brinda el resumen).

La única otra explicación que tengo es que hay algún otro tipo de configuración extraña que está estropeando el sistema (por ejemplo, un segundo cliente con la misma dirección IP que el destino y dentro del dominio de transmisión que la fuente, etc.). También puede verificar esto en la capa 2, comparando las direcciones MAC de las tramas con las de los clientes reales.

Idea tardía: ¿podría ser que haya configurado una puerta de enlace predeterminada, una ruta estática, etc.? ¿Tiene el enrutador, por ejemplo, una máscara de red de 24 bits? En este caso, aunque la subred es diferente, los dominios de transmisión del enrutador y los clientes se superponen. Esto podría explicar el comportamiento actual.

Answer 2

Su red está en mal estado, probablemente debido a una confusión de máscaras de red:

• La solicitud ICMP está precedida por una solicitud ARP anterior, inmediatamente o en algún momento antes. Evidentemente la solicitud ARP tuvo éxito, por lo que algún nodo sabía dónde estaba 10.10.11.9 y devolvió su dirección MAC, o el ICMP nunca se habría enviado.

• La solicitud PING debería haber devuelto "red inalcanzable" (o al menos "host inalcanzable"), lo cual no fue así. Entonces, la solicitud ICMP se envió con éxito y se devolvió con un código de éxito.

La pregunta sigue siendo por qué el comando ping aún reportó una pérdida del 100% de paquetes.

Sólo puedo teorizar que el comando ping en sí ha descartado la respuesta, tal vez porque vino de otra red.

Mi conclusión es que algunos otros nodos de la red están utilizando 10.10.11.x/24, por lo que están entregando el ping, lo que provoca una gran confusión para el 10.10.11.1/30nodo.