Solucionando errores TCP/IP. 7

Nombre NetBIOS o de Host inalcanzable

Ya dijimos que W2k3 permite la comunicación en red entre equipos usando tres tipos de destinos:

• Dirección IP
• Nombre de equipo (Host Name)
• Nombre NetBIOS (NetBIOS Name)

Veamos como podemos intentar dar soluciones a problemas en las dos últimas.

El primer paso es ver que aplicaciones están produciendo errores. Normalmente, en estas aplicaciones se incluyen IExplorer, NET USE, TELNET y FTP. Una vez sabemos cuales fallan, el siguiente paso es determinar si el error se debe a un problema de resolución de nombre de equipo o nombre NetBIOS.

La forma más fácil de distinguir los problemas entre ambas resoluciones es comprobar si la aplicación usa NetBIOS o Sockets. Si usa sockets el problema está relacionado con resolución de nombre de equipo. Las aplicaciones NetBIOS son de largo, las más comunes, incluyendo diversos comandos NET, Windows Explorer, y la superconocida Mis Sitios de Red. Las aplicaciones sockets incluyen IExplorer, otros navegadores, TELNET y FTP.

Error 53

El síntoma más común de un problema de NetBIOS es cuando el comando ping devuelve un mensaje de error 53. Este error generalmente es devuelto cuando falla la resolución a un nombre de equipo particular. También puede ocurrir cuando hay un problema estableciendo una sesión NetBIOS. Para distinguir entre estos dos casos:

• Desde la línea de comandos, escribimos

net view \nombre_equipo

*nombre_equipo es un recurso de red que sabemos que está activo.

Si esto funciona, la resolución de nombres no es probablemente el origen del problema. Con un ping al nombre de equipo podemos confirmarlo, ya que algunas veces la resolución de nombres puede funcionar correctamente cuando net use devuelve un error 53 (como cuando un DNS o WINS tiene una entrada errónea). Si el ping muestra que la resolución falla (con un error de host desconocido), comprobaremos el estado de la sesión NetBIOS.

Para comprobarla:

• Desde la línea de comandos, escribimos

net view \dirección_IP

*La dirección IP del mismo recurso que usamos para identificar la causa del error 53.

Si esto también falla, el problema se encuentra en el establecimiento de una sesión.

Si el equipo está en una subred local, confirmad que el nombre se ha escrito correctamente y que el equipo está ejecutando TCP/IP. Si el equipo no está en una subred local, asegúrenomos de que su nombre y su IP están debidamente relacionados en un DNS, o en los archivos HOSTS o LmHOSTS, o en WINS.

Si todos los elementos TCP/IP parecen bien instalados, con ping comprobaremos que en el equipo remoto TCP/IP funciona.

No podemos conectar con sistemas remotos mediante nombre de equipo

Si el problema no es de NetBIOS, es de sockets, el problema está relacionado con alguna entrada del archivo Hosts o un error en DNS. Para comprobar que sólo funciona correctamente con IPs y no con nombres de equipo, remotamente, comprobaremos ambos: Hosts y DNS en cuanto al equipo que nos da problemas.

Comprobar archivos Hosts

Las entradas del archivo Hosts se usan para crear entradas en la caché de resolución de cliente de DNS, que podemos ver con el comando ipconfig /displaydns. Comprobad los contenidos de la caché de resolución de cliente DNS y las entradas del archivo Hosts.

Comprobar configuración DNS

Si usamos DNS, comprobaremos que las direcciones IP de los mismos están perfectamente configuradas en las propiedades de TCP/IP y en el orden correcto.

Panel de control -> doble-clic en Conexiones de red -> Clic derecho en la conexión, clic en propiedades -> Clic en Protocolo TCP/IP y clic en propiedades -> En las propiedades clic en Avanzadas -> Pestaña DNS -> Comprobamos los DNS.

                                                  

Este procedimiento nos servirá en los equipos que están configurados estáticamente, ya que si son clientes DHCP no tendrán DNS en la lista.

Ping al equipo remoto mediante nombre de equipo y con su dirección IP para ver si la resolución es correcta. Si al nombre falla pero no a la IP, el problema es la resolución. Comprobad los DNS, un ping a sus IP para ver si están en marcha, o abrid una sesión Telnet al puerto 53: si la conexión se establece con éxito el DNS está funcionando. Después de ver que funciona el DNS, con NSlookup podemos enviar solicitudes al DNS y verificar el estado de los registros que estamos comprobando.

Si fallan ambos, el problema debe ser la conectividad de red, sea la conectividad básica o el enrutamiento.

Resolución de nombres mediante servidor DNS

DNS es una base de datos distribuida que relaciona nombres de dominio a datos. Un usuario puede consultar DNS usando nombres conocidos y jerárquicamente, para localizar equipos y otros recursos en una red IP. Esto ha supuesto el reemplazo de lo que una vez realizaba el archivo Hosts. DNS resuelve nombres conocidos a direcciones IP, de una forma transparente y como podemos observar, como ejemplo:

• Un cliente contacta con el servidor DNS con una solicitud recursiva para www.juansa.net. El servidor debe devolver una respuesta o un mensaje de error.
• El DNS comprueba sus archivos de zona y caché para la respuesta, pero no la encuentra. Entonces contacta con un servidor raíz para realizar una consulta iterativa respecto a la solicitud recibida.
• El servidor raíz no conoce la respuesta, y responde con una referencia a un servidor autoritativo del dominio .net.
• El servidor DNS contacta con un servidor en el dominio .net con una consulta iterativa respecto a la solicitud original.
• El servidor DNS en el dominio .net no conoce la respuesta exacta, así que responde con una referencia a un servidor autoritativo en el dominio juansa.net.
• El servidor DNS contacta con el servidor en juansa.net con una consulta iterativa de la solicitud original.
• El servidor en juansa.net conoce la respuesta y responde con la IP correspondiente al nombre solicitado.
• El servidor DNS responde a la solicitud del cliente con la dirección IP para www.juansa.net.

