Información blog

Linux, tutoriales, noticias, sistemas, redes y seguridad informática, entre otras cosas.

miércoles, 31 de agosto de 2016

Cómo medir la velocidad de lectura y escritura en disco en Linux

Agosto se acaba, y con ello los días de playa, relax y vacaciones, haciendo que cada uno tenga que volver a la rutina y haciendo que poco a poco la gente vaya retomando sus quehaceres habituales. Tras un pequeño descanso, vuelvo a la carga con las pilas cargadas y con ganas de seguir escribiendo artículos en este humilde blog que, espero que os gusten. En la ocasión de hoy vengo con un pequeño post orientado a la velocidad de lectura y escritura de un disco duro. 

disco_duro

La importancia de la eficiencia de todos los componentes es un hecho, y obviamente la eficiencia de un disco duro no es de menos, pues determina el tiempo que tarda este en leer un dato o escribirlo, cosa que no se nota con archivos pequeños, pero que se nota considerablemente en el tratamiento de archivos grandes. Generalmente es bastante perceptible por nuestra parte el saber si un disco actúa con la velocidad adecuada, pero a veces necesitamos datos más concretos, como saber con exactitud cuantos megabytes por segundo es capaz de leer y escribir.

Este proceso es bastante sencillo de realizar y la precisión con la que obtenemos el resultado es muy fiable, ayudándonos a hacernos una idea de le eficiencia de nuestro disco.


Requisitos

Los requisitos para realizar exitosamente este procedimiento son muy poco pero importantes. El primer requisito sería tener conocimiento del nombre de las unidades de disco instaladas en el equipo al igual que el tamaño de los sectores de éstas. Esta información se obtiene mediante un sencillo comando llamado fdisk, seguido del parámetro -l.

fdisk -l

En mi caso en concreto he obtenido el siguiente resultado referente a la única unidad de disco que tengo instalada que, como veis, se trata de /dev/sda y que contiene bloques de 512 bytes, un dato que no parece relevante, pero que tendrá cierta importancia más adelante..

fdiskl

Ahora que conocemos las características del disco instalado, tendremos que instalar una herramienta que posibilitará la medición de los tiempos de lectura del disco. Esta herramienta suele estar instalada por defecto en las últimas distribuciones, pero es preferible asegurarse. Dicha herramienta se denomina hdparm y se encuentra en los propios repositorios oficiales de las distribuciones Linux; es por eso que si deseamos instalar el paquete hdparm, simplemente tendríamos que escribir en la consola:

apt-get install hdparm


Velocidad de lectura

Comencemos con la velocidad de lectura. Esto se logra gracias la herramienta que recién acabamos de instalar; es decir mediante la herramienta hdparm. Con esta herramienta podremos medir la cantidad de MBs leídos por segundo, si bien es necesario ejecutarla varias veces y de ahí hacer una media, pues la velocidad de lectura no es un valor fijo, sino variable; un valor que  obviamente no cambia drásticamente cada vez que se ejecuta el comando, pero que sí que puede variar entre un comando y otro.

El comando a partir del cual obtendríamos la velocidad de lectura sería:

hdparm -tT /dev/sda

Este sería para ejecutar el comando una única vez, cosa que no ofrece un valor 100% fidedigno tal y como he dicho antes... La mejor forma de obtener una conclusión fiable, sería ejecutando dicho comando 10 veces, para lo cual podemos modificar la línea anterior para dejarla de la siguiente forma:

for ((i=1;i<=10;i+=1))do hdparm -tT /dev/sda; done

hparm_salida

Como podéis comprobar, a excepción de la primera lectura, que ha sido claramente más veloz que el resto, no hay una gran diferencia entre el resultado entre los comandos, con lo que podemos decir que el resultado obtenido es fiable.


Velocidad de escritura

Tan importante como la velocidad de lectura es la velocidad de escritura. Aquí, a diferencia de con el testeo de la lectura, no se usa el comando hdparm, sino que es necesario recurrir al comando dd, del cual ya he hablado con anterioridad. Este comando vuelca el contenido de un origen en un destino y muestra el tiempo invertido en dicha operación, con lo que es un método perfectamente válido para hacer la medición de velocidad de escritura.

