Servicio de Directorio con LDAP [2]: NTP y dnsmasq

¡Hola Amigos!. Empezamos a implementar y configurar servicios. Por supuesto que es necesario que nuestro sencillo Servicio de Directorio basado en OpenLDAP, cuente con los servicios básicos para funcionar adecuadamente. Entre ellos tenemos a los servicios DNS o «Domain Name System«, DHCP o » Dynamic Host Configuration Protocol«, y al NTP o «Network Time Protocol«.

El sistema operativo base que usaremos es el Debian 6 «Squeeze». La mayoría de los métodos descritos pueden servir para el Ubuntu 12.04 «Precise», y en el Debian 7 «Wheezy».

Aunque parezca una nimiedad -de hecho hacen un poco largos nuestros artículos- las definiciones, y el estudio de ellas por parte de los lectores son necesarios. Puede y algunos ni las lean y vayan directamente «al pollo y al arroz con pollo». Craso error. Y no me refiero a los experimentados, pues éstos, nada más de ver el título saben si les interesa o no.

Nos referimos a los que empiezan en las lides de Redes Empresariales. A ellos les pedimos que lean las definiciones y que sigan los enlaces, que profundicen en las partes conceptuales que no necesariamente son líneas de comando o código, y que posteriormente sigan el resto del artículo.

Así nos ahorraremos mucho tiempo tanto ellos como nosotros, en hacer y responder a preguntas cuyas respuestas están precisamente en la parte de esas definiciones e introducciones. 🙂

También queremos dejar dicho de una vez, que el lenguaje de programación fundamental y más importante para un administrador de redes o para un informático, es el Idioma Inglés. :-). No siempre podemos dar traducciones, pues no somos expertos en la lengua inglesa.

Por supuesto que, antes de continuar, recomendamos encarecidamente lean la Introducción a ésta serie de artículos.

Definiciones necesarias

Tomadas de Wikipedia:

dnsmasq. Es un servidor ligero DNS, TFTP y DHCP. Su propósito es proveer servicios DNS y DHCP a una red de área local. Es una implementación libre del protocolo DNS que recibe peticiones de clientes solicitando una dirección IP a partir del nombre de una máquina. El servidor responderá a dichas peticiones proporcionando la IP.

DNS Domain Name System (o DNS, en español, sistema de nombre de dominio). Es un sistema de nomenclatura jerárquica para computadoras, servicios o cualquier recurso conectado al internet o a una red privada. Este sistema asocia información variada con nombres de dominios asignado a cada uno de los participantes. Su función más importante, es traducir (resolver) nombres inteligibles para los humanos en identificadores binarios asociados con los equipos conectados a la red, esto con el propósito de poder localizar y direccionar estos equipos mundialmente.

DHCP (sigla en inglés de Dynamic Host Configuration Protocol) es un protocolo de red que permite a los nodos de una red IP obtener sus parámetros de configuración automáticamente. Se trata de un protocolo de tipo cliente/servidor en el que generalmente un servidor posee una lista de direcciones IP dinámicas y las va asignando a los clientes conforme éstas van estando libres, sabiendo en todo momento quién ha estado en posesión de esa IP, cuánto tiempo la ha tenido y a quién se la ha asignado después.

NTP o Network Time Protocol, es un protocolo diseñado para sincronizar los relojes de las estaciones de trabajo a través de la red. La versión 3 de este protocolo es un Internet Draft Standard, formalizado en la RFC 1305. El protocolo NTP versión 4 es una importante revisión del estandard mencionado, y se encuentra en desarrollo, pero aún no ha sido formalizado en una RFC. Una versión simple de NTP (SNTP) versión 4 se describe en la RFC 2030

ISC-DHCP-SERVER (Internet Software Consortium DHCP Server). Un servidor DHCP es un servidor el cual es una implementación libre del protocolo DHCP que recibe peticiones de clientes solicitando una configuración de red IP. El servidor responderá a dichas peticiones proporcionando los parámetros que permitan a los clientes autoconfigurarse. Para que un PC solicite la configuración a un servidor, en la configuración de red de los PCs hay que seleccionar la opción obtener dirección IP automáticamente.

