En este POST voy a explicar cómo montar un servicio de DHCP en modo Failover en una red local.

Aprovechando el montaje que ya hice de PowerDNS voy a usar DHCP para actualizar las zonas DNS de forma dinámica (DDNS).

Después de comprender el montaje que se hace aquí será sencillo, o debe serlo al menos, adaptar este montaje a las necesidades o limitaciones que tenga cada uno en la red donde vaya a ser montado.

 

1.ISC DHCP Server

1.1.Introducción

Antes de meterme con los detalles técnicos del montaje tengo que decir que si el servicio no está configurado correctamente, puede que funcione sin problemas en la asignación de IPS, pero el asunto de préstamos, retirada de préstamos y su inclusión en las zonas de actualización dinámica de los servidores DNS es otro cantar. Esto lo digo por propia experiencia. La primera, o primeras veces, que lo monté entregaba direcciones siempre, distinto era su comportamiento con la liberación de préstamos ni una actualización correcta de los registros del servidor DNS Bind. Y examinando los logs, aunque el servicio de DHCP y DDNS funcionaba, estaba repleto de warnings y errores que no llegaba a comprender.

1.2.Qué es ISC DHCP

Seguramente si estás aquí te suena Internet Systems Consortium y uno de sus 2 productos estrella, ISC DHCP Server.

Este tipo de servicio de DHCP tiene ya bastantes años, sus primeros pasos los daba en versiones Beta sobre finales de los 90 y principios del 2000.

Un servidor DHCP es una extensión del protocolo BOOTP, cuya primera versión fue introducida en 1993 en la RFC1531.

No voy a explicar en qué consiste un servicio de DHCP ni para qué sirve, eso deberías saberlo a estas alturas, lo que sí voy a decir es que el servidor de DHCP recibe las peticiones a través del Broadcast (255.255.255.255) y su respuesta es la IP que debe configurar el demandante y sugerirá una serie de opciones que el cliente será libre de establecer o no en sus parámetros de red. El método de préstamos es a cada “interfaz de red identificadas por su MAC” le corresponde 1, y solo 1, dirección IP.

Como el negociado que hacen el servidor de DHCP y su clientela se realiza por el Broadcast, es muy importante que, en el caso de que tengamos múltiples servidores DHCP, estén separados a Nivel 3 del modelo OSI, ya que de otra forma, la entrega de IP’s por los servidores DHCP estaría fuera de nuestro control y su comportamiento sería totalmente aleatorio.

El modo Failover del ISC DHCP Server es un tipo de funcionamiento en el que 2 servidores DHCP están repartiéndose la carga en la misma subred y si uno falla el otro puede hacerse cargo de la subred hasta que el primero vuelve a estar operativo de nuevo.

Uno de los inconvenientes que tiene el usar ISC DHCP Server en modo Failover es que si configuramos asignaciones estáticas, u otro tipo de asignaciones a pools basadas en otras reglas, para que se apliquen correctamente, estas deben estar igualmente configuradas en el otro servidor DHCP. Pongo un ejemplillo:

Teniendo 2 servidores DHCP en la red, si quiero que la MAC 00:11:22:33:44:55 tenga la IP 1.2.3.4, el fichero donde se configura debe estar en los 2 servidores. Si cambio una de las opciones que se entregan por petición DHCP, por ejemplo, la lista de servidores DNS, rutas estáticas, …, también debo cambiarla en los 2 servidores.

Habrá muchas opciones pero a mi poca imaginación solo se le ocurren unas cuantas:

• Usar un almacenamiento compartido, ya bien sea un dispositivo de bloques (iSCSI, CEPH, …), una carpeta compartida NFS, SAMBA, o lo que sea.

• Cuando se modifica en uno, transferir de forma automática los nuevos cambios y reiniciar servidores.

• Otra opción es manejarlos en base de datos, y cada vez que se actualice alguna o algunas de las filas de la tabla de préstamos, que un trigger me actualice los ficheros de préstamos en todos los servidores y reinicie los servicios.

• Usar el backend de LDAP que esté replicado.

Evidentemente me quedo con la última que es el próposito de esta entrada.

Antes de usar el backend de LDAP ya tuve una implementación basada en scripts BASH y hooks asociados a ficheros de configuración que filtraban y replicaban la configuración entre ambos servidores.

El haberlo hecho con un almacenamiento compartido no me venía bien. Primero porque si lo tengo en una carpeta compartida, si el servidor donde se aloja esa carpeta se cae, me quedaría sin ficheros de configuración, a no ser que replique el servicio, con lo cual más replicaciones, más configuraciones y en definitiva más trabajo. Y el segundo motivo es que, como me defiendo bastante bien en BASH y Systemd, no me cuesta ningún esfuerzo hacer que el proceso de actualizaciones sea eficaz con poco trabajo.

El usar una base de datos tipo SQL con ISC DHCP Server ver 4 requería de hooks sobre el servidor DHCP y mucha configuración por mi parte. Sería una versión más compleja que la que tenía implementada más el añadido de la base de datos.

1.3.Esquema de montaje

Para este documento, utilizaré parte de lo que ya tenemos hecho en la entrada anterior con unos sutiles cambios. Me veo obligado a hacerlos porque en el segmento 10.0.0.0/16 ya tengo 2 DHCPD en producción y máquinas que dependen de ellos, como linuxarena.net entre otras muchas.

Como la red donde trabajo está separada mediante VLAN’s, el cambio es a Nivel 2 del Modelo OSI y tendré que añadir una interfaz en una red en un segmento de red que tenga libre, en este caso el 172.26.0.0/16 que no me coincide con ningún otro.

La nueva zona de actualización dinámica será dyn.linuxarena.net, la zona de asignación estática lab.linuxarena.net y una última zona cajón desastre donde irán las máquinas a las que no tengo nada de aprecio que ya veré cómo la llamo.