Para la prueba en cuestión, lo que haremos será volcar cadenas de valores 0 en un fichero ficticio llamado  test.dat. Esos ceros se introducirán en bloques de 512 (debido a que hemos obtenido dicho tamaño anteriormente mediante el comando fdisk) 1 millón de veces. Además, para que el comando dd muestre un tiempo de escritura preciso, nos veremos obligados a usar el parámetro conv=fdatasync. Esto lo haremos usando el comando de a continuación.

dd if=/dev/zero of=/tmp/test.dat bs=512 count=1000000 conv=fdatasync

dd_salida

En este caso el tiempo de escritura ha sido de 33,8 MB/s, una cifra no especialmente alta, pero no del todo mala.


Como podéis observar, la comprobación de la velocidad de nuestro disco duro es realmente sencilla y nos ofrece valores muy concretos que nos puede dar una idea muy acertada de la eficiencia de éste.

Espero que os haya resultado útil.

Saludos.

miércoles, 17 de agosto de 2016

Cómo crear una terminal virtual en Linux con screen

Hoy quiero traeros un articulo orientado a la famosa consola de Linux que tanto nos gusta a muchos, y que otros tantos temen. El trabajar con las terminales de Linux es muy rápido y eficiente una vez se han adquirido ciertas nociones básicas, haciendo que la mayoría de las veces se quieran hacer tareas por consola en vez de desde interfaces gráficas (en caso de tenerlas). La cuestión está en que más de una vez tenemos el problema de que queremos tener una serie de tareas en segundo plano a las que poder acceder con comodidad cuando queramos. Esto a veces se puede lograr jugando con ejecuciones de procesos en background, pero eso a veces no nos vale, pues estas ejecuciones en muchas ocasiones son muy restrictivas... Tenemos un proceso en segundo plano sí; pero simplemente podemos hacer que dicho proceso se visualice en la pantalla; cosa que no está nada mal, pero que no es siempre lo que buscamos. A veces necesitamos algo más flexible y que se encuentre dentro de nuestra propia terminal y de ahí nace la necesidad de usar el comando screen; es decir del uso de terminales virtuales.

Screen_portada

Una terminal virtual, no es nada menos una subterminal que se ejecuta de forma independiente a la terminal "real" de forma virtualizada. Es importante no confundir este tipo de virtualización con la virtualización propiamente dicha, pues aquí simplemente se "virtualiza" la terminal; dejando intactos el resto de elementos del sistema. Esto hace que se puedan ejecutar ciertas tareas en segundo plano que queramos retomar más tarde.

Esta terminal virtual está instalada por defecto en algunos sistemas operativos, pero no en todos, o mejor dicho, no en todas las versiones de éstos, así que lo más recomendable es asegurarse de que efectivamente está instalado; cosa que se puede comprobar facilmente al estar incluido en los repositorios oficiales de la mayoría de los sistemas operativos.

apt-get install screen

Su uso es tan sencillo como escribir el comando, sin necesidad de recurrir a parámetro alguno.

screen

Esta terminal tendrá el mismo comportamiento que una terminal normal y en un principio no notaremos diferencia alguna ente una terminal "original" y una virtual; podemos ejecutar tareas a nuestro antojo sin temor a que haya diferencia alguna entre esta terminal y la normal si bien lo suyo es intentar aprovechar el potencial que ofrece screen. Imaginemos que ejecutamos una tarea interactiva que puede llevar bastante tiempo y que queremos ejecutar en segundo plano; algo como por ejemplo una actualización pesada del sistema, en la cual suelen haber cambios significativos y suelen haber actualizaciones que piden confirmación por parte del usuario, ya sea para saber si se está seguro de que se quiere actualizar un paquete en concreto o para mantener alguna configuración.

Se puede hacer que la terminal virtual pase a segundo plano para después volver a llamarlo... Para ello lo primero que habría que hacer sería presionar las teclas ctrl, a y d.  Podemos tener diferentes terminales en segundo plano; es decir, ejecutar el comando screen y poner la terminal en segundo plano en repetidas ocasiones... Es por eso que en caso de tener varias terminales en segundo plano, lo mejor es listarlas mediante el siguiente comando:

