Código fuente de puerta de enlace sellado
ARP (AddressResolutionProtocol) se utiliza para convertir la dirección de red de la computadora (dirección IP de 32 bits) en una dirección física (dirección MAC de 48 bits) [RFC826]. El protocolo ARP es un protocolo de capa de enlace. En Ethernet, las tramas de datos de un host a otro en la red identifican la interfaz según la dirección Ethernet de 48 bits (dirección de hardware) en lugar de la dirección IP de 32 bits. El kernel (al igual que el controlador) debe conocer la dirección de hardware del destino al que se envían los datos. Por supuesto, las conexiones punto a punto no requieren el protocolo ARP.
Estructura de datos del protocolo ARP:
typedefstructarphdr
{
unsignedshortarp _ hrd/*tipo de hardware*/
unsignedshortarp _ pro/*Tipo de protocolo*/
unsignedchararp _ hln/*Longitud de la dirección de hardware*/
unsignedchararp _ pln/*Longitud de la dirección de protocolo*/
unsignedshortarp _ op/*Tipo de operación ARP*/
unsignedchararp_sha[6];/*Dirección de hardware del remitente*/
unsignedlongarp_spa/*Dirección de protocolo del remitente */
unsignedchararp_tha[6];/*Dirección de hardware del objetivo*/
unsignedlongarp_tpa/*Dirección de protocolo del objetivo*/
}ARPHDR, *PARPHDR
Para explicar las funciones del protocolo ARP, es necesario comprender el proceso de transmisión de datos en la red. A continuación se muestra un ejemplo sencillo de PING.
Supongamos que la dirección IP de nuestro ordenador es 192.168.1.1. Para ejecutar este comando: ping 192.168.438 0.2. Este comando envía el Protocolo de mensajes de control de Internet a través del protocolo ICMP. Este proceso requiere los siguientes pasos:
1. La aplicación construye un paquete de datos; en este caso, genera un paquete ICMP y lo envía al kernel (controlador de red). El kernel verifica si la dirección IP se puede convertir en una dirección MAC, es decir, verifica la tabla de correspondencia IP-MAC en el caché ARP local
3. salte al paso 9 si es IP: si la correspondencia MAC no existe, continúe con los siguientes pasos
4. y el tipo de comando ARP es SOLICITUD(1), incluida su propia dirección MAC;
Cuando el host 5.192.168.1.2 recibe la solicitud ARP, envía el comando respuesta ARP (2), que contiene su propia dirección MAC;
6. Obtenga localmente la correspondencia de dirección IP-MAC del host 192.168.1.2 y guárdela en la caché ARP;
7. en una dirección MAC, luego encapsularla en la estructura del encabezado de Ethernet y luego enviar los datos.
Puede usar el comando arp-a para ver el contenido del caché ARP local; Por lo tanto, después de ejecutar el comando PING local, habrá un registro de la IP de destino en la caché ARP. Por supuesto, si sus paquetes de datos se envían a destinos en diferentes segmentos de la red, entonces la dirección IP-MAC de la puerta de enlace debe tener los registros correspondientes.
Al comprender el papel del protocolo ARP, podemos saber claramente que la transmisión saliente de paquetes de datos depende del protocolo ARP, que por supuesto es el caché ARP. Debes saber que todas las operaciones del protocolo ARP las completa automáticamente el kernel y no tienen nada que ver con otras aplicaciones. Al mismo tiempo, cabe señalar que el protocolo ARP sólo se utiliza en esta red.
Introducción a la aplicación y principios relacionados del protocolo ARP.
Primero, rastreo de redes conmutadas
El protocolo ARP hace más que simplemente enviar una solicitud ARP antes de recibir una respuesta ARP. Cuando la computadora recibe un paquete de respuesta ARP, actualiza la caché ARP local y almacena las direcciones IP y MAC en la respuesta en la caché ARP. Por lo tanto, en la red hipotética anterior, B envía una respuesta ARP falsificada a A. Los datos de esta respuesta son que la dirección IP del remitente es 192.168.10.3 (dirección IP de C) y la dirección MAC es DD-DD-DD-DD- DD-DD (la dirección MAC de C debe ser CC-CC. Cuando A recibe la respuesta ARP falsificada de B, actualizará el caché ARP local y reemplazará la tabla de correspondencia IP-MAC local con el formato de datos recibido. Porque todo esto se hace automáticamente por El núcleo del sistema de A, y A no sabe que ha sido falsificado.
El objetivo principal de la suplantación de ARP es olfatear la red de conmutación. Detectar la red de conmutación no es el contenido de este artículo. p>
En segundo lugar, conflicto de dirección IP
Sabemos que si hay un host con la misma dirección IP, se informará una advertencia de conflicto de dirección IP. ¿Cómo sucede esto? >Por ejemplo, el host B especifica la dirección IP 192.168.0.1. Si está activado, la otra máquina A tendrá más.
Cambiar la dirección IP a 192.168.0.1 provocará un conflicto de direcciones IP. El principio es que cuando el host A se conecta a la red (o cambia su dirección IP), enviará un paquete ARP a la red para transmitir su dirección IP. Si hay un host B con la misma dirección IP, entonces. B responderá a la dirección a través de ARP. Cuando A reciba esta respuesta, A mostrará una advertencia sobre el conflicto de direcciones IP. Por supuesto, B también tendrá una advertencia.
Por lo tanto, se puede utilizar la suplantación de ARP. falsifique este ARPreply para permitir que el objetivo tenga problemas con las advertencias de conflicto de direcciones IP.
En tercer lugar, evite que el paquete de datos del objetivo pase a través de la puerta de enlace. acceda a Internet a través de la puerta de enlace en la LAN, luego conéctese al ARP de la computadora externa. Hay un registro IP-MAC de la puerta de enlace en el caché. Si se cambia el registro, los paquetes de datos enviados por la computadora siempre se envían a la. dirección de hardware de puerta de enlace incorrecta, lo que hace que la computadora no pueda acceder a Internet.
Esto también se debe principalmente a la suplantación de identidad ARP. Hay dos formas de lograr este objetivo.
1. un paquete de respuesta ARP falsificado al objetivo, donde la dirección IP del remitente es la dirección de la puerta de enlace y la dirección MAC es la dirección falsificada cuando el objetivo lo recibe, actualizará su propia caché ARP. Si la suplantación continúa, la del objetivo. El caché de la puerta de enlace siempre tendrá un registro de error falso. Por supuesto, si alguien lo sabe, sabrá el problema.
2. Este método es muy malicioso y engaña a la puerta de enlace enviando un paquete de respuesta ARP falsificado. , en el que la dirección IP del remitente es la dirección IP de destino y la dirección MAC es la dirección falsificada. De esta manera, el registro ARP de destino en la puerta de enlace es Error, los datagramas enviados por la puerta de enlace al destino utilizan la dirección MAC incorrecta. En este caso, el objetivo puede enviar datos a la puerta de enlace, pero no puede recibir ningún dato de la puerta de enlace. Al mismo tiempo, el objetivo no puede ver nada al mirar ARP-a. , detecta nodos en modo promiscuo a través de ARP.
En el modo promiscuo, el filtrado de paquetes de la tarjeta de red es diferente al modo normal. Resulta que en el modo normal, la tarjeta de red solo enviará paquetes de direcciones locales o transmisiones (multidifusión, etc.) al núcleo del sistema; de lo contrario, la tarjeta de red descartará directamente estos paquetes. El modo mixto ahora permite que todos los paquetes entrantes pasen al núcleo del sistema y luego sean utilizados por programas como los rastreadores.
Se pueden utilizar solicitudes ARP especialmente diseñadas para detectar nodos en modo promiscuo hasta cierto punto, como enviar una solicitud ARP con la dirección MAC FF-FF-FF-FF-FE a cada nodo de la red. .
Para la tarjeta de red, esta no es una dirección de transmisión (FF-FF-FF-FF-FF-FF-FF), por lo que el nodo en modo normal descartará directamente este paquete, pero la mayoría de los núcleos del sistema operativo piensan que es una dirección de transmisión. . Si hay un programa rastreador general y la tarjeta de red está configurada en modo promiscuo, el núcleo del sistema responderá para poder determinar si hay un rastreador en estos nodos.
Se puede ver que muchos ataques basados en ARP se implementan mediante suplantación de ARP. En cuanto a la prevención de la suplantación de ARP, intente utilizar ARP estático. Para WIN, use arp-s para configurar arp estático. Por supuesto, sería mejor si se pudiera utilizar completamente la correspondencia IP MAC estática, porque la caché ARP estática es sólo relativa.
Por supuesto, existen algunas formas de detectar la suplantación de ARP. Configure un rastreador ARP, que mantiene una tabla de correspondencia estática de direcciones IP-MAC en la red local, verifica todos los datos ARP pasados y verifica la correspondencia IP-MAC entre ellos. Si la correspondencia IP-MAC capturada es inconsistente con la correspondencia estática mantenida, indica que se trata de un paquete ARP falsificado.
Para obtener el código fuente del remitente de paquetes ARP y el programa EXE compilado, consulte el programa ARPSender. Nota: Primero es necesario instalar WinPcap.
Seis errores comunes en el análisis de protocolos
Un analizador de protocolos es una de las herramientas más poderosas en el arsenal de un administrador de red. Puede convertir un problema que es difícil de solucionar, lleva mucho tiempo, molesta al CEO o incluso tiene que reiniciar todas las máquinas, en un problema que se puede solucionar en poco tiempo y se puede reflejar fácilmente en el estado semanal. informe, ahorrando a las empresas mucho tiempo y dinero.
Sin embargo, como cualquier otra herramienta compleja, debe usarse correctamente para obtener el máximo beneficio. Al utilizar un analizador de protocolos para diagnosticar fallos de red, debe intentar evitar...
Error 1: el analizador está colocado en la ubicación incorrecta
La ubicación correcta del analizador juega un papel decisivo en el diagnóstico rápido de fallos. Imagine que el analizador es una ventana colocada en la red, como la ventana de un edificio, y el campo de visión cambia según la ventana por la que mire. El atasco en la autopista al norte del edificio no es visible desde las ventanas orientadas al sur. El seguimiento de analizadores colocados en ubicaciones inadecuadas de una red suele llevar mucho tiempo. Entonces, ¿cómo se coloca correctamente el analizador? Podemos dar un ejemplo.
Aquí hay varios problemas posibles y sus causas:
Imagínese un: un host, servidor a, que no puede comunicarse con ningún otro host. Posibles razones:
1) El servidor A está configurado incorrectamente
2) La tarjeta de red configurada para el servidor A es incorrecta
3) La LAN donde se encuentra el servidor; A está ubicado Ocurrió un problema;
4) Hay un error en el segmento LAN donde se encuentra el servidor A.
Escenario B: un host, el servidor B, no puede comunicarse con ningún host en la red remota o el segmento LAN donde se encuentra el servidor B).
Posibles motivos:
1) El servidor B tiene algunos errores de configuración con respecto a la red X
2) El enrutador utilizado por el servidor B para conectarse a la red existe; un problema con la conexión del segmento de red;
3) Hay un problema con uno o más enlaces entre la LAN donde se encuentra el servidor B y la red X;
4) La red X está utilizado para conectarse al servidor Hay un problema con el segmento de red del enrutador donde se encuentra B;
5) Hay un problema con la red x.
Imagínese C: Un host, servidor C. Este host no puede comunicarse con otro host en la LAN, pero la comunicación con otros hosts en la red es normal (es decir, el problema no puede ocurrir en el servidor). C O el segmento LAN donde se encuentra el servidor C).
Posibles motivos:
1) La configuración del host C es incorrecta
2) La tarjeta de red del host C está defectuosa
<; p>3) Hay un problema en el segmento LAN donde se encuentra el host C.Imagínese D: un host, el servidor D, no puede comunicarse con el host remoto, pero se comunica normalmente con otros hosts en el segmento LAN donde se encuentra el servidor D, y no hay ningún problema con la conexión al red remota o la propia red remota.
Posibles motivos:
1) Error de configuración del Host D
2) Error de la tarjeta de red del Host D
3) Host D; Hay un problema con el segmento de la red de área local.
Algunos de estos problemas pueden diagnosticarse o eliminarse sin un perfilador. Por ejemplo, suponiendo el tercer escenario en A, puede determinar la falla verificando otros hosts en la LAN donde se encuentra el servidor A. El segundo y tercer escenario en el escenario D también se pueden determinar de esta manera (suponiendo que el host D pueda comunicarse con él; otros hosts en la LAN).
La mala configuración de un servidor o host se descubre fácilmente mediante una inspección. Pero otros problemas, como fallos en la red o en segmentos de red, deben ser diagnosticados por el analizador.
En todos los escenarios posibles anteriores, el analizador se puede colocar lo más cerca posible del host donde es más probable que ocurra el problema o de la red o segmento de red donde se sospecha inicialmente el problema, pero si No se encuentra ningún problema significativo, debe estar preparado para mover el analizador. Ya sabes, antes de determinar la ubicación de la falla, todo se basa en conjeturas. En el tercer escenario del escenario B anterior, debería haber analizadores tanto en la LAN como en la red X donde se encuentra el servidor B, al menos el analizador debería poder moverse de un extremo al otro.
Por ejemplo, en caso de fallo, un servidor deja de funcionar repentinamente. Al principio se sospechó que el personal del sitio web había manejado el servidor por error. De hecho, el rastreador muestra que el servidor está bloqueado porque muchos hosts envían información de solicitud de conexión al servidor, pero el servidor no responde.
Me tomó unos días determinar qué estaba mal con el servidor. Me dijeron que observara el rastreador, así que le pedí al operador del sitio que eliminara el rastreador de la LAN donde se encuentra el host (a esto se refiere). a la tercera situación en el Escenario B La red en X) se mueve a la LAN donde se encuentra el servidor. Resultó que la lista de control de acceso no se agregó correctamente al enrutador en la LAN donde se encuentra el servidor. Esta lista de control de acceso incorrecta filtra toda la información de la red donde se encuentra el host del cliente. Si al principio tienes más dudas, descubrirás que nunca has visto un mensaje de solicitud de conexión en la LAN donde se encuentra el servidor. Debido a que la situación en ambos extremos de la red no se verificó al mismo tiempo, el sitio web no pudo funcionar durante muchos días.
¿Cómo saber en qué extremo de la red está funcionando el rastreador? En el rastreador, la información de la trama enviada desde el host del cliente tiene todas las direcciones MAC de origen de los clientes reales, mientras que la dirección MAC de destino se almacena en el enrutador.
Desafortunadamente, el problema es cada vez más complejo y no basta con saber a qué red está conectado el analizador. Cuando una LAN se divide en segmentos, el primer paso es encontrar un puerto hub libre o una derivación de cable coaxial. Sin embargo, en un entorno de conmutación de red, hay más que simplemente conectar el analizador a un puerto libre en el dispositivo de conmutación.
La mayoría de los equipos de conmutación tienen la capacidad de designar un puerto específico como puerto de derivación o espejo, pero los diferentes fabricantes de equipos de conmutación utilizan términos diferentes. Si todo el tráfico desde o hacia un puerto específico también se puede enviar al puerto de imagen, siempre que el analizador esté conectado al puerto de imagen, toda la configuración estará completa.
Pero el problema es que algunos dispositivos de conmutación no pueden enviar tráfico entre dos puertos al puerto reflejado. Por ejemplo, en un entorno dúplex, dos hosts que forman parte de una conexión monitoreada pueden enviar información simultáneamente, o el conmutador puede recibir cada trama de datos y transmitirla a otro puerto del enlace. Pero para los puertos de imágenes, se debe almacenar en el buffer alguna trama de datos. Si se procesan demasiados fotogramas de esta manera, el búfer se desbordará, los fotogramas de datos se perderán y, por tanto, el seguimiento dejará de ser fiable. Peor aún, ni siquiera sabía que estaba siguiendo una pista poco confiable.
Algunos dispositivos de conmutación admiten la función de un analizador interno y el propio conmutador puede capturar tramas de datos transmitidas al objeto rastreado. La fiabilidad de este componente funcional depende de la capacidad de búfer del conmutador. En algunos casos tenemos que elegir un puerto de imagen o un analizador interno.
Pero siempre que sea posible, es mejor conectar uno de los hosts y el analizador a un concentrador y conectar el concentrador a un conmutador.
¿Por qué hiciste esto? Esto se debe a que incluso si está seguro de que el conmutador tiene suficiente capacidad para almacenar en búfer todas las tramas para que el puerto reflejado o el analizador interno no pierda datos, el seguimiento seguirá siendo poco confiable. Por ejemplo, en Ethernet estándar, un conector RJ45 ubicado en el puerto defectuoso del conmutador crea una sesión interactiva cada vez que el conmutador envía una trama de datos al servidor. El switch interpreta esto como un conflicto y deja de funcionar. Después de 16 intentos, la trama de datos se cancelará, pero la trama de datos aún se envía al puerto espejo, por lo que el rastreador encuentra la trama de datos, lo que indica que la respuesta del servidor falló. En otro caso, el cableado deficiente resultó en una trama de datos corrupta de 1. Si es el primer caso (el marco de datos se puede transmitir a cualquier lugar), el analizador se cuelga en el Hub con el host, o en el segundo caso (el marco de datos está dañado en la red), el analizador se cuelga en el Hub con el host y el conmutador receptor El puerto cancela la trama de datos antes de enviarla al puerto de imagen y el rastreador no tiene indicación de error. Por supuesto, cada vez que cambias un método, hay que correr cierto riesgo para corregir problemas inesperados que puedan surgir. Si el conector RJ45 está defectuoso simplemente porque no está asegurado al puerto del conmutador, entonces si el conector se vuelve a enchufar al concentrador, es posible que la falla no exista o al menos el problema esté resuelto.
Además, hay que recordar que para equipos de conmutación, cada puerto en su segmento de red es válido, por lo que cuando no se encuentre ningún problema en el puerto de conmutación conectado al servidor, se debe conectar el hub (o analizador) ) se mueve al puerto del conmutador de un host o enrutador.
Además, tenga cuidado de no dejar el concentrador colgado en un entorno dúplex. Algunos analizadores pueden funcionar en modo dúplex. Estos analizadores tienen dos puertos Ethernet y un módulo de función. El módulo funcional divide el par de comunicación en dos y lo envía a cada puerto Ethernet, y luego el software combina los datos recibidos de cada puerto Ethernet en una única cadena de seguimiento. Este analizador es necesario si la red es un entorno dúplex.
Error 2 Demasiado filtrado
La función de filtrado permite que el analizador de protocolos ignore algunas tramas de datos, liberando así más espacio en el buffer de captura para tramas de interés. Si puede filtrar datos de capas de protocolo superiores, como direcciones IP y números de puerto, o incluso datos de capas superiores, los analizadores rara vez necesitan filtrar según las direcciones MAC de origen o destino. Pero un problema común en el seguimiento real es el exceso de filtrado.
Un sitio experimentó tal falla: hubo un problema con la conexión entre el servidor y un cliente específico y se desconectó sin motivo, pero no hubo problema con otros clientes. Dado que el cliente y el servidor están en la misma subred, en caso de que se pierda la conexión, la única forma de restaurar la conexión entre el cliente y el servidor es reiniciar el servidor.
Este sitio tiene un analizador instalado y, debido a la gran cantidad de datos, se configura un filtro para permitir solo la captura de tramas de datos entre dos hosts (basados en direcciones MAC). No se encontró ningún problema durante los dos primeros días, pero el problema apareció al tercer día: los rastros mostraron que el servidor de repente dejó de enviar varias sesiones y la última sesión. Al hacer ping al cliente desde el servidor, el rastreador muestra que el servidor no está enviando ningún marco de datos. El operador del sitio concluyó que había un problema con la pila TCP o el sistema operativo.
Así que solicité otro rastreo, esta vez sin utilizar filtros. Un día y medio después, se capturó otro evento: los rastros mostraban claramente que el servidor seguía enviando datos, pero al mismo tiempo nunca respondía. Después de profundizar más, se descubrió que la dirección MAC de destino de las tramas de datos del servidor había cambiado repentinamente.
Dado que la dirección MAC de destino ya no coincide con la del cliente, el primer seguimiento sin filtro ya no capturará la dirección MAC, lo que indica que el servidor ha dejado de funcionar. También se descubrió que justo antes de cambiar la dirección, el servidor recibió un mensaje ARP que configuraba una nueva dirección MAC para la dirección IP del cliente sin ningún motivo, lo que provocó que el servidor actualizara la caché ARP y enviara los datos al host equivocado.
La dirección MAC de origen de la trama de datos ARP es rastreada por el host que envía ARP sin ningún motivo.
De alguna manera, el host se configura con una dirección IP estática y una dirección DHCP para que el cliente la reutilice. Cuando el host se inicia, se le asigna una dirección estática, que entra en conflicto con el servidor, por lo que se llama a DHCP y se configura la dirección correcta.
Basándonos en esto, podemos sacar una conclusión: usar filtros parece razonable, pero muchas veces, el origen del problema suele aparecer como un artefacto fuera del filtro. Si el rastreador no señala la causa del problema, entonces el filtro debe desactivarse o al menos expandirse hasta que el rastreador realmente encuentre la causa. Sólo cuando todos los filtros están desactivados y el rastreador aún no puede encontrar la causa del problema se puede concluir que no tiene nada que ver con la red.
Error 3
El tiempo de captura es demasiado corto.
Como se muestra en el ejemplo anterior, los operadores del sitio utilizan filtros porque hay demasiados datos en la red. El analizador sólo puede capturar unos 3 minutos de datos, lo que hace casi imposible que los operadores en el sitio detecten problemas o detengan el analizador a tiempo para encontrar realmente la causa del problema. El período de tiempo que el analizador puede capturar un cuadro de datos sin llenarlo en el búfer de captura depende de la velocidad de la red, la cantidad de cuadros en la red, el tamaño de los cuadros y el tamaño del búfer de captura.
Casi todos los analizadores tienen la capacidad de controlar el tamaño de las tramas de datos capturadas, lo que resulta útil cuando se trata de problemas de conexión y problemas de capa de protocolo baja. En términos generales, es suficiente capturar los primeros 64 bytes de datos. Entonces, si todas las tramas en la red tienen 1024 bytes y solo hay 3 minutos de tiempo de captura, entonces capturar solo 64 bytes permitirá más de 30 minutos de tiempo de captura.
Error 4
El disparador no está instalado correctamente.
Un disparador le dice al analizador que realice una acción, como finalizar una captura. Los desencadenantes son útiles cuando se espera que ocurra un problema sin saber cuándo ocurrirá.
La instalación de un disparador significa que no es necesario el control manual del analizador en ningún momento. El mayor problema con la instalación del disparador suele ser una definición incorrecta, lo que prolongará considerablemente el tiempo para resolver el problema.
Por supuesto, debes saber instalar el disparador al detalle y, si es posible, probarlo antes de usarlo. A veces es posible instalar otro analizador que envíe un marco de datos del activador para confirmar que el activador del análisis de captura se ha instalado correctamente.
Otro problema con el uso de activadores es que muchos analizadores le permiten establecer un porcentaje del búfer de captura que está preactivado. Por ejemplo, podría especificar que se capture un búfer de 50 antes del activador y otros 50 después del activador. El porcentaje previo al disparo suele ser 0, 25, 50, 75 o 100.
Si el valor de activación previa se establece incorrectamente, es posible que no capture suficientes marcos de datos relevantes para diagnosticar el problema. El valor de activación previa puede estar configurado incorrectamente porque su configuración predeterminada a menudo no es adecuada para el problema actual: tal vez porque la configuración de un problema anterior no se actualizó, o tal vez debido a una operación descuidada del mouse o pulsaciones de teclas incorrectas. Cualquiera sea el motivo, asegúrese de que el gatillo esté instalado correctamente.
Entonces, ¿cómo configurarlo? Normalmente, el porcentaje previo al disparo se establece en 100 para comprender qué causa que el disparador se apague.
Por supuesto, el disparador sólo se cerrará cuando se active el evento. En el pasado se utilizaban disparadores especiales que probaban el estado y luego enviaban un paquete que el analizador podía utilizar como disparador. El estado de la prueba puede ser un mensaje de error en el archivo de registro o, en el ejemplo anterior, no se puede crear una conexión. Generalmente, el programa completo tiene más de 100 líneas o un poco más.
Error 5
La configuración de fecha/hora es incorrecta.
No configurar la fecha/hora correctamente en el analizador puede parecer una cosa sin importancia y puede ser cierto en muchos casos. Sin embargo, cuando se trata de problemas en una WAN, a veces se ejecutan dos analizadores simultáneamente, uno en cada extremo de la red, por lo que configurar la fecha/hora correctamente es muy útil.
Será más fácil ajustar el seguimiento si ambos analizadores tienen la misma configuración de reloj. Supongamos en un ejemplo que, al buscar fotogramas comunes y comparar el tiempo, encontrará que uno de ellos tardó 4 horas y 37 minutos, lo que es 15,795438 0 segundos antes que el otro.
Si el error de sincronización de la configuración del reloj es de 1 a 2 segundos, entonces el cálculo del intervalo de tiempo será mucho más fácil.
Además, si necesita ajustar el seguimiento con eventos del host, definitivamente tiene sentido establecer la misma fecha/hora, ya que la sincronización basada en paquetes de tiempo no es opcional.
Error 6: No entender el protocolo
Muchos analizadores tienen la función de "análisis experto", lo que significa que pueden rastrear información, como números de serie, información de tiempo, mostrar información de retransmisión, Congelar ventanas, estado sin respuesta, etc. Este análisis es muy útil, pero también puede resultar engañoso, especialmente si el analizador no informa los errores correctamente.
Por ejemplo, hay situaciones en las que no se puede establecer una sesión de inicio de sesión remota desde una ubicación remota, pero no hay problema en establecer una sesión de inicio de sesión remota desde una estación de trabajo local. Entonces, los operadores del sitio conectaron un analizador en la LAN donde se encuentra el servidor de inicio de sesión remoto y el rastreador mostró que no había errores en los marcos de datos desde el host remoto al servidor de inicio de sesión remoto, por lo que concluyeron que algo andaba mal; con el sistema operativo.
Otro operador revisó el rastreador y encontró que la sesión de telnet local estaba conectada al puerto 2323, mientras que la sesión remota estaba conectada al puerto 23. Además, los paquetes enviados por el servidor telnet en respuesta a la solicitud de conexión remota contienen el indicador RST establecido.
Aquí, los operadores del sitio web no observaron cuidadosamente los detalles de TCP, por lo que no se dieron cuenta de la importancia de los diferentes números de puerto y paquetes RST. Se basan en la información de diagnóstico del analizador. Como el puerto 23 del servidor de inicio de sesión remoto no estaba instalado, especularon que había un problema con el sistema operativo. Sin embargo, si el personal del sitio comprende TCP y el inicio de sesión remoto, detectarán el problema inmediatamente y encontrarán una buena solución en 5 minutos.
De hecho, esperaron mucho tiempo para instalar el rastreador y, como resultado, perdieron una cantidad importante de clientes en la red remota.