Kerberos es un sistema de autentificación de usuarios, que posee un doble objetivo:

  • Impedir que las claves sean enviadas a través de la red, con el consiguiente Riesgo de su divulgación.
  • Centralizar la autentificación de usuarios, manteniendo una única base de Datos de usuarios para toda la red.

Kerberos, como protocolo de seguridad, usa una Criptografía de claves simétricas, lo que significa que la clave utilizada para cifrar es la misma clave utilizada para descifrar o autenticar usuarios. Esto permite a dos computadores en una red insegura, demostrar su identidad mutuamente de manera segura. Kerberos entonces restringe los accesos sólo a usuarios autorizados y autentica los requerimientos a servicios, asumiendo un entorno distribuido abierto, en el cual usuarios ubicados en estaciones de trabajo acceden a estos servicios en Servidores distribuidos a través de una red.

¿Cuál implementación de los servicios DNS y DHCP desarrollaremos?

Desarrollaremos dos: la basada en dnsmasq, y en los siguientes artículos la correspondiente al Bind9 y el ISC-DHCP-Server. Para los que quieran aprender de forma detallada cómo se implementa y configura un DNS, recomendamos lean el artículo «Cómo instalar y configurar un DNS Maestro Primario para una LAN en Debian 6.0»

¿Por qué necesitamos los servicios DNS, DHCP y NTP?

  • DNS: Para mantener una base de datos con los nombres de los hosts y sus direcciones IP, de los equipos que estarán conectados a nuestra red empresarial, de forma que podamos llamarlos por sus nombres, en vez de por sus direcciones IP.
  • DHCP: Evitarnos el desplazamiento hasta el lugar donde se encuentra ubicado el equipo cliente, para configurar su dirección IP y parámetros relacionados. Mediante el DHCP configuramos automáticamente la dirección IP del cliente, su máscara de subred, la puerta de enlace, el servidor DNS a quien debe consultar, la dirección IP del servidor de correo de nuestra LAN, el tipo de nodo, el servidor de nombres NetBIOS y muchos otros parámetros más. Evidentemente, con éste servicio, podemos evitar errores de configuración manual de tan importante aspecto en los equipos clientes.
  • NTP: Si en futuro no lejano decidimos integrar Kerberos a nuestro servidor LDAP, necesitaremos de éste servicio. Kerberos depende fuertemente del protocolo NTP y de los servicios DNS.

¿Integraremos los servicios DNS y DHCP al servidor LDAP?

La respuesta por ahora es NO. Inicialmente NO. El tema OpenLDAP es un poco técnico de por si. Y si de entrada nos complicamos la vida con ese tipo de integración, no llegaremos muy lejos. Observen que el ClearOS, usa el dnsmasq. Zentyal por su parte utiliza el Bind9 y el DHCP Server sin integrarlos con el servidor LDAP.

Vayamos de lo sencillo a lo complejo para no meternos entre las patas de los caballos. 🙂

Red de ejemplo

Lan: 10.10.10.0/24
Dominio: amigos.cu
Servidor: mildap.amigos.cu
Sistema Operativo Servidor: Debian 6 "Squeeze
Dirección IP del servidor: 10.10.10.15
Cliente 1: debian7.amigos.cu
Cliente 2: raring.amigos.cu
Cliente 3: suse13.amigos.cu
Cliente 4: seven.amigos.cu

Servidor dnsmasq

Instalamos y configuramos:

:~# aptitude install dnsmasq
:~# mv /etc/dnsmasq.conf /etc/dnsmasq.conf.original

Editamos el archivo que ahora está vacío /etc/dnsmasq.conf y lo dejamos con el siguiente contenido:

:~# nano /etc/dnsmasq.conf
# Nunca pasar nombres planos sin el punto
# o la parte del dominio
domain-needed
domain=amigos.cu

# No pasar direcciones en el espacio de
# direcciones no enrutadas.
bogus-priv

