Solucionar problemas de conectividad TCP/IP

Pruebe nuestro agente virtual: puede ayudarle a identificar y corregir rápidamente problemas comunes de replicación de Active Directory.

Se aplica a: Versiones compatibles del cliente de Windows y Windows Server

En este artículo se proporciona una guía completa para solucionar errores de conectividad TCP/IP.

Síntomas y análisis

Es posible que encuentre problemas de conectividad en el nivel de aplicación o que experimente errores de tiempo de espera. Estos son algunos escenarios frecuentes:

• Conectividad de aplicaciones a un servidor de bases de datos
• Errores de tiempo de espera de SQL
• Errores de tiempo de espera de la aplicación de BizTalk
• Errores del Protocolo de escritorio remoto (RDP)
• Errores de acceso al recurso compartido de archivos
• Conectividad general

Cuando se sospecha un problema relacionado con la red, se recomienda recopilar una captura de paquetes de red. Esta captura se puede filtrar para identificar la conexión TCP problemática y determinar la causa del error.

Durante el proceso de solución de problemas, es posible que encuentre un RESTABLECIMIENTO DE TCP en la captura de red, lo que podría indicar un problema de red.

Introducción de TCP

TCP se caracteriza como un protocolo confiable y orientado a la conexión. Garantiza la confiabilidad a través del proceso de protocolo de enlace. Una sesión TCP se inicia con un protocolo de enlace triple, seguido de la transferencia de datos y concluye con un cierre de cuatro vías.

• Un cierre de cuatro vías, donde tanto el remitente como el receptor están de acuerdo en cerrar la sesión, se conoce como cierre correcto. Esto se identifica mediante la marca FIN en el encabezado TCP que se establece en 1.

• Después del cierre de cuatro vías, la máquina espera 4 minutos (de forma predeterminada) antes de liberar el puerto. Esto se denomina estado TIME_WAIT. Durante este TIME_WAIT estado, se pueden procesar los paquetes pendientes para la conexión TCP. Una vez completado el estado TIME_WAIT, se liberan todos los recursos asignados para la conexión.

• Un restablecimiento de TCP es un cierre de sesión abrupto, lo que provoca la liberación inmediata de los recursos asignados y la eliminación de toda la información de conexión. Esto se identifica mediante la marca RESET en el encabezado TCP que se establece en 1. Un seguimiento de red recopilado simultáneamente en el origen y el destino le ayuda a determinar el flujo del tráfico e identificar el punto de error.

En las secciones siguientes se describen los escenarios en los que podría producirse un RESET.

Pérdida de paquetes a través de la red

Cuando un par TCP envía paquetes sin recibir una respuesta, el mismo nivel retransmite los datos. Si todavía no hay respuesta, la sesión finaliza con un RESTABLECIMIENTO de ACK, lo que indica que la aplicación reconoce los datos intercambiados pero cierra la conexión debido a la pérdida de paquetes.

Los seguimientos de red simultáneos en el origen y el destino pueden comprobar este comportamiento. En el lado de origen, puede ver los paquetes retransmitidos. En el lado de destino, estos paquetes no están presentes. Este escenario indica que un dispositivo de red entre el origen y el destino está quitando los paquetes.

Escenario 1: Pérdida de paquetes durante el protocolo de enlace TCP inicial

Si se produce un error en el protocolo de enlace TCP inicial debido a caídas de paquetes, el paquete TCP SYN se retransmite tres veces de forma predeterminada.

Nota:

El número de veces que se retransmite el paquete TCP SYN puede ser diferente en función del sistema operativo. Esto viene determinado por el valor Max SYN Retransmissions en parámetros TCP Global , que se pueden ver mediante el comando netsh int tcp show global.

Supongamos que una máquina de origen con la dirección IP 10.10.10.10.1 se está conectando al destino con la dirección IP 10.10.10.2 a través del puerto TCP 445. A continuación se muestra una captura de pantalla del seguimiento de red recopilado en la máquina de origen, que muestra el protocolo de enlace TCP inicial donde se envía el paquete TCP SYN y, a continuación, lo retransmite el origen, ya que no se recibió ninguna respuesta desde el destino.

La misma conversación TCP vista en el seguimiento de red recopilada en el destino muestra que el destino no recibió ninguno de los paquetes anteriores. Esto implica que el paquete TCP SYN se quitó a través de la red intermedia.

Si los paquetes TCP SYN llegan al destino, pero el destino no responde, compruebe si el puerto TCP al que está conectado está en estado LISTENING en la máquina de destino. Esto se puede comprobar en la salida del comando netstat -anob.

Si el puerto está escuchando y todavía no hay respuesta, podría haber una caída en la Plataforma de filtrado de Windows (PMA).

Escenario 2: Pérdida de paquetes durante la transferencia de datos después del establecimiento de la conexión TCP

