Dicen la verdad a menos que se registren incorrectamente. En estos casos, los paquetes pueden mentir descaradamente.
Al buscar archivos de seguimiento, podemos encontrar síntomas en los paquetes que sorprenderían a muchos. Estos eventos parecen extraños a primera vista e incluso pueden distraernos en la resolución de problemas por un tiempo. Algunos de estos problemas han sido, de hecho, engañosos. network analistas durante horas, si no días, lo que les obliga a perseguir problemas y eventos que simplemente no existen en el network.
La mayoría de estos ejemplos se pueden evitar fácilmente capturando paquetes de un network Punto de acceso de prueba (TAP) en lugar de en la máquina donde se genera el tráfico. Con un network TAP, puedes capturar el network datos de forma transparente e inalterada, y ver lo que realmente se está transmitiendo a través de la red.
En la mayoría de los casos, los paquetes no deben superar el tamaño máximo de Ethernet de 1518 bytes o el especificado para la MTU del enlace. Sin embargo, esto solo es aplicable si no se utilizan etiquetas 802Q o si se trabaja en un entorno de tramas jumbo.
¿Cómo es posible que los paquetes superen el límite de Ethernet? En pocas palabras, los capturamos antes de que la tarjeta de red los segmente. Muchas pilas TCP/IP actuales utilizan la descarga de segmentación TCP, que delega la tarea de segmentar los paquetes a la tarjeta de red. El controlador WinPcap o Libpcap captura los paquetes antes de que se realice este proceso, por lo que algunos paquetes pueden parecer demasiado grandes para ser legítimos.
Si se capturó la misma actividad en el networkEstos grandes marcos se segmentarían en varios más pequeños para su transporte.
Zero Delta Zeiten
Un tiempo delta cero significa que no hay tiempo medido entre paquetes. Cuando estos paquetes entran al dispositivo de captura, reciben una marca de tiempo y un tiempo delta medible. La marca de tiempo de entrada en el dispositivo de captura no podría seguir el ritmo del volumen de paquetes. Por otro lado, si estos paquetes se capturaran con un servidor de tap externo, probablemente podríamos obtener una marca de tiempo sin errores.
Paquetes anteriores no capturados
Esta advertencia se muestra porque Wireshark ha detectado una interrupción en el flujo de datos TCP. A partir de los números de secuencia, puede determinar que falta un paquete. En ocasiones, esto se justifica debido a la pérdida de paquetes en sentido ascendente. Sin embargo, también puede indicar que el analizador o SPAN ha descartado el paquete por no poder gestionar la carga.
Después de esta advertencia, debe buscar una serie de paquetes ACK duplicados en lugar de un paquete defectuoso. Esto indica que un paquete se ha perdido y debe retransmitirse. Si no ve retransmisiones ni paquetes defectuosos, es probable que el analizador o el SPAN no hayan podido seguir el flujo de datos. El paquete estaba en el... network, pero no lo vimos.
Segmentos no detectados con acuse de recibo de TCP
En este caso, se muestra un acuse de recibo de un paquete de datos no detectado. Es posible que el paquete haya tomado una ruta diferente o que el dispositivo de captura simplemente no lo haya detectado.
Recientemente he visto estos eventos en archivos de seguimiento capturados por conmutadores, enrutadores y cortafuegos. Dado que capturar tráfico tiene menor prioridad que reenviarlo (¡gracias a Dios!), el dispositivo podría simplemente perder algunas tramas en el flujo de datos. Tras ver la confirmación, sabemos que el paquete ha llegado a su destino.
En la mayoría de los casos, los paquetes dicen la verdad. Pueden llevarnos a la raíz del problema. network y problemas de aplicación. Debido a que presentan datos tan claros y detallados, es muy importante que los registremos lo más cerca posible de la realidad. network Lo más pronto posible. Esto significa que debemos capturarlos durante la transmisión, en lugar de en el propio servidor. Esto nos ayuda a evitar perder tiempo con falsos negativos.
Si desea obtener más información sobre network Consideraciones de visualización para profesionales, descargue nuestra infografía gratuita, TAP vs SPAN.
Comparte este blog:
Timur es el fundador y director ejecutivo de NEOX Networks, Un proveedor líder de network Soluciones de visibilidad y seguridad. Con más de 25 años de experiencia en el sector, Timur comprende a fondo los desafíos que enfrentan los equipos de TI y OT actuales. network y dominios de seguridad. Le apasiona aprovechar la tecnología para resolver problemas complejos y cree que la eficacia network La visibilidad es fundamental para el éxito de cualquier organización en lo que respecta a la disponibilidad y seguridad de las aplicaciones empresariales. Timur se compromete a ofrecer soluciones innovadoras que satisfagan las necesidades cambiantes de los clientes de NEOX.