# Consultar a los servidores de nombres en
# el orden en que aparecen en el archivo
# /etc/resolv.conf
strict-order

# Las respuestas a las consultas solo partirán de
# /etc/hosts o del DHCP.
local=/localnet/
# OJO CON LA INTERFACE
interface=eth1
expand-hosts

# Cambie el rango acorde a sus necesidades
# y también el tiempo de arrendamiento de
# la dirección IP
dhcp-range=10.10.10.150,10.10.10.200,12h

# Opciones para el RANGO
# Servidor de tiempo
dhcp-option=option:ntp-server,10.10.10.15

# La IP del servidor NTP es la misma que la de el dnsmasq
dhcp-option=42,0.0.0.0

# Las siguientes opciones son las que Samba recomienda para
# servidores ISC-DHCP-Server en su página
# http://www.samba.org/samba/ftp/docs/textdocs/DHCP-Server-Configuration.txt
# Están adaptadas para el caso en que el servidor Samba
# se ejecute en el mismo servidor dnsmasq.
# Puede descomentar algunas o todas ellas, si utiliza clientes
# Windows y el servidor Samba en su LAN.
#dhcp-option=19,0           # option ip-forwarding off
dhcp-option=44,0.0.0.0     # Servidor de nombres NetBIOS-sobre-TCP/IP. WINS
dhcp-option=45,0.0.0.0     # Servidor de distribución de Datagramas NetBIOS
dhcp-option=46,8           # Tipo de Nodo NetBIOS

Para conocer más sobre el dnsmasq, recomendamos lean detenidamente el archivo dnsmasq.conf, que nombramos cómo dnsmasq.conf.original. Es la Biblia en Pasta sobre éste servicio. Está en inglés.

Reiniciamos el servicio:

:~# service dnsmasq restart
Restarting DNS forwarder and DHCP server: dnsmasq.

Las direcciones IP fijas de servidores de nuestra LAN las declaramos en el archivo /etc/hosts del propio servidor donde se ejecuta el dnsmasq.

:~# nano /etc/hosts
27.0.0.1       localhost
10.10.10.15    mildap.amigos.cu    mildap
10.10.10.1      gandalf.amigos.cu gandalf
10.10.10.5      miwww.amigos.cu miwww

Cada vez que añadimos un nombre y una IP al archivo /etc/hosts , debemos forzar la recarga del servicio para que el host añadido sea reconocido por los comandos host, dig y nslookup, tanto en el propio servidor, como por el resto de las estaciones de trabajo que hayan adquirido una IP desde éste servidor:

:~# service dnsmasq force-reload

Nota: El archivo donde el dnsmasq almacena las direcciones IP otorgadas o «Leases», es el /var/lib/misc/dnsmasq.leases.

Servidor NTP

Fuente primaria consultada: «Configuración de servidores con GNU/Linux. Edición enero 2012. Autor: Joel Barrios Dueñas».

Instalamos y configuramos:

:~# aptitude install ntp
:~# cp /etc/ntp.conf /etc/ntp.conf.original
:~# cp /dev/null /etc/ntp.conf

Editamos el archivo que ahora está vacío /etc/ntp.conf y lo dejamos con el siguiente contenido:

# Se establece la política predeterminada para cualquier
# servidor de tiempo utilizado: se permite la sincronización
# de tiempo con las fuentes, pero sin permitir a la fuente
# consultar (noquery), ni modificar el servicio en el
# sistema (nomodify) y declinando proveer mensajes de
# registro (notrap).
restrict default nomodify notrap noquery

# Permitir todo el acceso a la interfaz de retorno del
# sistema.
restrict 127.0.0.1

# Se le permite a la red local sincronizar con el servidor
# pero sin permitirles modificar la configuración del
# sistema, y sin usar a éstos como iguales para sincronizar.
restrict 10.10.10.0 mask 255.255.255.0 nomodify notrap

# Reloj local indisciplinado.
# Este es un controlador emulado que se utiliza solo como
# respaldo cuando ninguna de las fuentes reales están
# disponibles.
fudge 127.127.1.0 stratum 10
server 127.127.1.0

