Guía de solución de problemas de comunicación TCP/IP

Artículo
01/15/2025

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

Este artículo está diseñado para ayudarle a solucionar problemas de comunicación tcp/IP.

Herramienta para la solución de problemas

El comando ping es útil para probar la conectividad básica. Sin embargo, no debe confiar en él para demostrar la conectividad general. Telnet y PsPing son más útiles por los siguientes motivos:

Estas herramientas pueden probar la conectividad a la capa de aplicación usando TCP o UDP (solo PsPing) como protocolo de transporte.
Puede especificar qué puerto se usará. Por lo tanto, puede navegar por los puertos abiertos de un firewall.
Puede conectarse a cualquier puerto de "escucha" en el nodo de destino para comprobar el acceso al puerto de una aplicación específica.

Lista de comprobación de solución de problemas

Paso 1: Capturar un diagrama de red

Capture un diagrama de red que detalle los dispositivos que están en la ruta de acceso al área afectada. En concreto, tenga en cuenta los siguientes dispositivos:

Firewalls
IPS (sistemas de protección y prevención de intrusiones)
PPP (inspección profunda de paquetes)
Aceleradores de WAN

El diagrama puede ayudarle a visualizar e identificar dónde buscar la causa del problema.

Paso 2: Seguimientos de redes

Los seguimientos de red son útiles para ver lo que ocurre en el nivel de red cuando se produce el problema.

Paso 3: Hacer ping a la dirección IP local del equipo

Intente hacer ping a la dirección IP local del equipo.

Si el nodo no puede hacer ping a su dirección IP local, la pila local no funciona. Observe los mensajes de error que se muestran.

Si recibe un error general de error , este error significa que no hay interfaces válidas para procesar la solicitud. Este problema podría deberse a un problema de hardware o a un problema de pila.

Vea si aparece una "X" roja o un signo de exclamación amarillo en el icono Conexión de red en la bandeja del sistema. Una X roja indica que Windows no detecta una conexión de red. Un signo de exclamación amarillo significa que el indicador de estado de la conexión de red (NSCI) no ha podido realizar una comprobación de sondeo.

Para solucionar este problema, compruebe que el adaptador de red notifica conectividad. Asegúrese de que el adaptador de red está conectado y que el puerto del conmutador en el que está conectado el nodo no está en estado de error. Puede cambiar los cables, los puertos de conmutador y los adaptadores de red para reducir dónde se produce este problema. Sin embargo, en última instancia, el problema está fuera del sistema operativo. Para investigarlo más a fondo, póngase en contacto con los proveedores de hardware.

También puede producirse un problema entre el controlador de red y Windows. Este problema suele deberse a daños en la pila. Use los siguientes pasos de solución de problemas:

Asegúrese de que dispone de los bits más recientes del nodo (TCP/IP, NDIS, AFD, Winsock, entre otros).
Restablezca IP y Winsock mediante la ejecución de los siguientes comandos. Realice una copia de seguridad de toda la configuración de red.
```
netsh -c interface dump > C:\netConfig.txt
netsh int ip reset
netsh winsock reset
```
Reiniciar el nodo.
Restaure la configuración de red después del reinicio. Esta operación solo funciona si los nombres de interfaz no han cambiado o el script se actualiza para usar los nuevos nombres.
```
netsh -f C:\netConfig.txt
```
Desinstale o vuelva a instalar el controlador del adaptador de red, según corresponda.
Busque y quite los controladores de filtro de terceros (por ejemplo, antivirus).
Intente iniciar el equipo en Modo seguro con funciones de red. Si el modo seguro con redes funciona, ejecute un proceso de "arranque limpio" deshabilitando todas las aplicaciones y servicios de terceros dentro de MSConfig, vuelva a habilitarlos uno por uno hasta que se devuelva el problema. A continuación, puede ponerse en contacto con el proveedor para obtener soporte técnico.
1. Si nada de esto funciona, puede que el problema tenga que ver con que el Registro está dañado.
2. Si tiene una copia de seguridad del Registro (como una copia de seguridad física o un punto de restauración del sistema), puede intentar restaurar el nodo a una configuración de trabajo anterior. Detectar la causa principal de la corrupción puede ser difícil y muy lento. Incluso si se encuentra la corrupción, sabiendo lo que causó es aún más difícil. La modificación manual de la clave del Registro dañada coloca el nodo en un estado no admitido. Por lo tanto, se recomienda que el cliente restaure o vuelva a cargar el nodo para corregir los daños.