(Esto no es más que un ejemplo que podría darse en internet, hay más info sobre consultas recursivas e iterativas, podemos encontrarla por ejemplo en nuestro propio w2k3, ejecutando hh DNSconcepts.chm desde ejecutar)

Mensajes de error DNS

Los errores en la resolución de nombres pueden ocurrir si las entradas en un servidor o cliente DNS no están correctamente configuradas, sí el servidor no está activo, o si hay un problema con la conectividad de red. Para determinar la causa de cualquier problema de resolución podemos usar la herramienta Nslookup.

Las solicitudes falladas devolverán una variedad de mensajes, dependiendo de la naturaleza del fallo. Por ejemplo, si usamos el siguiente comando:

nslookup equipo_destino

y el servidor no puede resolver el nombre, se mostrará lo siguiente:

Server: Nombre cualificado completo de dominio
Address: Dirección IP del servidor
*** Nombre completo de dominio cualificado no puede encontrar equipo_destino: dominio no existe

En otros casos, las solicitudes sin respuesta:

nslookup equipo_válido
Servidor: IP Address: w.x.y.z
DNS request timed out.
timeout was 2 seconds.

Si el servidor falla en responder a la solicitud, Nslookup devuelve:

*** Can’t find server name for address dirección_ip: No response from server
*** Default servers are not available.

Este mensaje indica que el servidor DNS es inalcanzable, aunque no indica el porqué. El servidor puede estar apagado, el equipo no tener el servicio DNS activo o existir un problema de hardware o enrutamiento.

Resolución de nombre de equipo mediante archivo Hosts

Un equipo que usa el archivo Hosts para llevar a cabo la resolución de nombres sigue unos pasos:

• Equipo A introduce un comando usando el nombre de equipo de Equipo B.
• Equipo A comprueba el contenido de la caché de resolución DNS, que contiene las entradas del archivo Hosts. Cuando el nombre de equipo de Equipo B se encuentra, se resuelve a una dirección IP. Entonces el paquete es envíado usando los procesos de resolución de dirección y determinación de ruta normales.

Los errores del archivo Hosts pueden causar errores de red, como:

• No contenga un nombre de equipo concreto.
• El nombre de equipo en el archivo o en el comando está mal escrito.
• La dirección IP para el nombre de equipo es inválida o incorrecta.
• Hay múltiples entradas para el mismo equipo en distintas líneas. El archivo se usa desde el inicio, así que la primera entrada es la que se propagará a la caché de resolución de cliente DNS.

El archivo Hosts no se actualiza dinámicamente; todas sus entradas son agregadas manualmente, y la IP y el nombre de equipo son siempre separados por uno o más espacios o tabulación. Un ejemplo:

Si estamos teniendo problemas conectando a un equipo remoto mediante su nombre de equipo y usamos el archivo Hosts para la resolución, el problema podría estar en el contenido del archivo. Busquemos el nombre del equipo remoto correctamente escrito en el archivo y por la aplicación que lo usa.

Comprobar el archivo LmHosts

El problema en la  resolución de nombres podría estar en nuestro archivo LmHosts, que se comprueba para direcciones para nombres NetBIOS de forma secuencial de arriba a abajo. Si hay más de una dirección listada para el mismo nombre, se devuelve el primer valor encontrado, tanto si es bueno como si no.

El archivo podemos buscarlo en ruta_del_sistemaSystem32DriversEtc. No existe de forma predeterminada; un ejemplo existe como LmHosts.SAM. Este archivo debe ser renombrado o copiado como LmHosts antes de usarlo.

Aunque el directorio mencionado es el predeterminado, su consulta dependerá del valor en la entrada DataBasePath de la sub-clave del registro HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters.

Esta entrada le dice al equipo local donde debe mirar para el archivo LmHosts.

Tiempo excesivo para conectar usando Lmhosts

Para comprobar la causa de un tiempo excesivo en conectar al añadir una entrada en el archivo, hay que ver el orden de las entradas.

Este problema puede ocurrir cuando un archivo grande tiene la entrada especificada al final del mismo. Para mejorar la resolución de la entrada, marcarla como una entrada precargada mediante el uso de la etiqueta #PRE. Entonces usaremos el comando nbstat -R para actualizar la caché de nombres NetBIOS local inmediatamente.

Alternativamente, podemos emplazarla más alto en el archivo. El archivo se lee desde arriba para la localización de entradas sin la etiqueta #PRE. Por lo tanto, las entradas que sabemos que son utilizadas más frecuentemente deben ir cerca del inicio del archivo y las que llevan la etiqueta al final del mismo archivo.

Comprobar la configuración WINS

Comprobar que la configuración WINS es correcta y en particular que la dirección del servidor WINS es la adecuada.

El procedimiento es el mismo que más arriba hemos utilizado para comprobar la configuración DNS, sólo que esta vez pulsaremos la pestaña WINS y comprobaremos la configuración:

– Añadir la ip del servidor WINS, si no lo está y existe.

– Verificar que Lmhosts lookup esta habilitado.

– También si NetBIOS sobre TCP/IP se asigna desde DHCP si está habilitado o deshabilitado. Sino, habilitar NetBIOS sobre TCP/IP.