Redes

Localizar problemas de red esquivos

Christopher Stoneff

Resumen:

• Las causas más frecuentes de problemas de red
• Ver más allá de lo obvio
• Cuando las herramientas de solución de problemas no ayudan
• Por qué es necesario configurar los límites de la conexión

Probablemente ha visto como sucede en muchas ocasiones, su equipo no puede comunicarse con otros equipos y no sabe por qué. Su sistema de administración está situado en un segmento de red conectada a otros segmentos de red por medio de un enrutador, como Microsoft Internet

Security and Acceleration (ISA) Server u otro dispositivo de hardware. Cuando intenta administrar 10, 20, ó incluso 100 sistemas, no encuentra ningún problema. Pero cuando intenta administrar 500 sistemas, su equipo no puede comunicarse en la red excepto con los equipos con los que ya tiene conexiones abiertas. No puede comunicarse con ningún otro sistema, ni puede obtener acceso a Internet, pero además nadie de la red, incluso los de su propio segmento, está experimentando este fenómeno. ¿Dónde buscar en primer lugar?

Diagnóstico del problema

La suposición más común en esta situación es que el software de administración tiene errores. Muchas herramientas de administración proactivas conectan y administran sus sistemas, pero a veces estas mismas herramientas pueden causar el problema que tratan de localizar. Eso es porque una herramienta de administración proactiva puede generar miles de conexiones a sus dispositivos buscando una mejor administración. Windows® mantendrá estas conexiones abiertas durante dos minutos de forma predeterminada aún cuando las conexiones estén inactivas, a menos que la herramienta, la aplicación o el servicio las mantenga conectadas durante más tiempo. Esto significa que aunque su sistema de administración no haya hablado con ningún equipo en dos minutos, todavía puede tener más de 1.000 conexiones abiertas. (Puede ver las conexiones abiertas ejecutando NETSTAT en un símbolo del sistema. El comando NETSTAT le mostrará todas las conexiones abiertas, pendientes y que se estén cerrando en su sistema y le dará su estado. Las descripciones de los mensajes de estado se pueden consultar en RFC 793 en tools.ietf.org/html/rfc793.)

Para excluir los errores del software de administración, puede crear un archivo por lotes que establezca conexiones con los sistemas remotos. Si se produce el mismo problema al ejecutar el archivo por lotes, sabrá que el software de administración y sus subprocesos no tienen la culpa. Aquí tenemos un ejemplo de los contenidos del archivo por lotes requerido:

Net use \\system01\ipc$
Net use \\system02\ipc$
Net use ...

Si el programa de administración en cuestión hubiera conseguido implementar su propia pila de red y autenticación, podría haber sido el culpable, pero en soluciones sin agente, como la mayor parte de estos paquetes de administración, la herramienta usa la pila de red y autenticación del sistema operativo para realizar operaciones de red. El uso de un archivo por lotes que inicie tantas conexiones de red sin causar errores demostrará que el problema no proviene del uso de las pilas de autenticación y red del sistema operativo por parte del programa, ya que el archivo por lotes las usa también.

Registros y mensajes de error que no ayudan

Puede que haya advertido que a medida que las conexiones comienzan a tener errores, recibe información incorrecta del error: error 53: no se encuentra la ruta de acceso de red, error 64: se ha eliminado el nombre de la red y error 1203: ningún proveedor de red aceptó la ruta de acceso proporcionada. Normalmente, todo esto indicaría problemas de resolución de nombres, pero los demás equipos no tienen ningún problema resolviendo los nombres y conectándose a los mismos sistemas. Para comprobar que su configuración de equipo no esté equivocada, simplemente ejecute ipconfig para confirmar que la configuración es correcta.

A continuación, ya que el fenómeno parece estar localizado en su sistema de administración, debería mirar los registros de eventos. La búsqueda de los registros de aplicaciones no da resultados, aunque en el registro de sistema encuentra un evento de advertencia 4226 de origen de evento TCP/IP que indica que se había alcanzado el número máximo de conexiones (consulte la figura 1).