Si el NSCI produce un error en su comprobación de sondeo (signo de exclamación amarillo), esto no indica necesariamente un problema de conectividad. Asegúrese de que la comunicación típica se está produciendo como debería.

En caso afirmativo, la investigación debe centrarse específicamente en por qué el NCSI no pasa las comprobaciones de sondeo. Los detalles de este problema se tratan en un tema aparte.
En caso negativo, investigue primero los problemas de conectividad, ya que es probable que se corrija una vez restaurada la conectividad.

Paso 4: Solución de problemas de mensajes de error que se producen durante la prueba de ping o telnet

Si el nodo puede hacer ping o comunicarse mediante Telnet a los nodos de la misma subred o segmento de red, se confirmaría que la conectividad externa funciona. Todavía es necesario realizar pruebas adicionales para saber si existe un problema de la conectividad básica.

Si el nodo no puede hacer ping o telnet a los nodos del mismo segmento de subred o red. Observe los mensajes de error que se muestran.

El error inaccesible del host de destino significa que las solicitudes de ARP enviadas por el nodo no reciben una respuesta.
Recopile un seguimiento en dos lados de los nodos entre los que está probando. Asegúrese de que la solicitud de ARP enviada por el nodo de origen llega al nodo de destino y que el nodo de destino responde en consecuencia. Esta respuesta debería verse en el seguimiento de origen. Si se produce un error en este proceso, es probable que el problema se deba a una configuración incorrecta u otros problemas que afecten a la infraestructura.

Las posibles causas pueden ser:
1. VLAN incorrectas o no coincidentes.
2. Una configuración incorrecta del puerto del conmutador (puerto de enlace frente a puerto de acceso).
3. Otros problemas de hardware.
El error de tiempo de espera de solicitud significa que la solicitud de ARP obtuvo una respuesta, pero la solicitud de eco ICMP enviada por el nodo no recibe una respuesta de eco ICMP. Esto, solo, no indica un problema. El software de red o del firewall podría estar bloqueando el tráfico de ICMP en los nodos. Podría ser beneficioso desactivar los perfiles de firewall (Windows) o deshabilitarlos mediante el método admitido por el proveedor del firewall para probar ICMP.
1. Telnet y PsPing son más adecuados para las pruebas. Ejecute Telnet o PsPing del nodo de origen al nodo de destino en un puerto de escucha (por ejemplo, 445).
2. Si el paso 1 se realiza correctamente, es que la conectividad externa funciona. Siga probando la conectividad básica.
3. Si el paso 1 no es correcto (y si los perfiles de firewall están deshabilitados), recopile un seguimiento de escenarios de netsh netconnection dos lados para solucionar problemas.

Paso 5: Ping o Telnet a la puerta de enlace predeterminada

Cuando el nodo puede hacer ping a su puerta de enlace predeterminada, la conectividad externa es posible desde el nodo de origen. Seguiría siendo necesario realizar pruebas adicionales para saber si existe un problema con la conectividad básica. Si el nodo no puede hacer ping o Telnet a su puerta de enlace predeterminada, esto significa que las respuestas ICMP están deshabilitadas en el enrutador.

Paso 6: Comprobación de problemas que afectan al nodo de destino específico

Si el nodo de origen puede hacer ping, Telnet o PsPing a otros nodos de la subred de destino, la conectividad básica y el enrutamiento dentro de la infraestructura funcionan. Este resultado apunta a un problema que afecta al nodo de destino específico.

