Configuración de un servidor DHCP en debian

Concesión de una dirección ip

El protocolo se inicia cuando un cliente que requiere una configuración de red pide una dirección ip mediante el envío de un paquete DHCPDISCOVER. Al no tener configurada aún el cliente su interfaz, usa como dirección de origen la 0.0.0.0 y como dirección de destino la de broadcast universal 255.255.255.255.

Este paquete llegará a todas las máquinas de la red y, si alguna es un servidor dhcp responderá enviando un paquete DHCPOFFER en el que le propone al cliente una dirección ip libre. Este paquete usa como dirección de origen la ip del servidor y como dirección de destino la ip ofrecida, aunque antiguamente se usaba la dirección de broadcast universal.

Si el cliente acepta está ip, envía entonces una petición formal al servidor dhcp mediante un paquete DHCPREQUEST en el que incluye una lista de parámetros de red que le gustaría que el servidor le proporcionara, Esta lista de parámetros es una lista de números enteros, ya que cada parámetro de red está representado por un número. Estos parámetros se refieren a la máscara de red, la dirección ip de la puerta de enlace, las direcciones ip de los servidores DNS, etc. Este paquete tiene las mismas direcciones de origen y destino que el DHCPDISCOVER, puesto que el cliente sigue sin tener una configuración de red.

Recibido el paquete de petición por el servidor, este responde con un paquete DHCPACK donde se incluyen todos los parámetros que requiere el cliente y además se le informa de cuál es el periodo de vigencia de la concesión. Las direcciones de origen y destino son las mismas que para el paquete DHCPOFFER. Cuando este paquete es recibido por el cliente, este es capaz de configurar por fin sus parámetros y podrá participar normalmente de la comunicación en red.

Renovación de una dirección ip

Cuando la concesión de una ip está próxima a expirar, el cliente puede enviar un paquete DHCPREQUEST en que pide al servidor que le prorrogue la concesión de la ip. Este paquete tiene las mismas direcciones de origen y destino que el DHCPREQUEST que se explicó bajo el epígrafe anterior.

Si el servidor accede, entonces devolverá un paquete DHCPACK con la configuración de red y el cliente disfrutará de la ip durante otro periodo de tiempo.

Anulación de la concesión

Si el cliente desea deshacer la concesión antes de que expire el plazo (por ejemplo, porque va a apagarse y no desea seguir ocupando la dirección), puede entonces enviar al servidor un paquete DHCPRELEASE que utiliza como dirección de origen la ip del cliente y como dirección de destino la del servidor. Al recibir este paquete el servidor dará por finalizada la concesión y liberará la ip para que pueda ser entregada de nuevo.

Si el cliente no envía este aviso, el servidor esperará a que el plazo expire para liberar la ip. Es más, si posteriormente el mismo cliente, por cualquier razón, inicia la petición de una nueva ip con un paquete DHCPREQUEST (ver apartado siguiente) en que sugiere una ip distinta y esta está libre, el servidor se la concederá sin liberar la ip anterior. cuyo plazo puede aún no haberse cumplido. Para que esta circunstancia no se produzca y un mismo cliente siempre consuma sólo una ip es necesario fijar en el servidor del ISC la directiva:

one-lease-per-client on;

Otros casos

Los tres casos anteriores son los más habituales. Sin embargo, pueden darse otros. Uno muy común se produce cuando el cliente, sin la concesión previa de una determinada ip, envía directamente al servidor un paquete DHCPREQUEST en que sugiere que se le conceda tal ip.

Si la ip está libre, el servidor aceptará la sugerencia del cliente y enviará un paquete DHCPACK. Sin embargo, si esa ip no está libre, no podrá concederla y le enviará un paquete DHCPNACK con el que le notifica la denegación. Este paquete tiene como ip de origen el servidor y como ip de destino la de broadcast universal 255.255.255.255.

Ante la denegación, el cliente comenzará el protocolo de pedir una nueva ip mediante un paquete DHCPDISCOVER.

dnsmasq como servidor dns

Consulte cómo se hace en los apuntes sobre dns.

dnsmasq como servidor dhcp

POR ESCRIBIR: interfaces de servicio, rango de ips, ips estáticas, opciones más habituales, otras opciones con RFC 2132.

Instalación

Basta con instalar el paquete isc-dhcp-server:

# aptitude install isc-dhcp-server

Configuración del servidor

Toda la configuración se hace tocando el fichero /etc/dhcp/dhcpd.conf. Por supuesto, siempre después de cambiar la configuración hay que reiniciar el servidor:

# /etc/init.d/isc-dhcp-server restart

pool { # Maquinas conocidas con ip dinamica
   allow known-clients;
   range 192.168.1.255.64 192.168.1.255.95;
}

pool { # Maquinas desconocidas
   deny known-clients;
   range 192.168.1.255.96 192.168.1.255.159;
}