screen -ls

ls_screen

Si observáis bien, veréis que cada terminal está diferenciada por un número; en este caso serían los números 18254 y 18168. Si quisiéramos volver a tener el control de una de esas terminales, tendríamos que escribir el comando screen -r, seguido del número de terminal. Por ejemplo:

screen -r 18254

Si tuviésemos una única terminal en segundo plano, no sería necesario hacer referencia al número de ésta, pues no habría ninguna otra que elegir.

Obviamente también podemos darles fin a las terminales que hemos creado. Esto se puede hacer de dos formas: La primera sería usando la combinación de teclas ctrl, a y k. La segunda opción sería recurrir al mismo comando que usaríamos para salir de una terminal común; es decir:

exit

Como podéis ver, el uso del comando screen es realmente sencillo, únicamente requiere tener controladas las terminales que dejemos en segundo plano para dominar diferentes procesos y terminales simultáneos, otorgándonos un gran control sobre el sistema y ayudándonos a evitar usar diferentes consolas (ya sean ttys o sesiones ssh remotas) simultáneas.

Espero que os haya resultado útil.

Saludos.

miércoles, 10 de agosto de 2016

Telefonía: ¿VoIP o analógica?

La tecnología ha evolucionado de forma vertiginosa durante los últimos años, adquiriendo una velocidad de cambio cada vez mayor y haciendo que aparezcan nuevas herramientas de software, sistemas operativos, gadgets etc... Si bien probablemente lo que más ha notado el usuario "de a pie" podría decirse que es la revolución de la tecnología móvil con los smartphones y todo lo que ello ha supuesto, también hay otras tecnologías que están causando un gran calado, si bien obviamente en la gran mayoría de los casos no es apreciable por el usuario final. En este punto uno puede decantarse por multitud de opciones, pues es cierto que han habido grandes avances en numerosos campos, pero hoy quiero enfocarme en un área en concreto: La telefonía.

Portada_telefonia

La telefonía ha ido evolucionando mucho durante las últimas décadas, y si bien la telefonía analógica (la que todos, o la mayoría tenemos en casa) es la más popular de todos con gran diferencia; la telefonía IP, también conocida como telefonía VoIP (voz sobre IP), ha ido ganando bastante relevancia durante los últimos años; una relevancia que le ha ido costando ganar, pues la tecnología en sí se inventó en 1995, pero que cuya velocidad de expansión ha ido aumentando de forma exponencial. ¿Pero qué ventajas ofrece cada tecnología? ¿Qué puede hacer que nos decidamos por montar una centralita VoIP con, por ejemplo Asterisk, en vez de por una telefonía convencional? ¿Ventajas de cableado debido a que todos los paquetes viajan por cables UTP/fibra? ¿Ventajas tecnológicas? ¿O simplemente es una tecnología "nerd"? A continuación veremos las diferentes ventajas que ofrecería la telefonía Voip sobre la analógica.

Cableado


cableado_img

Una ventaja bastante importante que ofrece la tecnología Voip, es la parte del cableado. La telefonía analógica requiere de unos cables de 2 hilos con conectores RJ-11; es decir cables de telefonía convencional, mientras que la telefonía Voip viajaría sobre cables de red (generalmente UTP)  de 8 hilos con conectores RJ-45; es decir, sobre cables de red tradicionales. Eso nos ahorra bastantes esfuerzos a nivel de cableado y nos permitiría toda la tecnología dentro de una red, lo cual nos facilitaría la gestión de los teléfonos, el cableado general y el mantenimiento de la infraestructura, pues solamente requeriríamos de un tipo de cable, no de dos. Obviamente para comunicarnos con el exterior tendríamos que bien optar por realizar llamadas por una operadora que trabaje con VoIP, o recurrir a un intermediario que convierta la señal IPen analógica para comunicarnos con el exterior.

Coste

coste_img