Pruebe a conectarse mediante Telnet o PsPing al puerto específico en el que escucha la aplicación (por ejemplo, el puerto TCP 445 para SMB). Si la conexión se realiza correctamente, se puede confirmar la conectividad básica de nivel de aplicación. En esta situación, tendrá que ponerse en contacto con el proveedor de la aplicación para que le ayude a investigar por qué la aplicación no se conecta.

Nota:

El proveedor de la aplicación podría ser Microsoft si el problema es un error al conectarse a un recurso compartido, por ejemplo. En estas situaciones, sería útil realizar un seguimiento del escenario netsh netconnection en los dos lados para recopilar información adicional y ayudarle a comprobar que no hay ningún problema en la pila de red.
Si la conexión al puerto específico no se realiza correctamente:
1. Asegúrese de que el puerto está en estado "escuchando":
  CMD: netstat -nato | findstr :<port>
  PowerShell: Get-NetTcpConnection -LocalPort <port>
2. Deshabilite temporalmente todos los perfiles de firewall. (Nota: Deshabilite solo los perfiles. No deshabilite el servicio).
  Si esto funciona, el firewall debe volver a configurarse para permitir el tráfico de la aplicación en su puerto específico.
3. Quite todas las aplicaciones de terceros de una a una y pruebe entre cada eliminación.
  Si esto funciona, póngase en contacto con el proveedor del software problemático.
4. Pruebe Modo seguro con funciones de red.
  Si esto se realiza correctamente, aísle la causa mediante la ejecución de un "arranque limpio" del nodo mediante MSConfig y, a continuación, habilite aplicaciones y servicios de terceros uno por uno hasta que se repita el problema.
5. Al reproducir el intento de conexión, debe ejecutar un seguimiento del escenario netsh netconnection desde el origen hasta el nodo de destino afectado. También podría ser beneficioso un SDP de red.
Si el nodo no puede hacer ping, Telnet o PsPing a otros nodos de la subred de destino, es probable que el problema esté relacionado con la infraestructura. De nuevo, ICMP podría estar bloqueado dentro del entorno. Por lo tanto, compruebe la conectividad mediante Telnet o PsPing para conectarse a los puertos de escucha conocidos. En este momento, se necesita un seguimiento de red en los dos lados para mostrar dónde se produce la pérdida de paquetes en la red. Asegúrese de que ambos seguimientos se ejecutan antes de intentar la prueba de conectividad para capturar el problema.

Problemas comunes y soluciones

Parece que la conexión TCP/IP a un host se ha detenido

Este problema se produce porque los datos están bloqueados en colas TCP y UDP o hay problemas de retraso de software de nivel de usuario o de red.

Para solucionar este problema, use el netstat -a comando para mostrar el estado de toda la actividad en los puertos TCP y UDP en el equipo local.
El estado de una buena conexión TCP se establece mientras tiene cero (0) bytes en las colas de envío y recepción. Si los datos están bloqueados en alguna de las colas o si el estado es irregular, es probable que la conexión tenga un error. Si no es así, es probable que experimente un retraso en la red o en el software de nivel de usuario.

Tiempos de conexión largos cuando se usan Lmhosts para la resolución de nombres

Este problema se produce porque el archivo Lmhosts se analiza secuencialmente para buscar entradas sin la opción #PRE.

Para solucionar este problema, coloque entradas usadas con frecuencia cerca de la parte superior del archivo y las #PRE entradas cerca de la parte inferior. Si se agrega una entrada al final de un archivo lmhosts grande, marque la entrada en Lmhosts como una entrada precargada mediante la opción #PRE. A continuación, ejecute el comando nbtstat -R para actualizar la caché de nombres local inmediatamente.

Error del sistema 53

Se devuelve el error 53 del sistema si se produce un error en la resolución de nombres para un nombre de equipo determinado cuando se usa el net use comando.

