Guía de administración de SunLink Server

Servicios de resolución de nombres

La implementación WINS de SunLink Server con TCP/IP requiere una dirección IP exclusiva y un nombre de equipo por cada equipo de la red. Aunque los programas utilizan direcciones IP para conectar los sistemas, los administradores sustituyen estas direcciones por nombres (más fáciles de recordar) al efectuar dicha conexión. Como resultado, las conexiones TCP/IP entre redes precisan de un servicio de resolución de nombres que convierta los nombres de equipos en direcciones IP y las direcciones IP en nombres de equipo.

Una dirección IP es una dirección exclusiva mediante las que otros dispositivos TCP/IP de una red reconocen el equipo que la tiene asignada. En TCP/IP e Internet, el nombre de equipo es el nombre del sistema conocido globalmente más el nombre de DNS (Domain Name System). En la red local, el nombre de equipo es el que se suministra durante la configuración de SunLink Server o de Windows NT. Para garantizar que tanto los nombres como las direcciones IP son exclusivas, los equipos que utilizan NetBIOS sobre TCP/IP registran sus nombres y direcciones IP en la red durante el inicio del sistema.

Nombres NetBIOS y DNS

Los componentes de conexión a red de SunLink Server se basan en una convención de asignación de nombres denominada NetBIOS. En general, los nombres de equipo NetBIOS constan de un solo elemento.

Por el contrario, los componentes TCP/IP se basan en la convención de asignación de nombres de DNS. Los nombres DNS constan de dos partes: el nombre de sistema y el nombre de dominio que, combinados, forman el nombre de dominio completo o FQDN (fully qualified domain name).

Afortunadamente, los nombres de equipo NetBIOS son compatibles con los nombres de sistema DNS, lo que proporciona interoperabilidad entre los dos tipos de componentes. El software de SunLink Server combina el nombre NetBIOS con el nombre de dominio DNS para generar el FQDN.

Nota -

En los sistemas SunLink Server, el nombre de equipo NetBIOS recibe de forma predeterminada el nombre de sistema DNS, pero este valor puede cambiarse si es preciso que los nombres sean exclusivos.

Un equipo puede usar uno o varios de los métodos siguientes para garantizar una resolución de nombres correcta en redes TCP/IP:

Servicio de nombres de Internet para Windows (WINS)

Los equipos pueden utilizar WINS si hay, al menos, un servidor WINS disponible con una base de datos dinámica que asocia los nombres de equipo a direcciones IP. WINS puede utilizarse en combinación con la resolución de nombres broadcast (de "difusión" en terminología de Windows NT) en redes interconectadas donde no pueden utilizarse otros métodos de resolución de nombres. Tal y como se describe en la sección siguiente, WINS opera en modo NetBIOS sobre TCP/IP.

Resolución de nombres broadcast

La resolución de nombres broadcast utiliza el modo de funcionamiento NetBIOS sobre TCP/IP definido en la especificación RFC 1001/1002 como b-node. Según este método, el equipo registra su nombre en la red "notificándolo" mediante la difusión de un mensaje generalizado a toda la red ("broadcast") en el nivel IP. Cada equipo situado en el segmento de broadcast es responsable de evitar cualquier intento de registro de nombres duplicados y de responder con su nombre registrado a los equipos que lo soliciten.

Resolución de nombres DNS

El sistema de nombres de dominio, DNS, representa una forma de buscar las asociaciones de nombres existentes al conectar un equipo a sistemas de otras subredes utilizando el modo NetBIOS sobre TCP/IP o aplicaciones como FTP (el software de SunLink Server no utiliza este método).

Un archivo LMHOSTS donde se especifican las asociaciones entre nombres NetBIOS y direcciones IP, o un archivo HOSTS para indicar el nombre de DNS y la dirección IP.

En los equipos locales, el archivo HOSTS (utilizado por las aplicaciones Windows Sockets para localizar nombres de sistemas TCP/IP) y el archivo LMHOSTS (utilizado por NetBIOS sobre TCP/IP para localizar los nombres de equipos de red de Microsoft) pueden emplearse para obtener la lista de las direcciones IP conocidas y sus nombres de equipos asociados. LMHOSTS se utiliza para la resolución de nombres en redes de pequeñas dimensiones o en subredes remotas donde no se encuentra disponible WINS.

Resolución de nombres NetBIOS sobre TCP/IP (NetBT)