match if substring(hardware,1,3) = 00:AB:22;

match if binary-to-ascii(16,8,":",substring(hardware,1,3)) = "0:ab:22";

class "abigarrada" {
   match if ( substring(hardware,1,3) = 00:AB:22 or
              substring(hardware,1,3) = 00:AB:23 or
              substring(hardware,1,3) = 00:AB:24
            );
   #Opciones particulares para esta clase, si se considera oportuno...
}

class "abigarrada" {
   match substring(hardware,1,3);
}
subclass "abigarrada" 00:AB:22;
subclass "abigarrada" 00:AB:23;
subclass "abigarrada" 00:AB:24; 

subclass "abigarrada" 00:AB:23 {
   lease limit 4;
}

log-facility local7;

# echo "local7.*    -/var/log/dhcpd.log" > /etc/rsyslog.d/dhcp.conf

*.*;auth,authpriv.none,local7.none          -/var/log/syslog

# invoke-rc.d isc-dhcp-server restart
# invoke-rc.d rsyslog restart

class "especialitos" {
   match if substring(hardware,1,3) = 00:11:22;
   log(info,concat("El ordenador con MAC ",binary-to-ascii(16,8,":",substring(hardware,1,6))," es de la clase especialitos"));
}

class "manipuladas" {
   match if option user-class = "Maquinas Clientes";
}

Configuración del servidor DHCP

Se basa en crear una clase a la que pertenezcan los dispostivos móviles. las condiciones de pertenencia, dado que el mercado de estos dispositiovs es bastante dinámico, conviene revisarlas de vez en cuando:

class "smartphones" {
   match if not known and (
      # ANDROID
#     substring(option host-name,0,8)  = "android-" or
      substring(option vendor-class-identifier,0,7) = "dhcpcd-" or
      # BLACKBERRY
#      substring(option host-name,0,11) = "BLACKBERRY-" or
      binary-to-ascii(10, 8, ",", option dhcp-parameter-request-list)= "56,6,1,3,15" or
      # IPHONE
      binary-to-ascii(10, 8, ",", substring(option dhcp-parameter-request-list,0,6))= "1,3,6,15,119,252" or
      binary-to-ascii(10, 8, ",", option dhcp-parameter-request-list)= "1,3,6,15,119,78,79,95,252" or
      # NOKIA
      binary-to-ascii(10, 8, ",", option dhcp-parameter-request-list)= "1,28,2,121,3,15,6,12" or
      binary-to-ascii(10, 8, ",", option dhcp-parameter-request-list)= "1,3,6,28" or
      binary-to-ascii(10, 8, ",", option dhcp-parameter-request-list)= "1,3,6,12,15,17,28,40,41,42"
   );

   ignore booting;
   execute("ipset", "-exist", "add", "bannedmacs", binary-to-ascii (16, 8, ":", substring(hardware, 1, 6)));
}

La declaración de la clase está compuesta por tres instrucciones:

1. La primera define cuáles son los criterios para considerar un dispositivo de la clase smartphones. Obsérvese que el primero de ellos es que el dispositivo no sea conocido. Esto abre la posibilidad de crear una lista blanca, si queremos que algunos smartphones no sufran restricciones.
2. La segunda niega ip a estos dispositivos. Obviamente esta segunda línea debe existir sólo si nuestro propósito es de veto, si pretendemos penalizar no debe aparecer: lo veremos más adelante.
3. La tercera línea sirve para ejecutar un comando externo en el momento en que un cliente smartphones pide (infructosamente) una dirección. Este comando, puesto de forma más legible es este:

   # ipset -exist add bannedmacs IP:DEL:CL:IEN:TE

   El comando apunta en un conjunto llamado bannedmacs la MAC del cliente indeseable. Obviamente este conjunto debe existir previamente, así que deberíamos haber ejecutado con anterioridad una orden parecida a esta:

   # ipset create bannedmacs hash:mac timeout $((30*60))

   que crea un conjunto hash:mac cuyos registros tienen una dureción de media hora. De este modo, de todo dispositivo móvil que intente obtener una dirección ip, quedará registrada la MAC durante media hora (o lo que más nos convenga).

Filtrado

Si nuestro propósito es filtrar sin más los dispositivos, podríamos estar tentados de pensar que con lo hecho bajo el epígrafe anterior ya está resuelto el reto y que, incluso la directiva execute, sobra. Pero no es así, puesto que negar una dirección ip, no veta al dispositivo, y, de hecho, si algún usuario inquieto decide fijar una dirección ip a mano, comprobará que puede acceder a la red sin problemas. Esa es la razón por la que se registran las direcciones mac de estos dispositivos. Con ellas podemos denegar el acceso escribiendo un par de reglas de iptables:

# iptables -A FORWARD -i eth1 -m set --match-set bannedmacs src -j DROP
# iptables -A INPUT -i eth1 -m set --match-set bannedmacs src -j DROP

