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

Artículo
12/26/2023

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.

Herramientas de resolución de problemas

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

Estas herramientas pueden probar la conectividad con la capa de aplicación mediante TCP o UDP (solo PsPing) como protocolo de transporte.
Puede especificar qué puerto se usará. Por lo tanto, puede navegar por los puertos abiertos en 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 para la solución de problemas

Paso 1: Capturar un diagrama de red

Capture un diagrama de red que detalle los dispositivos que se encuentran 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 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. Tenga en cuenta los mensajes de error que se muestran.

Si recibe un error general , 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.

Compruebe si ve un carácter rojo "X" o un signo de exclamación amarillo en el icono Conexión de red de la bandeja del sistema. Una X roja indica que Windows no detecta una conexión de red. Un signo de exclamación amarillo indica que el indicador de estado de conexión de red (NSCI) produjo un error en una comprobación de sondeo.

Para solucionar este problema, compruebe que el adaptador de red notifica la conectividad. Asegúrese de que el adaptador de red está conectado y de que el puerto de conmutador donde 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 el lugar donde se produce este problema. Sin embargo, en última instancia, el problema está fuera del sistema operativo. Para investigar más, 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 debese a un daño en la pila. Siga estos pasos de solución de problemas:

Asegúrese de que los bits más recientes del nodo (TCP/IP, NDIS, AFD, Winsock, etc.).
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
```
Reinicie 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 controladores de filtro de terceros (por ejemplo, antivirus).
Intente iniciar el equipo en modo seguro con redes. Si el modo seguro con redes funciona, ejecute un proceso de "arranque limpio" deshabilitando todas las aplicaciones y servicios de terceros dentro de MSConfig y vuelva a habilitarlos uno a uno hasta que se devuelva el problema. A continuación, puede ponerse en contacto con el proveedor para obtener soporte técnico.
1. Si ninguno de estos elementos se realiza correctamente, es probable que el problema sea un daño en el Registro.
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 que funcionaba anteriormente. La captura de la causa principal de la corrupción puede ser difícil y extremadamente lento. Incluso si se encuentra la corrupción, saber lo que causó es aún más difícil. La modificación de la clave del Registro dañada coloca manualmente 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 produce como debería.

Si es así, la investigación debe centrarse específicamente en por qué ncsi está fallando sus comprobaciones de sondeo. Los detalles de esto se tratan en un tema independiente.
Si no es así, investigue primero los problemas de conectividad porque es probable que se corrija después de restaurar 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 telnet a los nodos de la misma subred o segmento de red, esto confirmaría que la conectividad externa funciona. Todavía es necesario realizar pruebas adicionales para saber si existe un problema de conectividad básico.

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

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

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

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

Cuando el nodo puede hacer ping a su puerta de enlace predeterminada, es posible la conectividad externa (como la conectividad de fábrica) desde el nodo de origen. Seguirían siendo necesarias pruebas adicionales para saber si existe un problema de conectividad básico. 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: Comprobar los 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 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 ayudar 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 de netsh netconnection de dos lados para recopilar información adicional y ayudarle a comprobar que no hay ningún problema en la pila de redes.
Si la conexión al puerto específico no se realiza correctamente:
1. Asegúrese de que el puerto está en un estado de "escucha":
  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 se realiza correctamente, el firewall debe volver a configurarse para permitir el tráfico de la aplicación en su puerto específico.
3. Quite las aplicaciones de terceros de una en una y pruebe entre cada eliminación.
  Si esto se realiza correctamente, póngase en contacto con el proveedor del software problemático.
4. Pruebe el modo seguro con redes.
  Si esto se realiza correctamente, aísla la causa ejecutando un "arranque limpio" del nodo mediante MSConfig y, a continuación, habilitando aplicaciones y servicios de terceros uno a uno hasta que el problema vuelva a producirse.
5. Al reproducir el intento de conexión, debe ejecutar un seguimiento del escenario de netsh netconnection desde el origen hasta el nodo de destino afectado. Un SDP de redes también sería beneficioso.
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 bloquearse dentro del entorno. Por lo tanto, compruebe la conectividad mediante Telnet o PsPing para conectarse a puertos de escucha conocidos. En este momento, es necesario realizar un seguimiento de red de 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 probar la prueba de conectividad para que se capture el problema.

Problemas y soluciones comunes

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

Este problema se produce porque los datos se bloquean en las 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 al tener cero (0) bytes en las colas de envío y recepción. Si los datos se bloquean en una cola 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 de software de nivel de usuario o de red.

Tiempos de conexión largos al usar 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 las entradas usadas con frecuencia cerca de la parte superior del archivo y las entradas de #PRE 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 nbtstat -R comando para actualizar la caché de nombres local inmediatamente.

Error del sistema 53

Se devuelve el error del sistema 53 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 la 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 la dirección IP incorrecta se está resolviendo.

Para solucionar este problema, use el nbtstat -n comando en el servidor para determinar qué nombres tiene el servidor registrado en la red. El nombre 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 se muestran en 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 agregar 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 el problema.

Requisitos previos

Las cuentas con privilegios de administrador en el sistema local deben ejecutar el TSS y se debe aceptar el CLUF (una vez aceptado el CLUF, el TSS no volverá a solicitarlo).
Se recomienda la directiva de ejecución de PowerShell del equipo RemoteSigned local.

Nota:

Si la directiva de ejecución actual de PowerShell 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 tiene 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 cerrada la ventana de PowerShell determinada en la que se ejecuta TSS, el permiso asignado para el nivel de proceso también volverá al estado configurado anteriormente.

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

Descargue TSS en todos los nodos y descomprímalo 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 de 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.