NetBIOS sobre TCP/IP (NetBT) es un servicio de red del nivel de sesión que se encarga de asociar los nombres a direcciones IP. En el programa SunLink Server, NetBT se implementa a través de WINS y de la resolución de nombres broadcast. Los dos aspectos más importantes de las actividades relacionadas con la asignación de nombres son el registro y la resolución:

El registro es el proceso por el que se especifica un nombre exclusivo para un equipo (nodo) en la red. Generalmente cada equipo se registra a sí mismo al inicio.

La resolución es el proceso por el que se determina la dirección que corresponde a un nombre de equipo.

Nota -
Las normas RFC 1001 y 1002 determinan la forma en que debe implementarse NetBIOS sobre TCP/IP y definen los modos de resolución de nombres.

Dentro de NetBT se definen varios modos que determinan la forma en que se identifican los recursos de red y de qué manera debe accederse a ellos. Los modos de NetBT admitidos por el software de SunLink Server son:

b-node - Utiliza mensajes broadcast (de difusión) para resolver los nombres.

h-node - Utiliza primero otro tipo de nodo para la consulta de nombres y, a continuación, emplea b-node si el servicio de nombres no está disponible o si el nombre solicitado no está en la base de datos.

Nota -
Las especificaciones RFC hacen referencia al servidor de nombres de NetBIOS (NBNS). WINS es una implementación mejorada de NBNS.

Los dos tipos de nodos más comunes para los clientes Windows son b-node y h-node.

Para los usuarios de DHCP, el tipo de nodo puede asignarlo el servidor DHCP (en función de la configuración del cliente). Cuando hay instalados servidores WINS en la red, NetBT resuelve los nombres de los equipos cliente comunicándose con el servidor WINS. Si no hay servidores WINS, NetBT utiliza los mensajes broadcast del modo b-node para resolver los nombres. NetBT también puede utilizar archivos LMHOSTS para efectuar la resolución, según la forma en que se haya configurado TCP/IP en cada equipo.

El software de SunLink Server puede responder a los modos b-node y h-node de NetBT.

B-Node (nodo broadcast)

El modo b-node utiliza mensajes broadcast para registrar y resolver los nombres. Por ejemplo, si CLIENTE_PC1 quiere comunicarse con CLIENTE_PC2, emitirá un mensaje a todas las máquinas indicando que busca a CLIENTE_PC2 y esperará un tiempo especificado para que CLIENTE_PC2 responda.

El modo b-node tiene dos inconvenientes importantes:

En entornos de grandes dimensiones, carga la red de tráfico broadcast.

Normalmente, los enrutadores no reenvían los mensajes broadcast, por lo que los equipos que se encuentran al otro lado del enrutador, nunca reciben la petición.

H-Node (nodo híbrido)

El modo h-node resuelve la mayoría de los problemas asociados al envío de mensajes broadcast y a las transmisiones en entornos con enrutadores. Es una combinación del modo b-node y de otro tipo de nodo que utiliza los mensajes broadcast como último recurso. Si el servidor WINS no funciona (lo que crea la necesidad de enviar mensajes broadcast), el equipo sigue sondeando a dicho servidor hasta que vuelve a estar en servicio. El modo h-node también puede configurarse para utilizar el archivo LMHOSTS si falla la resolución de nombres broadcast.

No se generan mensajes broadcast si el servidor WINS está en ejecución y los equipos situados a distintos lados del enrutador pueden comunicarse. Si el servidor WINS no funciona, se utiliza b-node, lo que permite la comunicación normal entre equipos situados al mismo lado del enrutador.

Nota -

Para los usuarios TCP/IP de Microsoft que configuran este protocolo manualmente, el modo predeterminado es h-node, a menos que el usuario no especifique las direcciones de los servidores WINS al configurar TCP/IP.

Otras combinaciones

Existe otra variante, conocida como b-node modificado, que puede utilizarse en las redes SunLink Server para que los mensajes puedan atravesar los enrutadores. Este modo no utiliza servidores WINS, sino una lista de equipos y direcciones almacenados en un archivo LMHOSTS. Si falla un intento de comunicación mediante b-node, busca el nombre del equipo en LMHOSTS y utiliza la dirección asociada para atravesar el enrutador. El problema de este método es que cada equipo debe tener esta lista, cuyo mantenimiento y distribución crea una considerable carga administrativa.

Windows para trabajo en grupo 3.11 utiliza un sistema b-node modificado y Windows NT utiliza este método si no existen servidores WINS en la red. En Windows NT se han incorporado algunas ampliaciones a este archivo para facilitar su administración, pero el modo b-node sigue sin ser la mejor solución.