# Archivo de variaciones.
driftfile /var/lib/ntp/drift
broadcastdelay 0.008

## SI TIENE ACCESO A INTERNET
# Lista de servidores de tiempo de estrato 1 o 2.
# Se recomienda tener listados al menos 3 servidores.
# Mas servidores en:
# http://kopernix.com/?q=ntp
# http://www.eecis.udel.edu/~mills/ntp/servers.html
## Si tiene acceso a Internet, elimine el comentario de las siguientes 3 líneas
#server 0.pool.ntp.org
#server 1.pool.ntp.org
#server 2.pool.ntp.org

# Permisos que se asignarán para cada servidor de tiempo.
# En los ejemplos, no se permite a las fuente consultar, ni
# modificar el servicio en el sistema ni enviar mensaje de
# registro.
## Si tiene acceso a Internet, elimine el comentario de las siguientes 3 líneas
#restrict 0.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
#restrict 1.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery
#restrict 2.pool.ntp.org mask 255.255.255.255 nomodify notrap noquery

# Se Activa la difusión hacia los clientes
broadcastclient

Reiniciamos el servicio NTP:

:~# service ntp restart
Stopping NTP server: ntpd.
Starting NTP server: ntpd.

Cliente NTP

:~# aptitude install ntp
:~# cp /etc/ntp.conf /etc/ntp.conf.original
:~# cp /dev/null /etc/ntp.conf

Editamos el archivo que ahora está vacío /etc/ntp.conf y lo dejamos con el siguiente contenido:

server mildap.amigos.cu

Comprobaciones en el Cliente

Por ejemplo, tomemos a nuestro cliente debian7.amigos.cu, al cual previamente le hemos instalado el paquete openssh-server.

root@debian7:~# ssh debian7
root@debian7's password:
[----]
root@debian7:~# ifconfig
eth0      Link encap:Ethernet  HWaddr 52:54:00:8f:ee:f6  
          inet addr:10.10.10.153  Bcast:10.10.10.255  Mask:255.255.255.0
          inet6 addr: fe80::5054:ff:fe8f:eef6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:4967 errors:0 dropped:0 overruns:0 frame:0
          TX packets:906 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:6705409 (6.3 MiB)  TX bytes:93635 (91.4 KiB)
          Interrupt:10 Base address:0x6000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:8 errors:0 dropped:0 overruns:0 frame:0
          TX packets:8 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:480 (480.0 B)  TX bytes:480 (480.0 B)

Ya comprobamos que adquirió una dirección IP desde el dnsmasq instalado en nuestro servidor OpenLDAP. Por tanto, ese servicio funciona correctamente. Ahora comprobemos el servicio NTP, lo cual puede demorar varios segundos:

:~# ntpdate -u mildap.amigos.cu
25 Jan 20:07:00 ntpdate[4608]: step time server 10.10.10.15 offset -0.633909 sec

Con respecto al servicio NTP, todo funciona OK.

Otras comprobaciones:

root@debian7:~# dig gandalf.amigos.cu

; <<>> DiG 9.8.4-rpz2+rl005.12-P1 <<>> gandalf.amigos.cu
[----]
;; QUESTION SECTION:
;gandalf.amigos.cu.        IN    A
[----]
;; ANSWER SECTION:
gandalf.amigos.cu.    0    IN    A    10.10.10.1
[----]
root@debian7:~# dig gandalf
[----]
;; QUESTION SECTION:
;gandalf.            IN    A
[----]
;; ANSWER SECTION:
gandalf.        0    IN    A    10.10.10.1
[----]

root@debian7:~# dig miwww
[----]
;; QUESTION SECTION:
;miwww.                IN    A
[----]
;; ANSWER SECTION:
miwww.            0    IN    A    10.10.10.5
[----]
root@debian7:~# dig debian7
[----]
;; QUESTION SECTION:
;debian7.            IN    A
[----]
;; ANSWER SECTION:
debian7.        0    IN    A    10.10.10.153
[----]