Como acabo de comentar antes tenemos dos opciones para comunicarnos con el exterior. O bien vía VoIP o bien vía telefonía convencional... Ambas ofrecen sus ventajas y desventajas, si bien generalmente las llamadas por voz sobre ip son mucho más ventajosas a nivel económico.

La opción de VoIP tiene como ventaja que las llamadas son más baratas y que simplemente requiere conectar un cable de red al router y configurar este, pero tiene como desventaja que requiere buscar una operadora que trabaje con dicha tecnología, comparar precios etc... Cosa que si bien se puede hacer, es bastante tedioso debido a que no hay muchas compañías... Aún así puede traer beneficios a largo plazo, pues el coste de las llamadas (tanto del establecimiento de llamada como como del minuto de ésta) es mucho menor.

Otra enorme ventaja que ofrece la comunicación con el exterior vía VoIP, es que, en caso de tener varias sucursales y/o lugares de trabajo muy lejanos entre sí, se puede hacer que se comuniquen entre ellos mediante una VPN para que las llamadas entre estos puntos salgan GRATIS, lo que lo convierte en una opción muy atractiva a nivel económico en caso de tener dicha situación.

Un pequeño inconveniente de la comunicación VoIP es que requiere de cierta inversión inicial, tanto para tener un servidor como para tener unos teléfonos que soporten dicha tecnología (o conversores que hagan que los teléfonos puedan comunicarse vía VoIP); inversión que a medio/largo plazo se amortiza , pero que no deja de ser un cierto gasto inicial.

La llamada a través de tecnología analógica tiene como ventaja que es más fácil de implementar, pues simplemente requiere de un intermediario que convierta la señal de IP a analógica, y luego se envía la señal analógica por la toma telefónica ( la que todo el mundo tiene en casa). El intermediario puede ser el servidor de telefonía IP (que requeriría de una tarjeta especial llamada primario) o, más fácil, un gateway analógico (algo parecido a un router) que haría la conversión. En caso de no tener una centralita IP, simplemente habría que conectar el teléfono a la toma telefónica y listo... Es decir que el grado de dificultad del uso de esta tecnología es relativamente nulo.

Seguridad

seguridad_img

Más de uno se podrá sorprender al ver esto, pero así es. Es cierto que cada elemento que esté expuesto en la red es susceptible de ser hackeado, pero la tecnología analógica también es susceptible de ser hackeada; es más, el interceptar una comunicación de telefonía IP solamente requiere "pinchar" el teléfono. Obviamente eso requiere conocimientos y también el estar cerca de la toma telefónica, pero una vez han pinchado el teléfono no hay absolutamente nada que se pueda hacer para defenderse. 

La telefonía de voz sobre IP, obviamente también puede ser hackeada, y es cierto que el hecho de poder comunicarse vía IP hace que el abanico de posibilidades para que la comunicación se vea comprometida es mayor, pero siguiendo una serie de buenas prácticas de seguridad orientadas a este entorno y usando fail2ban combinado con un firewall, veremos que en realidad es mucho más seguro que la telefonía tradicional, pues es más "fácil" blindar el las comunicaciones. ¿Esto hace que la telefonía VoIP sea invulnerable en caso de estar adecuadamente protegida? Obviamente NO; pues la seguridad absoluta no existe, pero sí que obtendremos cierto grado de seguridad que nos hará estar relativamente tranquilos y siempre tendremos más oportunidades para defendernos que con la tecnología analógica, pues generalmente los ataques a centralitas telefónicas con tecnología VoIP, son muy agresivos y fáciles de detectar/prevenir, ya que dejan multitud de mensajes en los logs de las centralitas.

Ancho de banda y calidad de audio


bandwitdh_img

La telefonía analógica es muy sensible al ruido; es por eso que cualquier cosa que genere interferencias hace que la calidad del audio merme considerablemente, haciendo que la experiencia del usuario final sea bastante desagradable... Además tiene un gran problema y es que tiene un gran consumo de ancho de banda; ancho de banda que además no es aprovechado, pues tal y como he comentado antes es muy susceptible al ruido.