Resolución de nombres broadcast y WINS

WINS proporciona una base de datos distribuida para registrar y buscar asociaciones de nombres de equipo y direcciones IP de forma dinámica en entornos de red enrutados. Este sistema resuelve el problema que se genera al resolver nombres en entornos complejos de redes interconectadas.

WINS reduce el uso de las transmisiones broadcast locales para resolver nombres y permite a los usuarios localizar los sistemas con facilidad en redes remotas. Además, cuando DHCP genera nuevas direcciones IP para equipos que cambian de una subred a otra, los cambios se actualizan automáticamente en la base de datos WINS. Ni el usuario ni el administrador de la red necesitan introducir las modificaciones manualmente.

En las secciones siguientes se explica la forma en que se realiza la resolución de nombres mediante WINS y los mensajes broadcast.

WINS en entornos enrutados

WINS consta de dos componentes:

Servidor WINS, que maneja las peticiones de consulta y registro de nombres
El software cliente que solicita la resolución de nombres

Los clientes de redes Windows (equipos Windows NT, Windows 98, Windows 95 o Windows para trabajo en grupo 3.11 con software WINS) pueden utilizar WINS directamente. Los equipos de la red que no dispongan de servicios WINS y sean compatibles con el modo b-node (según lo descrito en las especificaciones RFC 1001 y 1002) pueden acceder a WINS a través de proxies (equipos WINS que escuchan las consultas broadcast de nombres y responden con los nombres que no pertenecen a la subred local).

Para posibilitar el examen de la red sin WINS, el administrador debe asegurarse de que el dominio principal de los usuarios dispone de equipos SunLink Server, Windows NT Server o Windows NT Workstation que actúen como examinadores principales a ambos lados del enrutador. Estos equipos tienen que contener archivos LMHOSTS correctamente configurados con entradas para los controladores de dominio de toda la subred.

Con WINS, esta operación no es necesaria porque los servidores y proxies WINS proporcionan de manera transparente el soporte necesario para examinar los distintos extremos del enrutador en dominios que así lo exigen.

Nota -

Si un cliente Windows NT está preparado para utilizar DHCP y el administrador especifica la información del servidor WINS como parte de las opciones de DHCP, el equipo se configura automáticamente con la información del servidor WINS.

En entornos de resolución de nombres broadcast y WINS, los clientes WINS se comportan de forma distinta a los clientes que no disponen de WINS. Las diferencias se hacen patentes en la forma en que manejan la resolución, registro, liberación y renovación de nombres, tal y como se describe en las secciones siguientes.

Resolución de nombres

Si hay instalados servidores WINS en la "interred", los nombres de equipos NetBIOS se resuelven utilizando dos métodos básicos según esté habilitada o no la resolución WINS en el equipo cliente. Independientemente de cuál sea el método de resolución utilizado, el proceso es transparente para el usuario una vez configurado el sistema.

Si WINS no está habilitado en el cliente - El equipo registra su nombre enviando paquetes de petición de registro (en forma de mensajes broadcast) a la subred local. Para localizar un determinado equipo, el equipo que no dispone de WINS envía paquetes de consulta de nombre (también como mensajes broadcast) a la subred local. Estos mensajes broadcast no pueden atravesar los enrutadores IP. Si la resolución de nombres local falla, consulta el archivo LMHOSTS local. Estos procesos se llevan a cabo tanto si el equipo es un servidor de red, como si es una estación de trabajo u otro dispositivo.