root@debian7:~# host mildap
mildap.amigos.cu has address 10.10.10.15
Host mildap.amigos.cu not found: 5(REFUSED)
Host mildap.amigos.cu not found: 5(REFUSED)

root@debian7:~# host mildap.amigos.cu
mildap.amigos.cu has address 10.10.10.15
Host mildap.amigos.cu.amigos.cu not found: 5(REFUSED)
Host mildap.amigos.cu.amigos.cu not found: 5(REFUSED)

Y como los dos servicios instalados y configurados funcionan muy bien, cerramos las comunicaciones por el día de hoy hasta la próxima entrega del artículo sobre cómo implementar los servicios DNS y DHCP actualizando al DNS, basados en el Bind9 y el ISC-DHCP-Server, para aquellos que administren redes un poco más grandes y complicadas.

Hasta la próxima, amigos !!!


Deja tu comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.

  1.   Fega dijo

    lo guardo a PDF para leerlo mejor después :/ es bastante largo

  2.   Huesos dijo

    no se porque leyendo «dnsmasq» pense que decía «dnscrypt» , lo había descubierto leyendo perseo’s blog y lo implemente por si acaso
    Saludos

  3.   firecold dijo

    Gracias Amigo, siempre e dicho que sus post son muy educativos y muy interesantes, aprecio mucho su colaboración, hablando de compartir el conocimiento, por lo demas muchas gracias, Saludos

    1.    federico dijo

      @firecold, Muchas Gracias por tus palabras de consideración a lo que escribo. Me impulsan a continuar.

      Gracias a TODOS por comentar

  4.   dhunter dijo

    Con esta serie de artículos voy a ponerme los pantaloncitos a ver si salgo del 389 del trabajo que ya da más dolores de cabeza que una resaca.

    Saludos, Fico!

    1.    federico dijo

      Hola amigo @dhunter !!!. Imagina que el 389 Directory Server (utiliza Kerberos) y Samba, junto con DHCP y DNS, ofrecer a los clientes Windows de una red, prácticamente la funcionalidad que obtendrían con un controlador de dominio Windows 2003. Es como partir de lo muy complejo para implementar una solución en una red para la pequeña y mediana empresa. Y eso es a lo que prácticamente, la mayoría de los Adminstradores están acostumbrados.

      Trato y trataré en los artículos de caminar de lo sencillo a lo complejo para que la gente se percate de que, en una red de computadoras, no es necesario ni imprescindible la filosofía de las redes Microsoft. De hecho, la Aldea WWW no la usa en lo absoluto.

      Sigue los artículos y verás. Saludos

  5.   vidagnu dijo

    Hola, una consulta, el cliente y servidor ntp los podes correr en un solo servidor, es decir que el servidor ntp se sincronize con los servidores de internet, y que a la vez este utilice el cliente para actualizar la hora del mismo servidor?

    Veo que aqui tenes un archivo ntp.conf para el cliente y otro para el server, como hago para que todo se ejecute en el mismo equipo??

    Saludos

    1.    federico dijo

      @vidagnu: Si lees nuevamente y despacio te darás cuenta de que el Servidor NTP, también se puede sincronizar con otros servidores NTP de Internet.

      En una red empresarial o privada, lo lógico es que los clientes sincronicen el reloj con el servidor NTP de esa red, no con los de Internet.

      De esa forma se disminuye el tráfico y se trabaja en la LAN con el Tiempo que el servidor local NTP sincronizó con los servidores de Internet.

      Parece un trabalenguas pero es así. Se trata de establecer una sincronización en cascada. O sea, el Servidor NTP de la LAN sincroniza su reloj con los Servidores NTP de Internet, y los clientes de la LAN lo hacen con su servidor local.

  6.   Raiden dijo

    Buenas noches, he leído algunas de tus publicaciones y me parecen excelentes, pero en esta tengo una pequeña duda, en que momento le doy direccionamiento por DHCP al equipo debian7, creo por lo que entendí la asignación de IP por DHCP al equipo se la da el servidor mildap, si es así no he conseguido hacerlo, disculpa por las molestias causadas, saludos.