Figura 1** Se ha alcanzado el límite de la conexión TCP **

Si realizamos una búsqueda exhaustiva de "límites de conexión" en Microsoft® Knowledge Base, ésta revelará el hecho de que hay límites de conexión impuestos a las conexiones incompletas, pero no hay límites en las conexiones completadas. Puede ajustar las siguientes entradas del registro en HKLM\System\CurrentControlSet\Services\TCPIP\Parameters para controlar los factores mencionados: TcpNumConnections se usa para establecer el número máximo de conexiones que TCP puede tener abiertas al mismo tiempo (el valor predeterminado es 10). TCPTimedWaitDelay establece el tiempo que una conexión permanece en la condición TIME_WAIT cuando se está cerrando. La mitad de vida predeterminada es 120 segundos, lo cual significa que una conexión está esencialmente en uso durante 4 minutos. Por último, MaxFreeTcbs cumple también una función en el número máximo de conexiones. Si todos los bloques de control de TCP están en uso, TCP debería iniciar conexiones que aparecen en la lista con el estado TIME_WAIT para crear más conexiones, aunque TCPTimedWaitDelay no haya expirado todavía. TCPTimedWaitDelay tiene un valor dentro del intervalo 30-300 segundos (0x1E – 0x12C).

Dependiendo de su situación, podrá ver una ligera mejoría en el rendimiento global realizando estos cambios en el registro. Otro paso que puede intentar es aplicar un parche al archivo TCPIP.sys para quitar estos límites, pero esto sólo ofrece mejoras en aplicaciones P2P.

Capturas de red

Tras otros intentos infructuosos por resolver los problemas de conexión, realizar una captura de red de los equipos implicados parece una buena idea. Al ejecutar Microsoft Network Monitor (Netmon), se produjeron capturas que mostraron los resultados exactos que se veían en las herramientas de administración y los scripts de prueba: todo funciona correctamente y después ya no, sin que haya más indicación de error.

La figura 2 muestra el resultado de ejecutar Netmon, que indicó comunicación correcta entre los primeros n sistemas. Tenga en cuenta que obtengo los reconocimientos de solicitudes RPC. Esto es lo que se desea ver, una comunicación bidireccional correcta.

Figura 2** Comunicación correcta en Netmon **(Hacer clic en la imagen para ampliarla)

Ahora necesita ver las capturas del sistema de administración y los equipos remotos que parecen mostrar el error 53/1203. Como cabría esperar, no hay nada que ver, ya que los equipos no se comunican. En la captura de red en la figura 3, el sistema de administración ha resuelto la dirección IP e intenta conectarse al sistema a través del puerto 445 (el puerto Microsoft SMB) pero nunca recibe una respuesta.

Figura 3** Los intentos para conectar al sistema a través del puerto 445 no dan respuesta **(Hacer clic en la imagen para ampliarla)

El error que recibe cuando tiene más subprocesos de los que su equipo puede conectar realmente no es siempre coherente. A veces puede ver en el sistema origen un error 53, que indica que ha recibido la resolución de nombre pero que no se ha podido encontrar la dirección IP. Esto indica que el DNS proporciona una dirección a la que no puede conectarse. Puede que reciba un error 1203, que indica que ningún equipo ha respondido al nombre ni la dirección IP que ha solicitado. El error 1203, en este caso, indica que ese DNS no está disponible. Verá que ese es el caso si ejecuta nslookup.

En este punto se debe sentir casi frustrado, pero hay más opciones a tener en cuenta. La mayoría de las personas ni tan siquiera pensarán en echar un vistazo a la infraestructura de conexión por la manera en la que se presenta este problema: su equipo es el único que no puede conectarse al resto de la red y los registros de eventos muestran que su equipo ha alcanzado el número máximo de conexiones permitidas, así que el problema no parece tener su origen en la arquitectura.

Aunque las miles de conexiones generadas por su solución de administración no se iniciarán al mismo tiempo, los mantenimientos y los tiempos muertos de conexión pueden significar que tiene más conexiones abiertas de las que cree. Por lo tanto, debe examinar también esos sistemas que se conectan al resto de su red.