Penalización

La penalización es bastante más complicada que el simple filtrado, ya que exige crear un control del tráfico en la interfaz de salida hacia internet. Por lo pronto, es necesario eliminar la segunda de las directivas (ignore booting;) para que los dispositivos puedan obtener una ip. Además, es conveniente sustituirla por otra que limite el número de dispositivos a los que se les concede una ip, para que nunca ocupen todas las disponibles:

lease limit 25;

Por ejemplo, 25. Limitar el número de ips concedidas de esta forma es la configuración óptima. Sin embargo, en las últimas versiones del servidor dhcp, hay un bug que inutiliza esta directiva, de modo que cuando se alcanza el límite, el servidor se cae. Mientras este bug no se soluciona, la única alternativa es no incluir la directiva y asociar la clase con un rango limitado de direcciones ip (véase la directiva pool). Esta remiendo temporal tiene el inconveniente de que cuando se agota el rango asignado, la directiva execute deja de ejecutarse y, como consecuencia, dejan de registrarse las mac.

La directiva execute conviene también revisarla. Como en este caso se concede ip, si el tiempo de concesión es mayor que el tiempo de permanencia de la MAC en el conjunto (timeout), resultará que pasado un tiempo de conexión (el timeout) y hasta que se renuevela concesión los smartphones no se verán penalizados. Podríamos asegurarnos de que el timeout es mayor, pero existe otra solución más elegante: prescindir del timeout en el conjunto, lo que hará permanentes las MAC, y añadirlas o eliminarlas según los clientes reciban ip o la revoquen o les caduque la concesión:

on commit {
   execute("ipset", "-exist", "add", "bannedmacs", binary-to-ascii (16, 8, ":", substring(hardware, 1, 6)));
}
on release {
   execute("ipset", "-exist", "del", "bannedmacs", binary-to-ascii (16, 8, ":", substring(hardware, 1, 6)));
}
on expiry {
   execute("ipset", "-exist", "del", "bannedmacs", binary-to-ascii (16, 8, ":", substring(hardware, 1, 6)));
}

Recuérdese que es importante que en este caso se cree el conjunto sin tiempo de caducidad:

# ipset create bannedmacs hash:mac

Resuelto el problema de registrar cuáles son los smartphones que detecta el servidor DHCP, toca preocuparse de penalizarlos, y esto segundo depende de si las conexiones atraviesan directamente el servidor o si por el contrario lo hacen a través de un servidor proxy como squid. Incluso puede darse el caso de que parte del tráfico circule directamente y parte (el tráfico web) a través del proxy:

Obsérvese en el esquema que, a la salida del tráfico por eth0, se conoce la procedencia del tráfico que no pasa por squid. En cambio, el tráfico web procede todo de squid, sea o no penalizado. La estrategia consiste en asignar dos direcciones a la interfaz de salida eth0: con la principal (172.22.0.2) se enmascarará el tráfico no penalizado, mientras que con la dirección secundaria (172.22.255.2) se enmascarará el tráfico penalizado. Hecho esto, se puede crear un control de tráfico con tc a la salida de eth0 que provoque la penalización.

Lograr enmascarar con una u otra dirección el tráfico que no gestiona squid es relativamente sencillo:

# ip addr add 172.22.255.2/16 dev eth0
# iptables -t nat -I POSTROUTING -o eth0 -m set --match-set bannedmacs src -j SNAT --to-source 172.22.255.2

En cambio, la penalización del tráfico gestionado por squid no se resuelve con la anterior regla de iptables, puesto que el origen de ese tráfico es el propio servidor (squid) y no los clientes que originan las peticiones. En este caso, debemos lograr que squid identifique las peticiones que proceden de los smartphones. Sin embargo, no podemos usar el módulo set dentro de él, así que la estrategia pasa por reservar una ip de la red a la que pertenecen la wifi y, antes de que los paquetes lleguen a squid, fingir que proceden de ella. Por ejemplo, si la red wifi es la 192.168.255.0/24, podemos hacer que la dirección 192.168.255.254 nunca sea asignada por el servidor dhcp a ningún cliente y usarla para nuestro propósito:

# iptables -t nat -A INPUT -p tcp --dport 8080 -m set --match-set bannedmacs src -j SNAT --to-source 192.168.255.254

Hemos supuesto que squid escucha por el puerto 8080.

Por último, en squid podemos hacer que el tráfico que procede de esta ip salga del programa hacia internet con una marca (0x1, por ejemplo):

acl smartphones src 192.168.255.254
tcp_outgoing_mark 0x1 smartphones

Y, finalmente, si hacemos que el tráfico con esta marca se enmascare con la dirección secundaria...

# iptables -t nat -I POSTROUTING -o eth0 -m mark --mark 0x1 -j SNAT --to-source 172.22.255.2

sufrirá las penalizaciones que hemos reservado a los smartphones.