¿Es posible capturar packages de un enrutador?

Estoy enfrentando un problema que algunos packages enviados a internet desde la networking interior faltaban. El patrón que estamos usando es como:

Client A ←→ Switch A ← Router A:NAT ← .. Network .. → Router B:NAT → Switch B ←→ Server B 

Quiero hacer dos pasos para seguir el problema:

  1. Capture los packages que son del cliente A en el enrutador B.
  2. Compruebe la tabla de traducción del enrutador B.

¿Son posibles ambas acciones?

Más información:

  1. El cliente A se está ejecutando en Windows XP
  2. El server B se ejecuta en Linux (Fedora exactamente).
  3. El Router B utiliza puerto estático y tabla de traducción de direcciones, lo que significa que los packages entrantes
    al puerto específico se enviará al server B.
  4. Tanto el enrutador A como el enrutador B son productos TPLink WR340 +.
  5. Tanto el enrutador A como el enrutador B tienen NAT de cono completo.
  6. El conmutador A es DLink DES-1024R y el conmutador B es DLink DES-1016D.

La razón por la que quiero realizar las dos acciones es que encontramos que los packages fueron enviados fuera de la interfaz de networking de ClientA, pero por razones desconocidas el núcleo TCP de la máquina ClientA nunca recibe ningún package ACK desde el otro punto final, transmisión hasta el time de espera. Y desde el lado del server, también usando la herramienta WireShark encontramos que la interfaz de networking de la máquina del server B nunca recibe el package enviado desde el cliente A. Supongo que los packages fueron eliminados por el enrutador B, así que me pregunto si es posible capturar packages en el router SEGUNDO.

En realidad, el problema sólo ocurrió cuando tenemos dos clientes, dicen que son cliente A y cliente C. El cliente A y el cliente C no se comunican entre sí directamente, sino que se comunican con el server B en su lugar.

Problema ocurrido cuando desconectamos el cable de networking de la máquina Cliente A y en otro logging de la máquina en el Cliente A en unos 30 segundos, el cliente A en la nueva máquina iniciará la comunicación TCP con el server B, los primeros muchos commands están bien, pero después de ese server no puede recibir ningún command del Cliente A más.

El server B nunca recibió el package

Si ejecuta Wireshark desde el server B está bien; si no, considere que necesitaría un switch gestionado configurando un puerto "mirror / span / monitor" en el que se conecte a la PC de Wireshark.

Me quedaría con Wireshark moviéndolo para ver los packages entre el enrutador B y el conmutador B (¿se puede agregar un concentrador en medio para insert la PC de wireshark?)

si el package no llega al segmento RouterB-SwitchB, entonces su reenvío de puertos en el enrutador B (para evitar sus services NAT) podría no funcionar correctamente o el enrutador no está enrutando su tráfico.

Creo que es importante get más información, los switches no hacen NAT (pero los routers hacen), y los diferentes enrutadores tienen capacidades muy variadas. Nunca he oído el término "comprobar la tabla de traducción" al referirse a conmutadores o enrutadores, pero entiendo lo que quiere decir con respecto a los routers.

Lo más probable es encontrar el conocimiento de NAT y comprobar las tablas de traducción, etc mucho less valioso a continuación, utilizando herramientas de networking sencillas. La primera herramienta que usaría es "WinMTR" del cliente A. Deje que la ejecución de un poco (minutos?) Mientras y ver si y dónde se produce la pérdida de packages. Esto le dará una muy buena idea de dónde search más. [Mirar latencias y picos en latencias también le dará algunas pistas si sabe qué mirar].

Para que alguien le proporcione más ayuda, quizás desee proporcionar más detalles sobre por qué cree que los packages van a faltar y las características del problema.

He aquí un esquema de algunas ideas, y tal vez otros saben cómo hacerlo en detalle.

Utilice un enrutador de máquina linux.

Tal vez tomate o DDWRT puede. Tan si su ranurador apoya ese firmware / si usted compró uno que lo apoye, usted podría intentar eso.

Usted comentó "The reason why I want to perform the two actions is that we found packets were sent out of the network interface of ClientA, but due to unknown reason the TCP kernel of ClientA machine never receives any ACK packet from the other endpoint, thus it enters data transmission until timeout. And from the server side, also using Tool WireShark we found the network interface of Server B machine never receives the packet sent from client A, of course it was not able to send any ACK packet back to ClientA."

Tal vez un enrutador está dañado, o tiene un cable defectuoso.

Me encantan las ideas divertidas de cómo ver lo que está sucediendo en su enrutador, puede ser posible con un router más sofisticado, o mejor firmware. Pero si puedes / quieres hacer eso, entonces probablemente tendrías o necesitarías un enrutador mejor, o un reemploop para probarlo. No pase por alto las técnicas básicas de solución de problemas, lógica de tipo mono, al igual que las partes de intercambio!

¿Es sólo una manera que tiene un problema? como A-> B. ¿O B-> A también? Usted podría solucionar un poco allí como intercambiar los cables alnetworkingedor. intercambiando los puertos con los que están conectados.