Déjeme explicarlo. Como he mencionado anteriormente, cuando el tráfico de red pasa a través de la red, atraviesa conmutadores, enrutadores y quizás firewalls. En cualquiera de estos puntos, generalmente en el enrutador o en el firewall, pueden haber sistemas de detección de intrusos. Los conmutadores y enrutadores administrados pueden emplear también el filtrado de tráfico. Usted, o quien tenga el control de estos dispositivos, necesitará comprobar los registros en busca de errores o advertencias. El problema de comunicación puede estar dentro de estos sistemas.

Como está conectando desde un sistema interno a otros sistemas internos, puede ver que no se están generando alertas, porque las alertas no están configuradas en el dispositivo o porque el problema no está calificado como intrusión o ataque de denegación de servicio (DoS). Una vez más, debe empezar con los registros. Si usamos el servidor ISA como ejemplo, estos registros se pueden encontrar en la consola de Administración del Servidor ISA en Matrices\<NombreMatriz>\Supervisión\Registro.

Si hay una directiva que lo está bloqueando, puede (en el caso de Servidor ISA) buscar los siguientes códigos de resultado donde la IP de origen es su equipo de administración:

• 0xc0040037 FWX_E_TCP_RATE_QUOTA_EXCEEDED_DROPPED
• 0xc004000d FWX_E_POLICY_RULES_DENIED
• 0xc0040017 FWX_E_TXP_SYN_PACKET_DROPPED

Si encuentra estos resultados, ha identificado la raíz de sus problemas de conectividad.

Implementación de la solución

Ahora que ha identificado el problema, la solución puede ser sencilla, pero las directivas del departamento pueden hacer que sea difícil implementarla. Antes de hacer ningún cambio, asegúrese de que tiene los permisos apropiados para realizarlos, ya que no siempre se permite crear exclusiones en las configuraciones de seguridad de los firewalls, enrutadores y/o los sistemas de detección de intrusos.

De nuevo, usando el servidor ISA como ejemplo, los pasos siguientes muestran cómo aumentar el número máximo de conexiones para un host dado o para todos los equipos en la red (como se muestra en la figura 4). Abra la consola de administración del servidor ISA y navegue hasta Matrices\<NombreMatriz>\Configuración\General\Configurar mitigación de ataques ''flood'' de congestión del servidor.

Figura 4** Aumente el número máximo de conexiones para un host o todos los equipos que usan el servidor ISA **

La dos configuraciones de interés son el máximo de conexiones TCP simultáneas por dirección IP y el máximo de solicitudes de conexión TCP por minuto por dirección IP. Las conexiones TCP simultáneas máximas por dirección IP se establecen normalmente en un valor que sería suficiente cuando no se produjera la administración activa, lo cual implica que ningún equipo se conecta activamente a miles de equipos rápidamente. En el servidor ISA, el límite predeterminado para el máximo de conexiones TCP simultáneas es 160. El máximo de solicitudes de conexión TCP por minuto por dirección IP está diseñado para limitar el daño y la visibilidad de las exploraciones de red. El límite predeterminado es 600 solicitudes de conexión por minuto por IP.

Como se ha indicado anteriormente, Windows mantendrá una conexión activa por un período predeterminado de dos minutos siempre que sólo intente mantener activa la conexión, incluso si la conexión no está en uso. Esto significa que aunque ya haya administrado correctamente un equipo y no necesite comunicarse más con el mismo, la conexión se mantendrá activa. Esta conexión abierta cuenta en el total de conexiones asignadas. Repita este proceso más de 160 veces sin eliminar conexiones y encontrará que todos los intentos de conexión le son denegados por el enrutador. Incluso si su programa de administración elimina activamente una sesión, Windows puede dejar la conexión en un estado time_wait que espera al equipo objetivo para desconectar la sesión.

Comience a realizar ajustes en el culpable más probable: el máximo de conexiones TCP simultáneas por dirección IP. Debe establecer esto para que su equipo de administración pueda crear todas las conexiones que necesita para administrar sus sistemas sin que se le deniegue el acceso. Haga clic en el botón Editar junto a la configuración y cambie los valores.

