Ostirala, 2024(e)ko abenduak 27
SERVICIO WINS PDF fitxategia Inprimatu E-posta
SOFTWARE - General
Asteazkena, 2006(e)ko azaroa(r)en 22-(e)an 10:52etan
There are no translations available.

En este artículo descubriremos como se realiza la resolución de nombres de equipo de Windows a la dirección de protocolo de red TCP/IP.

SERVICIO WINS

1.- Introducción

A los ordenadores se les asigna un nombre, ya a que a la gente le resulta más fácil referirse a los equipos por el nombre que se les haya asignado que por la dirección IP. Por ejemplo: si en el navegador se escribe http://www.cnice.mec.es o se hace un acceso directo a \\server\compartida se está utilizando nombres de máquina de alto nivel, esto se ha de resolver primero a una dirección de equipo que entienda el protocolo de red que se esta utilizando (TCP/IP, IPX/SPX, AppleTalk, etc.).

En esta artículo solo se acotará el problema a la resolución de nombres de equipo a la dirección de protocolo de red TCP/IP, en el caso de tráfico tipo unicast.

Vamos aclarando que existen 3 tipos de tráfico, que son los siguientes:

  • Broadcast: desde uno a todos los demás equipos
  • Multicast: desde uno a un grupo de equipos, no a todos, sino a los que se suscribieron a un determinado grupo de multicast
  • Unicast: desde un equipo a otro (1 a 1)

En una red de medio compartido como es Ethernet, aunque el tráfico esté dirigido a un equipo en particular, todos los que estén en el mismo medio “escuchan” la transmisión. Sólo el equipo destino toma la información, los demás la descartan al ver que no está dirigido a ellos.

Nombres NetBIOS y Hostnames

A todos los Windows cuando se les instala en red, se les ha de poner un nombre de equipo. Previo a Windows 2000 este nombre corresponde a lo que se conoce como nombre NetBIOS del equipo y es utilizado para la comunicación entre los mismos, aunque la longitud máxima es de 16 caracteres, el sistema permite usar sólo 15 porque el último es utilizado para funciones reservadas al sistema.

Cuando se tiene instalado TCP/IP, en las propiedades del mismo se puede ver que existe también un campo llamado Hostname. Es también un nombre de equipo y por omisión es igual al nombre NetBIOS, y conviene que así sea. Pero este Hostname podría ser diferente y tiene características sintácticas muy distintas: puede tener hasta 63 caracteres y sólo están permitidos letras, números y el signo menos (-); a diferencia del nombre NetBIOS que permite la utilización de algunos símbolos.

A partir de Windows 2000, el nombre que se coloca al equipo es el Hostname, no el nombre NetBIOS, este último es igual al Hostname y a diferencia de los casos anteriores no se puede hacer diferente. Windows 2000 sigue utilizando el nombre NetBIOS por compatibilidad con los anteriores sistemas operativos y aplicaciones basadas en NetBIOS.

¿En que casos se utiliza el nombre NetBIOS o el hostname de un equipo?, a continuación se explica:

NetBIOS: cuando se utiliza \\server para conectarse a otro equipo, server es el nombre NetBIOS.

Hostname: cuando se utilizan las herramientas de TCP/IP tales como ftp, ping, telnet seguido server, este es el nombre hostname. Ej: ping server

A la hora de resolver un nombre u otro se sigue un procedimiento diferente para cada uno. Para el nombre hostname es:

  • Archivo Hosts
    Es un archivo de texto, donde cada rengl ón corresponde a un registro e incluye la dirección IP seguida de por lo menos un espacio y el hostname del equipo, este es un archivo que existe en cada ordenador. Este archivo se encuentra en la siguiente ubicación: “C:WINDOWSsystem32driversetc”.
  • DNS (Domain Name Server)
    Un server con el servicio de DNS instalado y configurado. La construcci ón de la base con los registros puede ser hecha manualmente o en forma dinámica, de acuerdo a la versión utilizada. Windows 2000 utiliza protocolo DDNS (Dynamic DNS) y los clientes Windows 2000 se registran automáticamente. Windows NT 4.0 no soporta DNS dinámico, ni como cliente ni como servidor. La solución pasa por dos métodos: el primero consiste en dar manualmente de alta estos registros en el servidor DNS, la segunda es utilizar para estos clientes un DHCP server Windows 2000, y configurarlo para que cuando asigne direcciones IP, también haga la registración en el servidor DNS de las mismas
  • Hostname Cache
    A partir de Windows 2000, cuando resuelven un nombre a una direcci ón IP, esta información permanece almacenada en memoria durante un tiempo

