Protocolo de configuración dinámica DHCP
De XTech Capacitacion
Una de las tareas mas tediosas del administrador de redes, es la de recorrer los puestos de trabajo para configurar numeros de IP. Ya sea por la llegada de un equipo nuevo, o por modificaciones en la estructura de la red.
Mucho más tediosa es la tarea cuando sabemos que es innecesaria porque existe (para nuestra alegría) DHCP.
Tabla de contenidos |
Introducción
El uso de IPs estáticas en redes bajo nuestra tutela conlleva siempre inconvenientes de mantenimiento, sin importar las dimensiones de la misma; puede tratarse de nuestra pequeña red doméstica, un cybercafé, oficina o una universidad. Los nuevos nodos que se agreguen a la red o los cambios vitales (como DNS, gateways, servidores WINS, etc.) nos obligan, cada tanto, a dejar nuestro cálido puesto junto a los servidores y recorrer los clientes para tipear.
Es posible que un administrador con poca experiencia, se las arregle con un cuaderno de IPs y claves a la que recurra cada vez que haya un problema por resolver.
Cuanto más grande es la red, más difícil es mantenerla de este modo. Gente con muchas ganas de mejorar las cosas (el grupo de trabajo de la Internet Engineering Task Force) decidió resolver el problema desarrollando un Protocolo para Configuración Dinámica de Terminales, conocido como DHCP.
Este protocolo, basado en otro llamado BOOTP, pero con mejores características. Está descripto en el RFC 2131 y en anteriores como el 1541 y el 1531, ya obsoletos por la publicación del primero.
Imaginando que los interesados en esta nota serán administradores de redes haciendo sus primeras armas, aconsejaré a los gentiles lectores que ignoren aquellos oscuros documentos y pasaré a resumir el funcionamiento del protocolo en pocas líneas.
Cuando un equipo, con un sistema operativo cualquiera que soporte TCP/IP se conecta a nuestra red, desconoce sus caracteristicas. Sólo conoce un número: la dirección de hardware (tambien conocida como MAC address) de su placa de red (también llamada NIC).
Ese número identifica inequívocamente a cualquier dispositivo de red. Y (en teoría) no puede cambiarse.
Esto de la MAC es válido para cualquier dispositivo, aunque en la gran mayoría de los casos, la capa física utilizada es Ethernet, asi que no ahondaremos mas en la cuestión.
Con aquel número en mente, la terminal lanza un grito de ayuda y es allí cuando nuestro buen servidor DHCP acude en respuesta, indicándole su nombre de host, dirección IP, tipo de red, servidor de nombres, WINS, ruta de salida, etc.
¿Qué necesitamos?
Hardware
- Una red TCP/IP ;)
- Un servidor DHCP (sobreentiendo que corriendo GNU/Linux).
- Clientes dispuestos a aceptar configuración automática. Si se les asigna configuración estática, simplemente ignorarán las ideas del servidor DHCP respecto a la red.
Software
- Del lado del servidor, uno de los tantos paquetes disponibles: dhcpd, dhcp3 de ISC, udhcpd, etc.
- Cabe destacar sobre este último paquete que el cliente y el servidor juntos apenas superan los 40K y esto se debe a que fueron pensados para funcionar en sistemas embebidos, donde la carencia de disco y memoria son un problema. Desde luego carecen de muchas funcionalidades de los otros paquetes, pero en determinadas condiciones son insustituibles como solución.
- Del lado del cliente, un paquete cliente como dhcpcd, pump o udhcpc. En el caso de clientes Windows, no hay nada que agregar.
- Luego también puede ser interesante agregar al servidor algunas herramientas de análisis como LanLord, chechDHCPd, dhcpStatus o reportDHCPd (Perl).
Para la configuración pueden utilizar alguna interfaz web o gráfica, como el módulo para administracion dhcp de Webmin, WebConf (PHP), dhcptool o WebDHCP.
De igual manera, para el lado del cliente hay herramientas gráficas, pero la simplicidad de los archivos de configuración es tal que les sugiero tomarse la molestia de editarlos.
Lo importante
Instalado el software del servidor, nuestra atención caerá sobre dos archivos importantes: /etc/dhcpd.conf, y /var/state/dhcp/dhcpd.leases.
El primero nos permitirá configurar el servidor a nuestro gusto, mientras que el segundo es una base de datos creada por el servidor, con las asignaciones de IP que se van realizando.
Este último archivo es importante, porque permite, en primer lugar, verificar la actividad del servidor y en segundo lugar, permite al servidor llevar cuenta de las IPs que va asignando a los distintos clientes, para conservarlas en caso de caídas.
La capacidad de asignar IPs dinámicamente a equipos desconocidos, junto con la de recuperar las IPs asignadas con anterioridad, sobre una base de tiempos de caducidad renovables, constituyen la ventaja más notable sobre el predecesor de DHCP, BOOTP.
Protocolo de intercambio de mensajes
Cuando el cliente DHCP arranca, resulta evidente que ignora la configuración de red por lo que necesita realizar las primeras comunicaciones mediante mensajes de difusión o broadcast. Esos que se envían al host 255 de la red.
Esta difusión y el resto de las comunicaciones se basa en 8 tipos de mensajes que el servidor y el cliente utilizan para realizar su trabajo.
- Nota: Estos mensajes no son puestos por el usuario o el administrador. Pertenecen a un "repertorio" entre programas.
| Mensaje | Lo envía el... | Tarea que realiza |
|---|---|---|
DHCPDISCOVER
| Cliente | Envía un mensaje de difusión para localizar a los servidores DHCP activos. |
DHCPOFFER
| Servidor | Responde con una oferta de parámetros de configuración conforme a la situación del cliente. |
DHCPREQUEST
| Cliente | Solicita los parámetros ofrecidos, en caso de que el mensaje del servidor haya sido aceptado, rechazando la oferta, si el mensaje del servidor ha sido desestimado o confirmando la solicitud de una dirección IP obtenida anteriormente. |
DHCPACK
| Servidor | Mensaje de confirmación y cierre, indicando los parámetros definitivos. |
DHCPNACK
| Servidor | Informe de que la dirección IP que solicita no es válida para la subred en la que se encuentra o ya no la puede asignar porque la tiene otro equipo. |
DHCPDECLINE
| Cliente | Informe de que la dirección está en uso, normalmente porque otro usuario ha asignado esa dirección manualmente. |
DHCPRELEASE
| Cliente | Informe de que ha finalizado el uso de la dirección IP. |
DHCPINFORM
| Cliente | Consulta sobre la configuración local. El cliente ya está configurado cuando envía este mensaje. |
Configuración del servidor DHCP
La configuración del servidor DHCP, como hemos visto anteriormente, se realiza en el archivo /etc/dhcpd.conf. Es un archivo de texto (como todos los archivos de configuración en Linux), donde cada línea que comience por # indica un comentario y no se tiene en cuenta.
Las distintas líneas de éste terminan en ;. Si una línea de configuración necesita distintos parámetros los podemos agrupar mediante { y }.
Veamos el siguiente ejemplo de cofiguración:
authoritative;
one-lease-per-client on;
server-identifier 192.168.1.1;
default-lease-time 604800;
max-lease-time 604800;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.1.255;
option routers 192.168.1.254;
option domain-name-servers 192.168.1.1;
option domain-name "centro.ies";
ddns-domainname "centro.ies";
ddns-update-style ad-hoc;
ddns-updates on;
option netbios-name-servers 192.168.1.1;
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.7 192.168.1.9;
range 192.168.1.90 192.168.1.150;
}
Ahora veámoslo detalladamente:
authoritative;
Supone que la configuración correcta para la red es la definida en el servidor DHCP y tratará de reasignar datos a los clientes mal configurados. Este parámetro puede ser global o asigando a una declaración de subred. Los cambios realizados en en servidor marcado de esta forma, tienen una rápida propagación en la subred ya que se reconfigura cualquier cliente con la antigua configuración.
not authoritative;
Tiene el significado opuesto al anterior parámetro.
one-lease-per-client on;
Cuando esta opción está en "on" y un cliente solicita una asignación, el servidor libera automáticamente cualquier otra asignación que tenga ese cliente. Se supone que si el cliente hace una solicitud es porque ha olvidado que tuviera alguna, es decir tiene un solo interfaz de red. Si no se da esta situación en los clientes hay que usar este parámetro con precaución.
server-identifier 192.168.1.1;
Este parámetro identifica el nodo que alberga el servicio DHCP. Sólo se deber usar cuando el nodo tenga más de una dirección IP asignada a la interfaz.
default-lease-time 604800;
indica el tiempo de asignación de la dirección, en segundos. La siguiente tabla nos puede servir para no tener que sacar cuentas:
- 600 - 10 minutos
- 7200 - 2 horas
- 86400 - 1 día
- 604800 - 1 semana
- 2592000 - 1 més
- 31104000 - 1 año
- 62208000 - 2 años
max-lease-time 604800;
indica el tiempo máximo de asignación de la dirección, en segundos.
ddns-updates on;
activa la actualización del DNS, con los valores asignados mediante DHCP.
ddns-domainname "centro.ies";
indica el dominio en el que se actualizan los DNS
ddns-update-style interim;
esta línea indica el método de actualización DNS automática con los valores de la IP asignados por DHCP. Más adelante veremos como hay que modificar las zonas en el archivo /etc/named.conf para permtir la actualización.
option subnet-mask 255.255.255.0;
definimos la máscara general de red que vamos a utilizar.
option broadcast-address 192.168.1.255;
definimos la dirección de difusión de la red.
option routers 192.168.1.254;
definimos el gateway de la red.
option domain-name-servers 192.168.1.1;
definimos la dirección del servidor DNS de la red.
option domain-name "centro.ies";
definimos el nombre del dominio DNS que se añade a los nombres de host.
option netbios-name-servers 192.168.1.1;
definimos la dirección del servidor WINS para NetBios.
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.7 192.168.1.9;
range 192.168.1.90 192.168.1.150;
}
y por último definimos la red en la que queremos hacer asignaciones y los rangos de direcciones que puede asignar el servidor.
Una vez vista la descripcíón preliminar de la configuración DHCP vamos a entrar en más detalles.
Podíamos haber definido una descripción de subred más simple si sólo tuviéramos un rango de asignaciones:
subnet 192.168.1.0 netmask 255.255.0.0 range 192.168.1.100 192.168.1.200;
Nota: En cualquier red serán necesarios distintos host con dirección IP fija, por ejemplo los servidores DNS o gateways. Habrá que tener cuidado con la asignación de estas direcciones y definir los rangos correctamente para no llevarnos sorpresas. También se pueden configurar equipos concretos mediante el parámetro host.
Vemos otras opciones disponibles
fixed-address lista_direcciones_ip;
define direcciones estáticas para asignar a un host.
group comienza una declaración de grupo.
hardware tipo_de_hardware dirección;
se utiliza para indicar el tipo de hardware, Ethernet o token ring. por ejemplo: hardware ethernet 0:50:b3:c5:60:05;
host comienza una declaración de host. Por ejemplo:
host cli004 {
hardware ethernet 00:50:b3:c5:60:23;
fixed-address 192.168.1.122;
}
fixed-address direccion-ip;
dirección fija para asignar a un host, como vemos en el ejemplo anterior.
host-name nombre;
nombre para asignar al host solicitado.
max-lease-time segundos;
Tiempo máximo de asignación de la IP. Esta parámetro lo podemos utilizar para evitar que los clientes tomen una dirección IP por tiempo indefinido.
netbios-name-servers lista_IP;
Lista de IP de servidores WINS.
range ip-menor ip-mayor;
el rango de diecciones que se asignarán en la correspondiente subred.
routers lista_IP;
Lista de IPs de gateways.
subnet comienza un declaración de subred.
subnet-mask máscara;
mascara de red
shared-network
define una declaración de subred compartida.
Alguna veces es necesario especificar opciones para cierto número de máquinas de la red sin tener que tratarlas como una subred separada. Por ejemplo, se puede definir una subred para un grupo de equipos y entonces aplicarle unas opciones específicas a esa subred. Esto significa que tendremos que especificarle todas las opciones de configuración necesarias.
Por ejemplo:
shared-network 192.168.2.253 {
subnet 192.168.2.0 netmask 255.255.255.0 {
option routers 192.168.2.253;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.2.255;
option domain-name-servers ns.centro.ies, ns2.centro.ies;
pool {
default-lease-time 400;
max-lease-time 400;
range 192.168.2.100 192.168.2.200;
ddns-domainname "centro.ies";
ddns-rev-domainname "in-addr.arpa";
}
}
}
shared-network 192.168.3.253 {
subnet 192.168.3.0 netmask 255.255.255.0 {
option routers 192.168.3.253;
option subnet-mask 255.255.255.0;
option broadcast-address 192.168.3.255;
option domain-name-servers ns1.centro.ies, ns2.centro.ies;
pool {
default-lease-time 400;
max-lease-time 400;
range 192.168.3.100 192.168.3.200;
ddns-domainname "centro.ies";
ddns-rev-domainname "in-addr.arpa";
}
}
}
Seguridad en la configuración DHCP
A continuación, es necesario convertir nuestro DHCP "abierto" en uno estático y más seguro. Esto lo haremos usando el archivo dhcp.lease que acabamos de crear (al asignar IPs por primera vez a todas las máquinas) y convirtiéndolo en lo que he llamado un dhcp estático.
¿Cuál es la diferencia entre un DHCP estático y uno abierto?
En lo que nos concierne, un DHCP abierto permite a cualquier computadora conectada a la red, obtener una dirección IP y el resto de parámetros de la red. Esto es un gran agujero en la seguridad, ya que cualquier atacante puede conectarse físicamente a la red y obtener parámetros de red correctos :(
Para contrarrestar tales ataques, usaremos el DHCP estático. Cada dirección IP sólo se da a clientes que tengan una MAC correspondiente a la placa ethernet asociada. De esta manera es fácil detectar una intrusión.
Por ejemplo:
host
hardware ethernet 00:40:95:49:0b:a5;
fixed-address "192.168.12.57";
host
hardware ethernet 00:50:04:45:e1:65;
fixed-address "192.168.12.67";