La telefonía IP es mucho menos sensible al ruido; y si bien hay factores, como el tipo de cable o la ubicación de éste, que pueden llegar a hacer que la transmisión no sea del todo "limpia", es mucho más dificil que se de el caso. Además, la telefonía IP cuenta con una serie de codecs que suelen jugar con dos valores: El ancho de banda y la calidad de audio. Generalmente a mayor el ancho de banda consumido, mejor la calidad del audio, con lo que dependiendo de nuestras necesidades podemos optar por un tipo de codec u otro. Generalmente se suele buscar un punto medio entre calidad y ancho de banda, si bien a veces lo que prima es la calidad ante cualquier otra cosa. He aquí una pequeña tabla informativa con algunos de los codecs más populares; hay muchos más, pero estos sería los más usados:

tabla_codecs

Llamadas simultáneas


Llamadas_img

Algo que no tiene punto de comparación entre la telefonía IP y la analógica, es la cantidad de llamadas simultáneas que pueden soportar unas y otras. Cuando se está hablando con el exterior, si alguien llama a tu número de teléfono se encontrará que el teléfono se encuentra comunicando, cosa que solamente se puede solventar contratando nuevas líneas telefónicas, con su correspondiente número etc... En la telefonía IP no hay límite, y además se puede configurar para que en caso de que se reciba una llamada desde el exterior y el teléfono de destino esté ocupado, se entré en modo de espera hasta que el teléfono esté libre.

Personalización


Asterisk_img

Aquí sí que podría decirse que vendría la parte más técnica de todas, pues lo cierto es que al crearnos una centralita IP podemos realizar acciones completamente personalizadas a nuestro gusto. Definir reglas, grupos de llamada, menús dinámicos, conferencias, macros, funcionamientos especiales según la fecha y hora... Es decir que con una centralita IP, podemos tener el control total de ésta. Aquí tenemos varias elecciones, pero la más famosa de todas debido a que es una herramienta libre, completamente personalizable y gratis (Ojo, libre no tiene que ser necesariamente gratis siempre) sería: Asterisk. Asterisk no requiere comprar un hardware especial, simplemente requiere un equipo con Linux e instalar dicho software en éste, lo cual lo convierte en una herramienta muy atractiva que a mí, personalmente, me parece increíblemente útil.


En conclusión podemos decir que si bien la telefonía analógica es muy sencilla de implementar y no requiere prácticamente inversión inicial alguna, no tiene la misma potencia que la telefonía IP que, si bien es más costosa de implantar (tanto a nivel de gasto como a nivel de conocimiento) nos puede ofrecer unos resultados muy satisfactorios a muy bajo coste a largo plazo, siendo una elección muy a tener en cuenta. No es de extrañar que cada vez más empresas opten por implantar este tipo de tecnología si bien cada uno debe valorar qué se adapta mejor a sus gustos y necesidades.

Espero que os haya resultado interesante.

Saludos.

viernes, 5 de agosto de 2016

Firefox 48 y el multiproceso

En este blog raramente hablo de cuestiones relacionadas con noticias a menos que éstas tengan un gran impacto o las considere muy interesantes, pues este blog no está orientado a dar noticias; pero en este caso en concreto, la noticia que os traigo hoy es muy relevante pues marca un punto de inflexión en uno de los navegadores más importantes del mundo: Firefox. El día 2 de Agosto, este gran navegador ha liberado la versión 48, algo que de por sí no causaría un gran revuelo si no fuese por que trajese una característica muy esperada: El multiproceso

firefox48_portada

Este concepto puede parecer muy "nerd" o muy poco relevante, pero en realidad no es así, pues el usuario final notaría la diferencia de inmediato. Hasta ahora, si había un problema con una de las pestañas de Firefox y dicha pestaña se bloqueaba, el navegador entero sufría las consecuencias, llegando a tener que incluso reiniciar dicho navegador para solventar el problema. Con el multiproceso, dicho problema desaparecería, o al menos se vería mermado en gran medida, pues lo que ocurriese en una pestaña, se quedaría en dicha pestaña sin llegar a afectar al resto. Esto significaría que si una página web se quedase "colgada" por cualquier motivo, y tuviésemos más pestañas abiertas, solo la pestaña que cargase dicha página web se quedaría bloqueada, no llegando a afectar al resto y haciendo que, como mucho, hubiese que cerrar la pestaña bloqueada. 