Para el nombre NetBIOS es:

  • NetBIOS Name Cache
    Si en algún momento se resuelve una dirección, permanece durante un cierto tiempo el mapeo en memoria
  • Broadcast
    Se env ía información en la red dirigida a todos los equipos, que contiene algo así como “¿Qué dirección IP tiene el equipo que se llama Server?” Todos los equipos lo escuchan, pero contesta sólo el que se llama Server, informando su dirección IP.
  • WINS (Windows Internet Name Server)
    Un server con el servicio WINS instalado y los clientes configurados para usarlo. Para explicarlo en forma sencilla: cuando los clientes inicializan registran con el servidor WINS su nombre y su dirección IP. Con esta información el server construye una base de datos dinámica que incluye todos los clientes que se registraron. Luego cuando los clientes tienen que resolver una dirección IP le preguntan al servidor WINS, que si puede responde adecuadamente.
  • Archivo LMHOSTS
    Es un archivo de texto, donde cada renglón corresponde a un registro e incluye la dirección IP seguida de por lo menos un espacio y el Nombre NetBIOS correspondiente. Este archivo debe estar disponible y mantenerse individualmente en cada PC. Por defecto este archivo no esta creado, se tendrá que crear para lo cual hay un archivo de ejemplo llamado “lmhosts.sam” que nos servirá de guía. La ubicación de este archivo es la siguiente: “C:WINDOWSsystem32driversetc”.

Como se ha visto hasta ahora lo que en este artículo se pretende resolver son los nombres NetBIOS, por lo que se utilizará un Servidor WINS para resolver estos nombres.

2.- Descripción

En un segmento de una red se montará un Servidor WINS para responder a todas aquellas peticiones de los hosts de esta red, que anteriormente al querer asociar el nombre de una máquina con una dirección IP lanzaban un broadcast a toda la red para que el host con esa dirección IP le respondiera.

Ahora con el Servidor Wins funcionando, los hosts en vez de lanzar un broadcast a toda la red, lanzan una petición al Servidor, respondiéndoles éste con la dirección IP de la máquina en cuestión si la tiene en la base de datos que crea con el nombre y la dirección IP de todas las máquinas de esa subred.

Se montarán 2 máquinas con 2 tarjetas de red cada una, una de las tarjetas de cada máquina se utilizará para que ambas se comuniquen entre si por medio del servicio heartbeat para ver si la otra máquina sigue funcionando. La otra tarjeta de las máquinas son las IP´s públicas por las que se llega a las máquinas.

Para realizar esto se utilizarán las siguientes IP.

Servidor Wins

Eth 0: 192.168.1.1

Eth 1: 195.53.170.3

Cliente Wins

Eth 0: 192.168.1.2

Eth 1: 195.53.170.4

Servicio Wins

Eth 1 Virtual: 195.53.170.7

Comentario: No es necesario utilizar IP´s públicas, se pueden utilizar IP´s privadas, dependiendo de cómo sea el esquema de red en el que se monte el Servidor Wins.

3.- Servidor WINS

Para realizar este servicio, se montará una máquina Linux, a la cual se añadirá el servicio Samba, que es el que permite comunicar con máquinas de entorno Windows. Para que esta máquina funcione como Servidor Wins, se tendrán que añadir las siguientes líneas en el archivo de configuración denominado “smb.conf”. Las líneas a añadir son las siguientes:

[global]

wins support = yes

netbios name = Servidor Wins

name resolve order = wins lmhosts hosts bcast

A continuación se explicara lo que significan cada una de estas líneas.

Primera línea: es la que convierte a Samba en un servidor Wins.

Segunda línea: es el nombre que tiene la máquina.

Tercera línea: es el orden en el que se van a resolver los nombres netbios de las máquinas.

wins: utiliza el servidor wins

lmhosts: utiliza el fichero de control de red LMHOSTS

hosts: utiliza los métodos de resolución de nombres de un sistema Unix system, /etc/hosts, DNS, NIS, o una combinación (según esté configurado en dicho sistema).

bcast: utiliza un petición de broadcast.