El mensaje siguiente (consulte la figura 5) tiene un cuadro Límite que representa el límite predeterminado, aplicable a todos clientes. El límite personalizado se aplica a todos los equipos, redes, etcétera que se definen en la ficha de Excepciones IP del cuadro de diálogo de mitigación de ataques ''flood''. Si desea permitir a cada equipo crear más conexiones, cambie el valor del Límite. Para configurar la excepción sólo para su equipo de administración, ajuste el límite personalizado y agregue su equipo a la ficha Excepciones IP. Normalmente es mejor permitir la excepción sólo para su propio equipo.

Figura 5** Límite predeterminado de conexión y límite personalizado de conexión **

Si desea usar el límite personalizado para modificar este valor sólo para sistemas específicos, cambie el valor en el campo Límite Personalizado y haga clic en Aceptar. Después agregue su equipo a la ficha Excepciones IP en el cuadro de diálogo de mitigación de ataques ''flood''. Para agregar solamente su equipo a la lista de excepciones, en las Excepciones IP haga clic en Agregar para hacer aparecer el cuadro de diálogo Conjuntos de equipos. Haga clic en Nuevo para crear un nuevo conjunto de red para contener su sistema o sistemas, si no existe un conjunto de red que contenga estos equipos. Seleccione este conjunto de red y haga clic en Agregar para agregar el conjunto de red de Redes Internas y haga clic en Cerrar. Seleccione el conjunto de red Redes internas de nuevo y haga clic en Editar. Esto abrirá las propiedades de Redes internas (consulte la figura 6). Haga clic en Agregar en este cuadro de diálogo para mostrar un submenú en el que puede elegir agregar un equipo, intervalo de direcciones o subred; elija el equipo. Escriba un nombre que identifique la entrada, la dirección IP del equipo y una descripción para que cualquiera que vea la entrada no se vea tentado a quitar su sistema (consulte la figura 7). Haga clic en Aceptar para agregar su sistema y haga clic de nuevo para agregar la excepción. Ahora que ha realizado estos cambios, debe aplicar la configuración.

Figura 6** Configuración de propiedades de redes internas **

Figura 7** Escriba el nombre de equipo, la dirección IP y la descripción para asegurar que su sistema no sea eliminado **

Pruebe su herramienta de administración proactiva otra vez y debería comprobar que el rendimiento es mucho mejor y la conexión no tiene errores, al menos no como resultado del tráfico de red. Al final, resulta que el problema no era el número de conexiones iniciadas por el software, era la falta de planeación correcta para esas conexiones la que causaba la interrupción.

Lecciones aprendidas

Uno de los mayores quebraderos de cabeza en TI es experimentar y resolver los problemas realmente esquivos. Son problemas que el usuario final no ha creado, el equipo del servidor tampoco los ha causado, el servicio de soporte técnico no los conoce y, desgraciadamente, puede ser responsabilidad suya arreglarlos. Hay infinidad de herramientas disponibles para ayudarle a identificar, aislar y solucionar problemas, pero a veces las herramientas no son suficientes. A veces las herramientas se equivocan. Y a veces necesita ser más listo que las propias herramientas.

La próxima vez que no pueda establecer conexiones entre un número de equipos en la red sin razón obvia, pruebe los pasos que he descrito aquí. Hay una gran probabilidad de que siguiendo estos pasos, observando su software de administración más detenidamente y configurando las conexiones permitidas correctamente, pueda resolver el problema correctamente.

Christopher Stoneff es administrador de producto en Lieberman Software (liebsoft.com), un desarrollador de software de seguridad y administración de sistemas. Chris posee más certificaciones técnicas de las que debería tener una persona en su sano juicio. Su mayor virtud no es sólo saber cómo funciona algo de una cierta manera, sino también saber por qué.

© 2008 Microsoft Corporation and CMP Media, LLC. Reservados todos los derechos; queda prohibida la reproducción parcial o total sin previa autorización.