Si el equipo está en la subred local, compruebe que el nombre está escrito correctamente y que el equipo de destino también ejecuta TCP/IP. Si el equipo no está en la subred local, asegúrese de que su nombre y asignación de direcciones IP están disponibles en el archivo Lmhosts o en la base de datos WINS. Si todos los elementos TCP/IP parecen estar instalados correctamente, use el ping comando junto con el equipo remoto para comprobar que su software TCP/IP funciona.

No se puede conectar a un servidor específico

Este problema se produce porque la resolución de nombres NetBIOS no resuelve el nombre o se está resolviendo la dirección IP incorrecta.

Para solucionar este problema, use el nbtstat -n comando en el servidor para determinar qué nombres registró el servidor en la red. El nombre de equipo del equipo al que intenta conectarse debe estar en la lista mostrada. Si el nombre no aparece en la lista, pruebe uno de los otros nombres de equipo únicos que muestra nbtstat. Si el nombre que usa un equipo remoto es el mismo que el nombre que muestra el nbtstat -n comando, asegúrese de que el equipo remoto tiene una entrada para el nombre del servidor que se encuentra en el servidor WINS o en su archivo Lmhosts.

No se puede añadir una puerta de enlace predeterminada

Este problema se produce porque la dirección IP de la puerta de enlace predeterminada no está en el mismo identificador de red IP que la dirección IP.

Para solucionar este problema, determine si la puerta de enlace predeterminada se encuentra en la misma red lógica que el adaptador de red del equipo comparando la dirección IP de la puerta de enlace predeterminada con los identificadores de red de cualquiera de los adaptadores de red del equipo.

Por ejemplo, un equipo tiene un único adaptador de red configurado con una dirección IP de 192.168.0.33 y una máscara de subred de 255.255.0.0. Esto requiere que la puerta de enlace predeterminada tenga el formato "192.168.<y>.<z>" porque la parte del identificador de red de la interfaz IP es 192.168.0.0.

Recolección de datos

Antes de ponerse en contacto con el soporte técnico de Microsoft, puede recopilar información sobre su problema.

Requisitos previos

TSS debe ejecutarse con cuentas con privilegios de administrador en el sistema local y el CLUF debe aceptarse (una vez que se acepte el CLUF, TSS no volverá a preguntar).
Se recomienda la directiva de ejecución de PowerShell del equipo RemoteSigned local.

Nota:

Si la directiva de ejecución de PowerShell actual no permite ejecutar TSS, realice las siguientes acciones:

Establezca la RemoteSigned directiva de ejecución para el nivel de proceso mediante la ejecución del cmdlet PS C:\> Set-ExecutionPolicy -scope Process -ExecutionPolicy RemoteSigned.
Para comprobar si el cambio surte efecto, ejecute el cmdlet PS C:\> Get-ExecutionPolicy -List.
Dado que los permisos de nivel de proceso solo se aplican a la sesión actual de PowerShell, una vez que se cierra la ventana de PowerShell especificada en la que se ejecuta TSS, el permiso asignado para el nivel de proceso también volverá al estado configurado anteriormente.

Recopilar información clave antes de ponerse en contacto con el soporte técnico de Microsoft

Descargue TSS en todos los nodos y descomprima en la carpeta C:\tss .
Abra la carpeta C:\tss desde un símbolo del sistema de PowerShell con privilegios elevados.
Inicie los seguimientos en el servidor de origen y destino mediante el siguiente cmdlet:
```
TSS.ps1 -Scenario NET_General
```
Acepte el CLUF si los seguimientos se ejecutan por primera vez en el servidor de origen o de destino.
Permitir grabación (PSR o vídeo).
Reproduzca el problema antes de escribir Y.

Nota:

Si recopila registros tanto en el cliente como en el servidor, espere este mensaje en ambos nodos antes de reproducir el problema.
Escriba Y para finalizar la recopilación de registros después de reproducir el problema.

Los seguimientos se almacenarán en un archivo ZIP en la carpeta C:\MS_DATA , que se puede cargar en el área de trabajo para su análisis.

Compartir a través de