Una vez realizados todos los cambios en el archivo de configuración, se tendrá que reiniciar el servicio Samba, para lo cual se ejecutará el siguiente comando:

/etc/init.d/samba restart

4.- Servidor de Backup de WINS

Es conveniente para mantener la funcionalidad del servicio tener un servidor de reserva, por si en el caso de que se caiga el servidor, entre otra máquina en funcionamiento. Para lo cual se realizarán 2 configuraciones independientes: el servicio heartbeat y el rsync.

  • Heartbeat: este servicio se utiliza para si se cae la máquina que actúa de servidor, la máquina que esta de reserva tomará la dirección IP que tenía el servidor. Hay que tener en cuenta que esta dirección es virtual, y va a actuar sobre el servicio que nosotros le digamos, en nuestro caso será sobre samba, que es donde se encuentra el servicio wins.
  • Rsync: es un servicio que se utiliza para realizar copias sincronizadas de directorios o de archivos, en este caso se utilizará para copiar las bases de datos del servicio wins de la máquina que actúa de servidor a la máquina que actúa de reserva. Y también se utilizara para cuando el servidor vuelva a ofrecer servicio, sincronice su base de datos de wins con la base de datos que tiene el Backup, ya que si se cae el Servidor entra en funcionamiento el Backup, y durante el tiempo que esta máquina esta ofreciendo servicio, la base de datos puede sufrir modificaciones.

A continuación se verá más detalladamente la configuración de los 2 servicios, tanto en la máquina que actúa de servidor, como en la máquina que actúa de backup.

Heartbeat

Es conocido como un servicio de “Alta Disponibilidad”, como el propio nombre indica se utiliza para que uno o más servicios se encuentren disponibles en todo momento, independientemente de sobre la máquina física que corran los servicios en ese instante. El servicio que interesa que este activo en todo momento es samba, ya que sobre éste corre el servicio wins. Tanto la máquina que actúa de servidor como la máquina de backup van a estar conectadas mediante un cable de red, también podrían estar conectadas mediante un cable serie, pero esta opción en principio no se va a utilizar.

Todo esto se ha montado sobre máquinas Linux con Mandriva 2005, a la hora de hacer la instalación del heartbeat se instalarán los siguientes paquetes:

  • heartbeat
  • heartbeat-pils
  • heartbeat-stonith

Antes de realizar la instalación hay que mirar donde busca las fuentes el urpm, si en los CD´s de instalación o en sitios web, o en los 2 sitios. Para que busque en los 2 sitios se ha de modificar el archivo /etc/urpmi/urpmi.cfg, lo cual se hará mediante las siguientes instrucciones con el usuario root:

urpmi.addmedia plf-free ftp://ftp.cica.es/mirrors/Linux/plf/mandrake/free/2006.0

urpmi.addmedia plf-nonfree ftp://ftp.cica.es/mirrors/Linux/plf/mandrake/nonfree/2006.0/

urpmi.addmedia contrib ftp://ftp.cica.es/pub/Linux/MandrakeLinux/official/2006.0/i586/media/contrib

urpmi.addmedia main ftp://ftp.cica.es/pub/Linux/MandraleLinux/official/2006.0/i586/media/contrib

Se instalarán mediante urpm que es similar al apt-get de Debian, así las sentencias serán similares a esta:

urpmi hearbeat-pils

Una vez instalado el servicio de heartbeat, lo siguiente que se hará será configurar el servicio, para lo cual se tendrán que configurar los siguientes archivos: ha.cf, haresources, authkeys.

Ha.cf: se configuran los nodos que pertenecen al cluster de máquinas que darán el servicio. El nombre de cada debe ser idéntico al que devuelve la ejecución de “uname –n”, también se configuran los enlaces usados para conectar ambas máquinas. A continuación se muestran las partes que se dejar sin comentar del fichero de configuración.

##Establece el tiempo en segundos que transcurre entre heartbeats

keepalive 2

##Establece el tiempo en segundos hasta que se da un host por muerto

deadtime 6

##Fichero de LOG

logfile /var/log/ha-log

##Si se prefiere usar el syslog, se debe configurar el /etc/syslog.conf y utilizar el nivel local0

logfacility local0

##Comprueba mediante el cable de red la otra máquina del cluster, hay que poner por que
##tarjeta se comunica y la dirección IP de la otra máquina