En un escenario en el que un paquete de datos enviado después de establecer la conexión TCP se quita a través de la red, TCP retransmite el paquete cinco veces de forma predeterminada.

Supongamos que una máquina de origen con la dirección IP 192.168.1.62 ha establecido una conexión con la máquina de destino que tiene la dirección IP 192.168.1.2 a través del puerto TCP 445. La máquina de origen envía datos (paquete De negociación SMB), que se retransmite cinco veces, como se muestra a continuación. Después de no responder desde el destino, la máquina de origen envía un ACK-RST para cerrar esta conexión TCP.

Origen 192.168.1.62 seguimiento lateral:

No vería ninguno de los paquetes anteriores llegando al destino.

Debe interactuar con el equipo de red interno para investigar los diferentes saltos entre el origen y el destino y comprobar si alguno de los saltos puede provocar caídas de paquetes.

Parámetro incorrecto en el encabezado TCP

Este comportamiento se produce cuando los dispositivos intermedios de la red modifican paquetes, lo que provoca que TCP al final receptor los rechace. Por ejemplo, el número de secuencia TCP podría modificarse o un dispositivo intermediario podría reproducir los paquetes con un número de secuencia TCP modificado.

Un seguimiento de red simultáneo en el origen y el destino puede ayudar a identificar las modificaciones en los encabezados TCP.

Comience comparando los seguimientos de origen y destino para detectar los cambios en los paquetes o la presencia de nuevos paquetes que llegan al destino en nombre del origen.

En tales casos, se recomienda buscar ayuda del equipo de red interno para identificar los dispositivos que modifican o reproducen paquetes en el destino. Entre los culpables comunes se incluyen los dispositivos Riverbed o los aceleradores WAN.

Restablecimiento de nivel de aplicación

Cuando haya determinado que los restablecimientos no se deben a caídas de paquetes, parámetros incorrectos o modificaciones de paquetes (como se identifica a través de seguimientos de red), puede concluir que el problema es un restablecimiento en el nivel de aplicación.

Los restablecimientos de nivel de aplicación se caracterizan por la marca Confirmación (ACK) que se establece en 1 junto con la marca Reset (R). Esto indica que el servidor confirma la recepción del paquete, pero no acepta la conexión por algún motivo. Este problema suele producirse cuando la aplicación que recibe el paquete encuentra algo inaceptable en los datos.

En las capturas de pantalla siguientes, puede observar que los paquetes tanto en el origen como en el destino son idénticos, sin modificaciones ni caídas. Sin embargo, el destino envía un restablecimiento explícito al origen.

Seguimiento del lado de origen:

Seguimiento del lado de destino:

Un paquete TCP marcado ACK+RST también puede producirse cuando se envía un paquete TCP SYN. El paquete TCP SYN lo inicia la máquina de origen para establecer una conexión en un puerto específico. Sin embargo, si el servidor de destino no quiere aceptar el paquete por cualquier motivo, el servidor responde con un paquete ACK+RST.

En tales casos, es esencial investigar la aplicación que provoca el restablecimiento (identificado por números de puerto) para comprender por qué se restablece la conexión.

Nota:

La información anterior se refiere a los restablecimientos desde una perspectiva TCP y no UDP. UDP es un protocolo sin conexión y los paquetes se envían indistintamente. Por lo tanto, no se observan retransmisiones ni restablecimientos cuando se usa UDP como protocolo de transporte. Sin embargo, UDP utiliza ICMP como protocolo de notificación de errores. Cuando se envía un paquete UDP a un puerto que no aparece en el destino, el destino responderá inmediatamente con un mensaje "Host de destino inaccesible: Puerto inaccesible".

10.10.10.1  10.10.10.2  UDP UDP:SrcPort=49875,DstPort=3343
 
10.10.10.2  10.10.10.1  ICMP    ICMP:Destination Unreachable Message, Port Unreachable,10.10.10.2:3343

Durante la solución de problemas de conectividad TCP/IP, puede observar en el seguimiento de red que una máquina recibe paquetes, pero no responde a ellos. Esto podría indicar una caída en la pila de red del servidor de destino.

Para determinar si el Firewall de Windows local está quitando el paquete, habilite la auditoría de la Plataforma de filtrado de Windows (PMA) en el equipo con el siguiente comando.

auditpol /set /subcategory:"Filtering Platform Packet Drop" /success:enable /failure:enable

A continuación, puede revisar los registros de eventos de seguridad para identificar una colocación de paquetes en un puerto TCP y una dirección IP específicos, junto con un identificador de filtro PMA asociado.

A continuación, ejecute el comando netsh wfp show state que genera un archivo wfpstate.xml .

Puede abrir este archivo mediante el Bloc de notas y filtrar el identificador que se encuentra en los registros de eventos (por ejemplo, 2944008 en el evento de ejemplo). El resultado revela el nombre de la regla de firewall asociado al identificador de filtro que está bloqueando la conexión.