Esto supone un gran cambio a nivel de experiencia de usuario final, y más aún cuando otros navegadores, como Chrome, ya incorporaban dicha funcionalidad desde hacer algún tiempo, con lo que el hecho de que Firefox finalmente haya podido incorporar dicha funcionalidad hace que pueda estar a la altura de sus competidores. Aún así no todo son noticias "buenas", ya que Firefox ha preferido optar por la prudencia e ir incorporando la funcionalidad a unos pocos "elegidos", pues el multiproceso requiere que los Add Ons se adapten también a dicha funcionalidad; adaptación que todavía no ha madurado. En concreto, solo un 1% de los usuarios podrá disfrutar, por defecto, de dicha funcionalidad de momento, haciendo que dicho número aumente paulatinamente. 

La mejor forma de comprobar si tenemos dicha función activada, sería escribiendo en el navegador:

about:support

Lo más normal sería que os apareciese el siguiente contenido (este ejemplo sería con un equipo con Windows):

e10_disabled

Es decir, que NO estuviese activada dicha función. En caso de tener activada la función, se debería a que no usáis ningún Add On  que Firefox considere incompatible con el navegador. Eso no significa que no podáis activar manualmente dicha funcionalidad; si bien Firefox recomienda no hacerlo para evitar problemas de compatibilidad. Si sois de los que no pueden esperar a activar el multiproceso, tendréis que hacer lo siguiente:

En el navegador, hay una URL que en caso de escribirla os dejará manipular la configuración del navegador; se trata de una configuración relativamente delicada, con lo que es recomendable tocar siempre lo justo y necesario y a sabiendas de lo que dicha modificación acarrearía. Dicha URL es:

about:config

Allí habrá que modificar estos tres valores:

browser.tabs.remote.autostart --> Esta valor es necesario ponerlo a True.
extensions.e10sBlockedByAddons --> Este valor habría que ponerlo a False.
extensions.e10sBlocksEnabling --> Este valor también es necesario ponerlo a False.

Para vuestra información, al hacer referencia al concepto e10 en Firefox, se estaría refiriendo a la funcionalidad de multiproceso, con lo que si vieseis en el futuro alguna referencia a dicho nombre, tened en cuenta que dicho concepto es una especie de alias referente al multiproceso.

Con todos estos cambios aplicados, la mejor forma de comprobar que efectivamente el multiproceso está activado sería reiniciando el navegador y escribiendo en este de nuevo.

about:support

En caso de haber realizado los anteriores cambios correctamente, vereis un pequeño pero significativo cambio en la pantalla.

e10_enabled

Con esto ya se podría disfrutar de esta fantástica funcionalidad, si bien al ser algo que todavía se podría considerar como "beta", debido a la poca compatibilidad que tiene con los Add Ons, es recomendable ser cuidadoso con el uso de ésta, ya que puede que algún complemento no funcione del todo correcto.

Espero que os haya resultado interesante.

Saludos.

lunes, 1 de agosto de 2016

Cómo crear un DHCP relay en Linux

Hoy quiero traeros un pequeño artículo más orientado al mundo de las redes... El mundo de las redes es muy amplio y apasionante y tiene que contemplar un gran número de escenarios muy diversos entre sí... Uno de ellos es el hecho de que puedes tener una serie de equipos (PCs) separados de un servidor DHCP (Dynamic Host Configuration Protocol) por un PC intermedio que puede estar haciendo de firewall y/o otras tareas.  La cuestión está que generalmente queremos que haya únicamente un solo servidor DHCP, porque en caso contrario, en caso de haber cualquier fuga en el futuro, pueden haber conflictos tales como el hecho de que un equipo intente coger IP habiendo dos servidores DHCP y coja ip precisamente desde el servidor que no debe. Es por eso que existe un método que ayuda a saltar ese pequeño escoyo: El DHCP relay.

DHCP_relay_portada