ucast eth1 195.53.170.4

##Los nombres de los nodos que forman el cluster devueltos con el comando uname -n

node servidor_wins

node backup_wins

##Si se quiere que las máquinas del cluster funcionen en modo activo-pasivo, es decir
##el servidor da servicio, y la otra máquina solo da servicio si el Servidor se cae. Una vez
##que el servidor vuelve a estar activo, le devuelve el control del servicio al Servidor.

auto_failback o­n

Este archivo de configuración tiene que ser idéntico en las 2 máquinas, a excepción de la dirección IP de la otra máquina a la que monitoriza, en el máquina de backup se pone la siguiente orden en el archivo ha.cf.

ucast eth1 195.53.170.3

haresources: en este fichero se configura la acción que se ejecutará al arrancar el heartbeat, ya sea cuando se arranca el servicio tanto en el servidor como en la máquina de backup. Heartbeat se encargará de mantener en ejecución los procesos que se configuren en este fichero.

servidor_wins 195.53.170.7 smb

La instrucción anterior dice que la máquina que actúa como servidor cuyo nombre es servidor_wins creará una dirección IP virtual que corresponde con la dirección 195.53.170.7 y que arrancará el demonio smb que pertenece al servicio de samba, el cual incluye el servicio wins.

authkeys: en este fichero se determina el método de encriptación o de comprobación de errores en la comunicación entre ambos directores. Este fichero debe ser igual en ambas máquinas (servidor y backup). Lo idóneo es que toda la comunicación vaya cifrada usando una clave que esta contenida en el contenido de este fichero. En este caso no hemos utilizado ninguna clave de encriptación, la comunicación se produce en texto sencillo, ya que la elegida es la opción 1, si se escoge la opción 2 o 3 se elige uno u otro método de encriptación.

auth 1

1 crc

#2 sha1 HI

#3 md5 Hello!

Esto significa que el método de autenticación que utiliza es la primera opción, que es en texto simple.

Una vez realizados estos cambios en los ficheros de configuración de heartbeat, ya se puede arrancar el servicio con el siguiente comando.

service heartbeat start

Rsync

Es una herramienta que se utiliza para realizar copias remotas sincronizadas de archivos o directorios de una máquina a otra. El rsync se ejecuta como un demonio, el cual se encuentra asociado a xinetd. Hay que asegurarse de que se encuentre abierto el puerto tcp 873.

Por defecto no viene instalado el rsync con el Mandriva 2005, por lo que tendremos que instalarlo, lo haremos al igual que el heartbeat con urpm.

urpmi rsync

A la hora de realizar la configuración, hay que tener en cuenta que va a ver una máquina que ejerza como servidor y la otra como cliente, por tanto se van a realizar configuraciones distintas en cada máquina. En este punto hay que puntualizar que se van a sincronizar el mismo directorio (/var/cache/samba) desde diferentes sentidos y para diferentes propósitos.

Caso 1

La máquina que actúa como Backup (cliente rsync) sincroniza el directorio “samba” con el mismo directorio de la máquina que actúa como Servidor Wins (servidor rsync). Este caso se utiliza para que cada cierto tiempo (15 minutos – tarea realizada mediante crontab) se sincronice el directorio “samba” del Servidor Wins con el mismo directorio del Backup Wins.

Caso 2

La máquina que actúa como Servidor (cliente rsync) realiza una copia cada 5 minutos de este directorio en una carpeta creada a la que se llamará “Backup”, para que posteriormente

La máquina que actúa como Servidor (cliente rsync) sincroniza su directorio “samba” con el mismo directorio de la máquina que actúa como Backup Wins (servidor rsync). Este caso se da cuando si se cae el Servidor Wins, el servicio pasa al Backup Wins, y una vez el Servidor Wins vuelve a estar activo, éste recupera el servicio y sincroniza con el directorio “samba” para ver si ha cambiado este fichero durante el tiempo en que el servicio ha dependido del Backup Wins.

Caso 1

Servidor: (Servidor Wins)

Hay que realizar cambios en 2 ficheros, que son:

/etc/xinetd.d/rsync

/etc/rsyncd.conf

A continuación se explicará por pasos, las modificaciones que hay que realizar en el servidor.

1º Paso

en /etc/xinetd.d/rsync

service rsync