Si WINS está habilitado en el cliente - El equipo consulta primero al servidor WINS. Si esto no da resultado, envía peticiones de registro y consulta de nombres (como mensajes broadcast) siguiendo este procedimiento:
1. El cliente envía primero una petición de consulta de nombre al servidor WINS. Si éste localiza el nombre en su base de datos, el cliente puede establecer la sesión basándose en la asignación de dirección recibida del servidor WINS.
2. Si la consulta al servidor WINS no da resultado y el cliente está configurado como h-node, éste envía paquetes de consulta de nombre (como mensajes broadcast) de la misma manera que lo hace un equipo que no dispone de WINS.
3. Por último, si este otro método falla, consulta el archivo LMHOSTS local (en la búsqueda se incluye cualquier archivo LMHOSTS centralizado al que se haga referencia en las sentencias #INCLUDE de ese archivo local).

Los servidores WINS aceptan y responden a las consultas de nombres UDP (User Datagram Protocol). Cualquier asignación de nombre-dirección IP registrada en un servidor WINS puede suministrarse como respuesta válida a una consulta de nombre, si bien una asignación de esta base de datos no garantiza que el dispositivo asociado esté en funcionamiento, sólo que un equipo tiene asignada esta dirección IP y que, en ese momento, la asignación es válida.

Registro de nombres

El registro de nombres garantiza que el nombre de equipo NetBIOS y la dirección IP son exclusivos para cada equipo.

Si WINS está habilitado en el cliente - La petición de registro de nombre se envía directamente al servidor WINS para que lo agregue a la base de datos. Este servidor acepta o rechaza la petición de registro en función del contenido de su base de datos y de los criterios siguientes:
- Si la base de datos contiene otra dirección para ese nombre, WINS envía un mensaje a la entrada actual para determinar si ese dispositivo todavía reclama ese nombre.
- Si hay otro dispositivo que utiliza ese nombre, WINS rechaza la petición de registro del nuevo nombre.
- En otros casos, WINS acepta la entrada y la agrega a su base de datos local con una marca de hora, un número de versión exclusivo e incremental y otra información complementaria.

Si WINS no está habilitado en el cliente - Los equipos que no disponen de WINS envían un paquete broadcast de petición de registro de nombre a la red local especificando su nombre de equipo NetBIOS y su dirección IP. Cualquier otro dispositivo que haya reclamado ese nombre con anterioridad rechaza la petición enviando una respuesta negativa que da como resultado el fallo de ese intento de registrar un nombre duplicado. Si la petición de registro de nombre no recibe respuestas negativas durante un determinado tiempo, el equipo que ha enviado la petición adopta ese nombre y esa dirección.

Una vez que un equipo que no utiliza WINS ha reclamado un nombre, debe rechazar cualquier intento de registro de ese mismo nombre (enviando una respuesta de petición de registro negativa) y responder positivamente a cualquier consulta que solicite el nombre que tiene registrado (con una respuesta de petición de consulta de nombre positiva). La respuesta positiva contiene la dirección IP del equipo para que ambos sistemas puedan establecer una sesión.

Liberación de nombres

Cuando un equipo termina de utilizar un determinado nombre, deja de rechazar el registro de ese nombre por parte de otros equipos. Esto se conoce como liberar un nombre.

Si WINS está habilitado en el cliente - Cada vez que se apaga un equipo de forma normal, libera su nombre en el servidor WINS, con lo que la entrada correspondiente en la base de datos se marca como liberada. Si permanece liberada por un determinado periodo de tiempo, el servidor la marca como extinguida, actualiza el número de versión y notifica el cambio a los otros servidores WINS.
- Si un nombre está marcado como liberado en un servidor WINS y se recibe una nueva petición de registro con ese nombre pero otra dirección, el servidor puede asignar el nombre inmediatamente al nuevo cliente porque sabe que el cliente anterior ya no lo utiliza. Esto puede ocurrir, por ejemplo, cuando un equipo portátil que utiliza DHCP cambia de subred.
- Si el equipo ha liberado su nombre durante un apagado normal, el servidor WINS no rechaza el nombre cuando vuelve a conectarse. Si el apagado no se realiza de forma normal, el intento de registrar el nombre con una nueva dirección provoca que el servidor WINS rechace el registro. El rechazo no da resultado y el nombre queda registrado porque el equipo ya no tiene su antigua dirección.

Si WINS no está habilitado en el cliente - Cuando un equipo que no dispone de WINS libera un nombre, se envía un mensaje broadcast para que cualquier sistema de la red que tenga ese nombre en caché lo suprima. Si los equipos reciben paquetes de consulta del nombre suprimido, hacen caso omiso, lo que permite a otros equipos de la red adoptar el nombre liberado.

Nota -
Para poder acceder a equipos de otras subredes que no utilizan WINS, sus nombres deben agregarse como entradas estáticas a la base de datos WINS o a los archivos LMHOSTS de los sistemas remotos porque sólo responderán a peticiones originadas en su subred local.

Renovación de nombres

Los equipos clientes deben renovar de forma periódica sus nombres NetBIOS en el servidor WINS. Cuando un cliente se registra por primera vez en dicho servidor, éste le devuelve un mensaje donde indica cuándo debe renovar el registro, siguiendo estos criterios:

El intervalo predeterminado de renovación de entradas de la base de datos WINS es de seis días.
Los clientes WINS se registran y actualizan cada tres días.
Los servidores WINS principal y secundario deben tener los mismos intervalos de renovación.
Las entradas definidas como estáticas no vencen.

Si una entrada es propiedad del servidor WINS local, el nombre se libera en el momento especificado a menos que el cliente la haya renovado. Si la entrada pertenece a otro servidor WINS, se reconfirma en el momento especificado. Si la entrada no existe en la base de datos del servidor WINS propietario de la misma, se elimina de la base de datos WINS local. Las peticiones de renovación de nombre se tratan como un registro de nombre nuevo.

Precaución -

Un ajuste incorrecto del intervalo de renovación puede afectar negativamente al sistema y al rendimiento de la red.

Proxy de WINS

Un proxy de WINS es un equipo con servicios WINS mediante el cual pueden resolverse las consultas de nombre de equipos que no utilizan WINS en intranets TCP/IP enrutadas. Los equipos que no utilizan WINS se configuran de forma predeterminada con el modo b-node, que emplea mensajes broadcast IP para enviar las consultas de nombre. El proxy de WINS escucha la subred local para detectar mensajes broadcast IP de consulta de nombre.

Cuando un equipo que no utiliza WINS envía un mensaje broadcast de consulta de nombre, el proxy de WINS acepta el mensaje y busca en su memoria caché la asociación existente entre el nombre de equipo NetBIOS y la dirección IP. Si el proxy de WINS contiene esta asociación en su caché, envía la información al equipo que ha efectuado la petición. Si no localiza la asociación en su caché, la solicita a un servidor WINS.

Si no hay ningún servidor WINS disponible en la subred local, el proxy de WINS puede efectuar la petición a otro servidor a través del enrutador. Este proxy almacena en memoria caché las asociaciones entre nombres de equipo y direcciones IP recibidas del servidor WINS y las utiliza para posteriores consultas broadcast de nombre procedentes de equipos b-node dentro de la subred local.

Las asociaciones entre nombre y dirección IP que recibe el proxy de WINS se guardan en caché durante un tiempo limitado (el valor predeterminado es seis minutos y el mínimo permitido es un minuto).

Cuando el proxy de WINS recibe una respuesta del servidor WINS, la almacena en su caché y la utiliza para responder a posteriores consultas broadcast de nombre.

La función de un proxy de WINS es similar a la del agente relé DHCP/BOOTP, que reenvía las peticiones de clientes DHCP a través de los enrutadores. Dado que el servidor WINS no responde a los mensajes broadcast, es necesario instalar un equipo configurado como proxy de WINS en subredes con equipos que utilicen este tipo de mensajes para la resolución de nombres.

Nota -

Para configurar un equipo Windows NT, versión 4.0, como proxy de WINS, es preciso editar manualmente el Registro de ese equipo. La clave EnableProxy debe definirse con el valor 1 (REG_DWORD). Esta clave se almacena en: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netbt\ Parameters

WINS y clientes con acceso telefónico a redes TCP/IP

Los clientes con acceso telefónico a redes TCP/IP proporcionan conectividad a red para teletrabajadores, empleados que viajan con frecuencia y administradores de red que monitorizan y administran servidores en diversas sucursales. Los usuarios que acceden telefónicamente a redes TCP/IP desde equipos Windows 98, Windows 95 o Windows NT pueden usar las líneas telefónicas públicas para acceder a sus redes de forma remota y utilizar servicios como la impresión compartida, el correo electrónico, la programación de tareas o el acceso a bases de datos.

Windows 98, Windows 95 y Windows NT permiten enrutar el tráfico TCP/IP sobre conexiones TCP/IP telefónicas mediante diversos tipos de servidores de acceso TCP/IP incluidos los siguientes:

Servidores de sistema UNIX que soportan los estándares PPP (point-to-point protocol) o SLIP (serial line IP) para la conectividad TCP/IP mediante acceso telefónico.

Servidores de acceso remoto (RAS) Windows NT.

Servidores de acceso remoto de otros fabricantes que soportan conexiones PPP y/o SLIP, como los de CISCO, 3COM y Bay Networks.

Los equipos Windows 98, Windows 95 y Windows NT con acceso telefónico a redes configurados para enrutar el tráfico TCP/IP también pueden configurarse como servidores WINS (si precisa información al respecto, consulte la documentación de Microsoft).

Los equipos Windows 98, Windows 95 y Windows NT con acceso telefónico a redes configurados para enrutar el tráfico TCP/IP y utilizar WINS pueden acceder en remoto a sus servicios de red, incluidos los de archivos e impresoras compartidas, correo electrónico, programación de tareas y acceso a bases de datos.