DCHP relay no es más que un proxy que redirige las peticiones DHCP recibidas al servidor DHCP real para que éste las atienda. Esto no es nada complicado; requeriría que, para empezar tuviésemos el siguiente escenario a nivel físico: Un servidor DHCP; un equipo que hará de proxy (que tendrá dos tarjetas de red), un switch y luego todos los equipos queramos conectar a dicho switch; que pueden ser 2, 10 o los que deseemos. Un pequeño ejemplo gráfico sería el de a continuación:

Esquema_red

Lo primero que habría que hacer sería preparar un servidor DHCP; esto es tan sencillo como instalarlo desde los repositorios mediante apt-get:

apt-get install isc-dhcp-server

Aquí la configuración que uno puede aplicar puede ser muy personalizable; desde cosas muy sencillas a cosas tan especificas como la entrega de una serie de rangos de ip a unas MAC en concreto. En caso de no tener nociones sobre el funcionamiento de este servicio, una configuración muy básica que podríamos aplicar en /etc/dhcp/dhcpd.conf sería:

  1. default-lease-time 600;
  2. max-lease-time 7200;
  3. shared-network "test"{
  4.     subnet 192.168.1.0 netmask 255.255.255.0 {
  5.     }
  6.     subnet 192.168.2.0 netmask 255.255.255.0 {
  7.         range 192.168.2.2 192.168.2.255;
  8.     }
  9. }

Tras aplicar nuestros cambios sería imprescindible reiniciar nuestro servicio DHCP, con el comando:

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

Obviamente el ejemplo anterior es eso, un ejemplo; que puede ser adaptado a la situación que mejor convenga... Teniendo ese pequeño requisito preparado, sería el turno de preparar el DHCP relay. Esto es tan sencillo como ejecutar el comando de instalación, de forma parecida a como se ha hecho con el servidor.

apt-get install isc-dhcp-relay

A diferencia del servidor DHCP, el relay posee un asistente de configuración que hará que el proceso sea mucho más automatizado que su predecesor. En caso de equivocarnos durante el asistente no pasaría nada, pues los parámetros introducidos se encontrarían dentro del fichero de configuración /etc/default/isc-dhcp-relay.

El primer paso y más importante sería la especificación de la dirección ip del servidor DHCP REAL; es decir, la dirección ip a la que tendremos que redirigir las peticiones DHCP.

ip_DHCP

Tras eso, sería muy importante especificar en qué interfaz de red (ojo, interfaz de red, no dirección ip) deseamos estar "escuchando" las peticiones DHCP que queremos luego redirigir... Aquí habría que poner el nombre de la interfaz de red que estaría conectada a la red que va a solicitarnos ips para que sean entregadas por DHCP... El nombre de la interfaz puede ser eth0,eth1... En mi caso en particular sería eth0.

interfaz_relay

Por último, pero no por ello menos importante habría que especificar qué parámetros especiales asignarle al servicio DHCP-relay. Al arrancar un servicio se le pueden poner parámetros especiales que pueden aportar más o menos funcionalidades. En este caso en concreto nos interesa que se esté ejecutando en segundo plano, es decir que se ejecute como un demonio; así que le especificaremos el parámetro -D.

parámetro_relay

Al tener que hacer de "proxy" y tener que transferir información de una interfaz a otra, el equipo que haga de relay, es indispensable que el equipo tenga activada la función ip_forward, tal y como se hace cuando se quieren hacer tareas de NAT. Este parámetro está alojado a nivel de kernel, con lo que se encuentra dentro del directorio proc. La ruta completa sería: /proc/sys/net/ipv4/ip_forward

Ahora únicamente tendríamos que tener equipos que estuviesen preparados para hacer de clientes DHCP; tanto en Windows como en Linux, los equipos de escritorio estarían preparados para recibir ip automáticamente desde un servidor DHCP, si bien en Linux podríamos asegurarnos comprobando la existencia del fichero dhclient.conf dentro del fichero /etc/dhcp.

Con esto ya tendríamos nuestro DHCP relay preparado, pudiendo redirigir toda petición DHCP a un servidor real.

Espero que os haya resultado útil.

Saludos.