{

disable = no

socket_type = stream

protocol = tcp

wait =no

user = root

server = /usr/bin/rsync

server_args = --daemon

log_on_failure += USERID

interface = 192.168.1.1

}

2º Paso

en /etc/rsyncd.conf

#Transferencias como usuario root

uid = root

#Identificador del grupo de trabajo del usuario

gid = root

#Hacer un chroot al directorio de los datos transferidos

use chroot = yes

#Permiso de acceso solo a los hosts con los que se sincroniza

hosts allow = 192.168.1.2

hosts deny = *

#Varios

max connections = 2

syslog facility = daemon

[wins]

path =/var/cache/samba

comment = Servidor de WINS Principal

3º Paso

service xinetd restart

Cliente: (Backup Wins)

En el cliente se lanzará un script cada cierto tiempo para que se produzca la sincronización y la copia remota. Para ello se la herramienta crontab, las copias se realizarán cada 15 minutos. La copia se realizará de la base de datos del Servidor Wins que el que contiene los nombres de las máquinas, la base de datos está guardada dentro del directorio de samba ubicado en /var/cache/samba.

Pare ello con crontab –e se editará los script que queremos que se ejecuten.

15,30,45 * * * * rsync –av --stats –delete --force –owner –group –perms –timeout=3600 192.168.1.1::wins /var/cache/samba

Con lo realizado anteriormente, el rsync ya estará funcionando como cliente y servidor.

Caso 2

Servidor: (Backup Wins)

Hay que realizar cambios en 2 ficheros, que son:

/etc/xinetd.d/rsync

/etc/rsyncd.conf

En el cliente se creará en el directorio raíz de la máquina, una carpeta a la que llamaremos backup, en la cual cada 5 minutos se guarda una copia de la base de datos Wins, tarea incluida en el cron. Para lo cual se realiza lo siguiente:

- Crear carpeta de copia

mkdir /backup

- Editar cron

crontab –e

- Copia cada 5 minutos de la base de datos Wins

5,10,15,20,25,30,35,40,45,50,55 * * * * cp –R /var/cache/samba/* /backup/

A continuación se explicará por pasos, las modificaciones que hay que realizar en el servidor.

1º Paso

en /etc/xinetd.d/rsync

service rsync

{

disable = no

socket_type = stream

protocol = tcp

wait =no

user = root

server = /usr/bin/rsync

server_args = --daemon

log_on_failure += USERID

interface = 192.168.1.2

}

2º Paso

en /etc/rsyncd.conf

#Transferencias como usuario root

uid = root

#Identificador del grupo de trabajo del usuario

gid = root

#Hacer un chroot al directorio de los datos transferidos

use chroot = yes

#Permiso de acceso solo a los hosts con los que se sincroniza

hosts allow = 192.168.1.1

hosts deny = *

#Varios

max connections = 2

syslog facility = daemon

[backup_wins]

path =/backup

comment = Copia de Seguridad de la Base de Datos Wins

3º Paso

service xinetd restart

Cliente: (Servidor Wins)

En el cliente se configura un script para que cuando esta máquina vuelva a estar activa realice una sincronización con la copia de seguridad de la base de datos Wins “/backup” para tener actualizada la lista de nombres de máquinas.

Se creará un script, para lo cual haremos lo siguiente.

-   Se crea el archivo

vi sincro.sh

- Se edita el contenido del fichero.

rsync –av –stats –delete –force –owner –group –perms –timeout=3600 192.168.1.2::backup_wins /var/cache/samba

-   Se le da al archivo permisos de ejecución

chmod 755 sincro.sh

Para ello en el archivo “rc.local” ubicado en “/etc” se mete la ubicación del script previamente creado, para lo cual haremos lo siguiente.

-   Se edita el fichero

vi rc.local

-   Se añade la siguiente línea

/usr/sbin/sincro.sh

5.- Clientes WINS

En aquellos clientes Windows que reciban dirección IP del servidor DHCP no hará falta configurar el cliente WINS, ya que también recibirán la dirección IP del Servidor Wins. Sin embargo en los clientes Windows que tengan una dirección IP fija, habrá que configurar manualmente la dirección IP del Servidor Wins, para ello se seguirán los siguientes pasos.

 

Revista INTEFP

Marcadores Sociales

Facebook MySpace Twitter Delicious Google Bookmarks 

Artículos relacionados