Repositorio Institucional de Documentos

Proyecto Fin de Carrera Ingeniería Informática Configuración de servicios de red de un dispositivo empotrado mediante una base de datos Autor Pablo Gómez Duro Director Roberto Casas Millán Ponente Jesús Alastruey Benedé Escuela de Ingeniería y Arquitectura Mayo 2013 Configuración de servicios de red de un dispositivo empotrado mediante una base de datos RESUMEN El proyecto ha consistido en el desarrollo de un backend para una plataforma de enrutamiento basado en políticas, cortafuegos y control de navegación web que se instalará en un sistema empotrado. El origen del proyecto surge por la necesidad de integrar varios productos, desarrollados anteriormente por la empresa, en un mismo sistema. Dichos productos proporcionan funcionalidades de enrutamiento, cortafuegos, traducción de direcciones, redes privadas virtuales (VPN), calidad de servicio (QoS), proxy de navegación web y análisis de tráfico, además de otros servicios de red básicos como son la asignación de direcciones y resolución de nombres dentro de una red. El trabajo realizado se ha centrado en proporcionar una abstracción de la configuración del sistema a través de una base de datos relacional para que posteriormente se desarrolle un frontal de administración web usando dicha base de datos como interfaz con el resto del sistema. Dicha abstracción se implementa mediante una base de datos diseñada para almacenar todo lo necesario para configurar el sistema, es decir, datos de configuración, reglas de filtrado de paquetes, reglas de enrutamiento, etc. Partiendo de los datos de configuración almacenados en la base de datos, se ha desarrollado el programa que genera la configuración adecuada para el sistema operativo y el software utilizado, y que es regenerada en el arranque del sistema o cada vez que se realice un cambio en la configuración. Para la implementación de la plataforma se ha usado el sistema operativo Linux como base. Linux proporciona todas las herramientas necesarias para implementar la mayor parte de las funcionalidades de red y es lo suficientemente estable para un sistema de este tipo. El resto de servicios se han implementado usando otros proyectos de software libre como OpenVPN, Squid, Dnsmasq, LSM, Ntop, Collectd, etc. Además de los servicios de red más usuales (enrutamiento, filtrado de paquetes o traducción de direcciones), se ha dotado al sistema de capacidades más avanzadas con el objetivo de mejorar la gestión del tráfico de red (aprovechamiento de ancho de banda, redundancia, tolerancia a fallos…), como por ejemplo: - Monitorización y balanceo de tráfico dirigido hacia Internet entre varios enlaces. - Agregación de varias conexiones VPN punto a punto enrutadas por varios enlaces. - Balanceo de tráfico de entrada a nivel DNS. Contenido 1 Objetivos y alcance del proyecto ..............................................................................1 1.1 Descripción ...........................................................................................................1 1.2 Contexto ...............................................................................................................2 1.3 Trabajo previo ......................................................................................................2 2 Análisis......................................................................................................................4 2.1 Requisitos .............................................................................................................4 2.2 Tecnologías usadas ...............................................................................................4 2.2.1 Lenguaje de programación ...........................................................................4 2.2.2 Base de datos relacional ...............................................................................4 2.2.3 Abstracción en el acceso a datos ..................................................................5 2.3 Planificación .........................................................................................................5 2.4 Arquitectura del sistema ......................................................................................5 3 Módulo de comunicación y abstracción (Core) ........................................................7 3.1 Esquema Entidad Relación del modelo de datos ..................................................7 3.2 Bases de datos de configuración y tiempo de ejecución ......................................7 3.3 Sistema de eventos ...............................................................................................8 3.4 Implementación....................................................................................................8 4 Backend ..................................................................................................................10 4.1 Interfaces ............................................................................................................10 4.1.1 Tipos de interfaces ......................................................................................12 4.1.2 Datos de configuración ...............................................................................13 4.2 Firewall ...............................................................................................................13 4.2.1 Sistema de filtrado de paquetes en Linux ...................................................14 4.2.2 Filtrado en capa de aplicación (Application-layer Firewall) ........................16 4.2.3 Filtrado MAC ...............................................................................................17 4.2.4 Datos de configuración ...............................................................................17 4.3 Enrutamiento......................................................................................................20 4.3.1 Enrutamiento en Linux................................................................................20 4.3.2 Balanceo .....................................................................................................20 4.3.3 Datos de configuración ...............................................................................21 4.4 Calidad de Servicio (QoS) ....................................................................................22 4.4.1 QoS en Linux ...............................................................................................22 4.4.2 Solución implementada ..............................................................................23 4.4.3 Datos de configuración ...............................................................................25 4.5 VPN .....................................................................................................................26 4.5.1 Tipos VPN ....................................................................................................26 4.5.2 Software empleado ....................................................................................27 4.5.3 Agregación ..................................................................................................27 4.5.4 Datos necesarios en base de datos .............................................................29 4.6 Control de navegación Web ...............................................................................30 4.6.1 Tipos ...........................................................................................................30 4.6.2 Autenticación ..............................................................................................31 4.6.3 Autoconfiguración ......................................................................................31 4.6.4 Datos de configuración ...............................................................................31 4.7 Balanceo de tráfico de entrada (DNS).................................................................32 4.8 DHCP y DNS ........................................................................................................32 4.8.1 Datos de configuración ...............................................................................32 4.9 Otros servicios ....................................................................................................33 4.9.1 Análisis y estadísticas de tráfico..................................................................33 4.9.2 Monitorización de enlaces ..........................................................................33 4.9.3 Gestión de certificados ...............................................................................34 4.9.4 Gestión remota ...........................................................................................34 5 Frontend línea de comandos (CLI) ..........................................................................36 6 Pruebas realizadas ..................................................................................................37 6.1 Entorno virtualizado ...........................................................................................37 6.2 Escenarios simulados para llevar a cabo las pruebas ..........................................37 7 Conclusiones ...........................................................................................................39 7.1 Grado de cumplimiento de objetivos iniciales ....................................................39 7.2 Ampliación del trabajo desarrollado...................................................................39 7.2.1 Interfaz de configuración web ....................................................................39 7.2.2 Consideraciones sobre IPv6 ........................................................................39 7.2.3 Incorporación de nuevos servicios ..............................................................39 7.3 Valoración personal ............................................................................................39 Bibliografía .......................................................................................................................40 A. Anexo Diagrama Entidad-Relación y Modelo Relacional ........................................41 B. Anexo: Proceso de configuración de servicios ........................................................49 1. Interfaces ............................................................................................................49 2. Firewall ...............................................................................................................52 3. Routing ...............................................................................................................56 4. Calidad de Servicio (QoS) ....................................................................................58 5. VPN .....................................................................................................................59 6. Control de navegación web ................................................................................62 7. DHCP y DNS ........................................................................................................63 Índice de figuras Figura 1: Esquema general del sistema ..............................................................................1 Figura 2: Diagrama de Gantt de la planificación.................................................................5 Figura 3: Diagrama de módulos del sistema 2....................................................................6 Figura 4: Diagrama de clases ..............................................................................................9 Figura 5: Esquema general de interfaces .........................................................................10 Figura 6: Esquema de composición de interfaces ............................................................11 Figura 7: Entidades configuración de interfaces ..............................................................13 Figura 8: Diagrama del flujo de paquetes por netfilter en Linux ......................................16 Figura 9: Entidades configuración de Firewall ..................................................................18 Figura 10: Entidades configuración de NAT .....................................................................19 Figura 11: Entidades configuración filtrado MAC .............................................................19 Figura 12: Entidades configuración Routing .....................................................................22 Figura 13: Esquema general de clasificación QoS.............................................................23 Figura 14: Ejemplo distribución ancho de banda con HTB ...............................................24 Figura 15: Esquema funcionamiento SFQ ........................................................................25 Figura 16: Esquema implementación QoS elegida ...........................................................25 Figura 17: Entidades configuración QoS ...........................................................................26 Figura 18: Diagrama general enlace VPN .........................................................................26 Figura 19: Diagrama enlace VPN site-to-site ....................................................................27 Figura 20: Esquema de agregación de varios enlaces VPN ...............................................28 Figura 21: Pérdida de un enlace en VPN agregada. ..........................................................29 Figura 22: Entidades configuración VPN ..........................................................................29 Figura 23: Entidades configuración proxy web ................................................................32 Figura 24: Entidades configuración hosts estáticos DHCP ................................................33 Figura 25: Entidades configuración DNS ..........................................................................33 Figura 26: Esquema de gestión remota mediante SSH .....................................................35 Figura 27: Entorno de pruebas simulado 1 ......................................................................37 Figura 28: Entorno de pruebas simulado 2 ......................................................................38 Figura 29: Diagrama Entidad Relación (DER) ....................................................................41 Figura 30: Enlaces generados en una VPN agregada ........................................................60 1 1 Objetivos y alcance del proyecto 1.1 Descripción El proyecto ha consistido en el desarrollo de un sistema que facilite e integre la configuración de un dispositivo con funcionalidades de red. Estas funcionalidades incluyen servicios de red básicos, enrutamiento avanzado, balanceo y redundancia de tráfico, redes privadas virtuales (VPN) y monitorización y control de tráfico. Los requisitos iniciales eran que el sistema ofreciese una interfaz gráfica de configuración web que permitiese administrar de forma sencilla toda la configuración del sistema, de manera que una persona con conocimientos generales de redes no tuviese problemas en la operación del mismo. Dados estos requisitos se optó por dividir el sistema en dos partes bien diferenciadas, una que gestionaría toda la configuración de red, sistema operativo, etc., y otra que se limitaría a ser la interfaz con el administrador del sistema, como hemos dicho anteriormente a través de una interfaz web. El acoplamiento entre ambas partes del sistema se realiza a través de una base de datos que almacena la configuración del sistema. La parte de la interfaz de usuario introduce cambios en la base de datos y la parte del sistema reacciona ante estos cambios mediante un sistema de gestión de eventos. Este proyecto fin de carrera ha abarcado las partes que comprenden la base de datos y los mecanismos de acceso a ella y la parte de configuración del sistema. La base de datos proporciona una abstracción de toda la configuración de red y servicios. La configuración contempla los parámetros básicos de interfaces de red, tablas de enrutamiento, reglas de filtrado y balanceo de tráfico, configuración de servicios VPN, control de navegación web, monitorización del sistema, etc. En la figura 1 se puede ver un esquema general del sistema desde el punto de vista de conectividad a redes. Figura 1: Esquema general del sistema 8 configuración. La sincronización entre ellas se lleva a cabo mediante la capa de abstracción en acceso a datos (ORM) y es transparente para ambos módulos. De esta manera conseguimos una mayor modularización y facilita mucho la creación de nuevos frontends o backends, ya que su única interfaz es la base de datos y no existe ningún acoplamiento directo entre ellos. 3.3 Sistema de eventos El sistema de eventos es el encargado de comunicar al Backend todos los cambios que se produzcan en la configuración. Como el sistema esta subdividido en módulos cada uno se encarga de un conjunto de datos de la configuración. Cada registro de la configuración tiene especificado un evento que es lanzado cuando este se modifica. El sistema de eventos proporciona a los servicios la manera de registrarse para que sean avisados cuando se produzca un evento. Dicho registro consistirá en que el servicio especifique un evento y un método que será invocado cuando se produzca dicho evento. El método recibirá como parámetro el registro modificado y deberá realizar las acciones necesarias para mantener la configuración de red sincronizada con lo que refleja la base de datos. 3.4 Implementación Tal y como hemos dicho, el Backend está dividido en servicios. Cada servicio implementa una funcionalidad común que permite tratarlos a todos de similar forma. Esto se ha implementado haciendo que todos los servicios hereden de una clase abstracta que proporciona la funcionalidad común y la interfaz que deben implementar todos los servicios. Esta abstracción proporciona la siguiente funcionalidad común:  Control de dependencias entre servicios.  Escucha y generación de eventos entre servicios.  Inserción de configuración en otros servicios (hooks). Todos los servicios heredarán dicha funcionalidad común, únicamente deberán implementar los métodos de configuración, arranque y parada. La figura 4 muestra el diagrama de clases. 9 Interfaces Firewall +getServices() +findService() ServiceManager +start() +stop() +configure() +deconfigure() Service IService «uses» Frontend «uses» +init() +commitConfig() +rollbackConfig() +enableService(service)() +disableService(service)() +findService() +getService() System Routing Figura 4: Diagrama de clases Como se observa en la figura 4, en el diagrama se ha introducido la clase ServiceManager que es encargada de controlar todos los servicios del sistema. Mantiene referencia a ellos para que sea posible la comunicación entre servicios. Cuando un servicio necesite de alguna funcionalidad de otro servicio, resolverá la dependencia a través de la clase ServiceManager. También tenemos la clase System que ofrece funciones de arranque y parada global y métodos para controlar el estado de los cambios de configuración pendientes. El objetivo de la clase System es que sea el punto de acceso desde el Frontend, siguiendo el patrón de diseño Fachada o Facade. 10 4 Backend Como hemos dicho anteriormente el Backend es la parte del sistema que interactúa finalmente con la configuración de red. Recibirá eventos del módulo de abstracción cuando haya cambios y se encargará de mantener la configuración de red sincronizada. Se ha dividido en servicios para hacer el producto final más personalizable. Cada servicio corresponde a una implementación de la clase abstracta Service nombrada anteriormente. Dicha implementación debe contener métodos para inicializar y parar el servicio y podrá registrar métodos que serán ejecutados cuando la base de datos genere un evento determinado. Lógicamente, aun dividiendo en módulos el sistema, hay módulos que dependen de otros para llevar a cabo su funcionalidad. Por ello en la definición de cada módulo se especifican sus dependencias tal y cómo se ha explicado en el punto 3.5. A continuación se van a detallar todos los servicios del sistema. Para seguir una pauta común, en cada servicio se va a explicar la funcionalidad requerida, los datos necesarios para implementar dicha funcionalidad, las dependencias de otros servicios, y finalmente las alternativas de implementación y la solución final adoptada. El proceso de configuración, con los comandos y ficheros generados, se especifica para cada servicio en el anexo B. 4.1 Interfaces El servicio de interfaces es el servicio más importante del sistema, ya que la mayoría del resto de servicios depende de él. Este servicio nos va a permitir definir y configurar las interfaces de red por las que van a entrar y salir paquetes de datos del sistema. Las interfaces de red corresponden con las tarjetas de red (NIC) que tiene físicamente un sistema. Cada interfaz de red puede recibir y enviar tráfico y tiene una configuración IP asociada, que es la que le permite determinar qué tráfico debe recibir. El sistema operativo recibe el tráfico y mediante el proceso de enrutamiento determina cuál es su interfaz de salida, como se puede observar en la figura 5. Figura 5: Esquema general de interfaces 11 Las interfaces de red pueden ser agrupadas para formar interfaces virtuales que ofrezcan funcionalidades adicionales. Estas agrupaciones pueden ser de cuatro tipos:  Puente o Bridge  Agregación (Bonding en Linux)  Interfaces VLAN  Interfaces Virtuales El funcionamiento de estas interfaces especiales es totalmente transparente para el sistema, es decir, el sistema operativo hace uso de estas interfaces de la misma manera que si fueran interfaces físicas. Lógicamente puede interesar combinar estos tipos de interfaces y es por ello que el modelo de datos contempla relacionar las interfaces en forma de árbol para poder abarcar todas las posibilidades. Desde un punto de vista más formal el modelo de datos implementa un DAG 1 (Directed Acyclic Graph o Grafo Acíclico Dirigido). La figura 6 muestra un ejemplo de lo que podría ser un conjunto de interfaces: Figura 6: Esquema de composición de interfaces Las interfaces finales utilizadas por el proceso de filtrado y enrutamiento serán las que se encuentran en la parte superior del árbol, y las interfaces físicas las que se encuentran en la parte inferior. Como hemos dicho, en el nivel superior no hay diferencia entre la configuración de los diferentes tipos de interfaces. Estas interfaces son las que recibirán la configuración IP. De aquí en adelante llamaremos interfaces lógicas a estas interfaces para distinguirlas de las interfaces físicas. La configuración de una interfaz supone la dirección IP, la máscara de subred y el gateway en caso de que lo haya. La máscara de subred determinará la subred a la que la interfaz pertenece, es decir, las IP que son alcanzables directamente a través de la interfaz configurada. La presencia o no de gateway determinará si se trata de una interfaz LAN o WAN 1 http://en.wikipedia.org/wiki/Directed_acyclic_graph 12 para el sistema. Si tiene gateway consideraremos que esa interfaz sirve para dar acceso a internet y por tanto será de tipo WAN. En cambio, si no se ha configurado un gateway se considerará que la interfaz es de tipo LAN, ya que todo el tráfico recibido por dicha interfaz tendrá que ser enrutado por otra de las interfaces presentes en el sistema. Realmente este modelo de configuración de interfaces en árbol es tan general que permite configuraciones incoherentes, como por ejemplo encadenar varias interfaces VLAN con tags distintos (la primera eliminará el tag, las demás no harán nada). De todas formas se ha preferido dejar esas comprobaciones de situaciones incoherentes a otro nivel y permitirlas en el modelo. 4.1.1 Tipos de interfaces A continuación se explican con más detalle las diferentes configuraciones que pueden tener las interfaces del sistema: 4.1.1.1 Puente entre interfaces (Bridging) Las interfaces agrupadas en un puente están unidas a nivel de enlace, es decir, que todas las tramas de nivel de enlace que lleguen por una y no tengan como destino la propia máquina serán redirigidas por todas las demás interfaces. Las tramas de datos retransmitidas atraviesan el sistema sin llegar al nivel de red, comportándose como un switch. La consecuencia de este comportamiento es que los paquetes no se verán afectados por ninguna regla de filtrado IP, por tanto no es posible usar dichas reglas para filtrar tráfico. A este nivel, en cambio, podemos hacer filtrado en función a la dirección MAC que tengan las tramas Ethernet. 4.1.1.2 Agregación de interfaces (Bonding) La agregación de interfaces o bonding (nombre que se le da en Linux) es una funcionalidad que proporciona el sistema operativo que permite unir varias interfaces físicas en una interfaz virtual con capacidades de alta disponibilidad. Es decir, el sistema podrá enviar paquetes por la interfaz virtual pero realmente esos paquetes serán enviados por las demás interfaces según sea la configuración. Esta agregación ofrece varios modos de funcionamiento, dependiendo de cómo envía los paquetes el sistema. Por un lado, una de las posibilidades es configurar la agrupación en modo activo-pasivo, que hará que sea una de las interfaces la que esté transmitiendo y recibiendo información y el resto estén a la espera por si la primera fallase. Por otro lado ofrece varias posibilidades para configurar la agrupación como activoactivo. Una de ellas permite que la transmisión de paquetes sea vaya alternando entre las interfaces (Round Robin). Esto nos permite aumentar el ancho de banda de transmisión pero no así el de recepción, porque los paquetes seguirán llegando sólo por una de las dos interfaces. Si queremos balanceo en la recepción de tráfico también se ofrece un modo que habilita el protocolo LACP, que negocia la conexión con los switches a los que está conectado. En este caso, lógicamente, será necesario hardware de red especial que soporte dicho protocolo. 4.1.1.3 Interfaces VLAN Las redes VLAN permiten el uso de varias subredes en un mismo segmento de red como si fuesen redes independientes. Esto se consigue añadiendo un campo a las tramas de nivel de enlace (Ethernet) tal y como especifica el estándar IEEE 802.1Q. Ese campo contiene un 13 identificador de red (VLAN tag) que permite diferenciar las tramas de una red y las de otra. Aplicado a nuestro caso quiere decir que el sistema operativo nos va a permitir filtrar tráfico según un determinado identificador. Es decir, podemos usar una misma interfaz física del sistema para tener varias interfaces lógicas que serán las que realmente use el sistema para el enrutamiento de paquetes. 4.1.1.4 Interfaces virtuales Las interfaces virtuales permiten definir interfaces a las que procesos de usuario se pueden conectar para implementar las funciones de envío y recepción de datos. Su principal uso es para implementar redes privadas virtuales (VPN). Es como si tuviésemos una interfaz en la en vez de conectar un cable conectamos un proceso dentro del mismo sistema. Este proceso se encarga de recibir y enviar todo el tráfico que pasa por la interfaz. En Linux existen dos tipos de estas interfaces, dependiendo de si emulan un nivel de red (tun) o un nivel de enlace (tap). Su uso con otras interfaces en la jerarquía permite opciones interesantes y muy versátiles como por ejemplo incluir una interfaz virtual conectada a una conexión VPN punto a punto y a su vez incluida en un puente con otra interface física. Si al otro extremo de la VPN tenemos la misma configuración nos serviría por ejemplo para extender una red LAN (usando una misma subred) de una empresa entre varias sedes en lugares distintos. 4.1.2 Datos de configuración Como hemos dicho es importante distinguir entre las interfaces lógicas y las interfaces físicas, ya que quién va a recibir una configuración IP van a ser las interfaces lógicas. Por ello se ha optado por separarla en dos entidades distintas. Por un lado la entidad Interface representa la configuración de las interfaces lógicas y por otro la entidad Device representa las interfaces físicas y sus relaciones entre sí para representar el DAG nombrado anteriormente. De acuerdo con esto en la figura 7 se muestra el esquema de entidades. Figura 7: Entidades configuración de interfaces 4.2 Firewall El servicio de Firewall proporciona la capacidad de seleccionar flujos de tráfico de determinadas características para aplicar sobre ellos acciones determinadas. Las acciones básicas que se aplican son para determinar si el tráfico es permitido o no, pero también es posible clasificar dicho tráfico de forma que otros servicios puedan tomar decisiones distintas en función de dicha clasificación. En este punto nos vamos a centrar en las formas de seleccionar el tráfico y cómo aceptarlo/rechazarlo o clasificarlo. En puntos siguientes, enrutamiento y calidad de servicio, se usará la funcionalidad de clasificación para tratar a los flujos de tráfico de forma adecuada. 14 El filtrado de paquetes actúa sobre la entrada de paquetes al sistema por cada una de la interfaces de red. Es importante decir que no actúa sobre las interfaces físicas, sino sobre las interfaces lógicas, tal y como las hemos clasificado anteriormente. Actuar sobre las interfaces físicas no tiene sentido excepto en un caso, detallado más adelante, que será el filtrado en función de la dirección MAC de los paquetes. No tiene sentido porque precisamente lo que pretendemos creando interfaces lógicas es tener más control sobre el tráfico. Si actuásemos sobre la interfaces físicas estaríamos perdiendo toda la capacidad de filtrar sobre agregaciones de interfaces o VLAN distintas. Una vez un paquete ha atravesado el filtrado de la interfaz por la que entra al sistema, pasará a la fase de enrutamiento y saldrá por una de las interfaces restantes sin ningún tipo de restricción. Es decir, los paquetes no son filtrados a la salida del sistema sino a la entrada. Esto implica que el tráfico local generado por el propio sistema no será, en principio, objeto de ningún tipo de restricción. El modelo de firewall implementado se basa en reglas que permiten seleccionar el tipo de tráfico y aplicarle una determinada acción, que será aceptar o rechazar el tráfico. Las reglas se aplican en orden y su aplicación termina cuando el tráfico coincide con lo especificado en una de las reglas, es decir, que la primera regla que coincida con el tráfico será la que se aplique. Para aumentar la seguridad, si un determinado tráfico no coincide con ninguna regla el tráfico será rechazado. De esta manera se evita posibles fallos de seguridad debido a algún error o descuido a la hora de introducir las reglas de filtrado en la configuración. Cuando hablamos de selección de tráfico nos referimos a seleccionar paquetes o flujos (TCP, UDP, etc.) en función de datos de la cabecera IP o del protocolo superior, es decir, datos como las direcciones de origen o destino y los puertos origen o destino. También es posible realizar la selección en función a un grupo de IP o puertos y negar las condiciones. Más adelante veremos la estructura de datos necesaria en base de datos para guardar la información que permita implementar estas reglas. El servicio también contempla la definición de reglas NAT (Network Address Translation) que nos permitirán hacer traducción de direcciones siguiendo las mismas condiciones de selección de tráfico. Las traducciones posibles son en la dirección origen y en la dirección destino, Source NAT y Destination NAT respectivamente. DNAT nos permite por ejemplo hacer que los paquetes provenientes de internet sean redirigidos hacia una IP interna. SNAT nos permite que puestos de una red con direccionamiento privado puedan tener acceso a internet traduciendo su dirección origen a una dirección IP de direccionamiento público, o a una IP de direccionamiento privado que está en una red en la que el router de nivel superior saber enrutar hacia ella. 4.2.1 Sistema de filtrado de paquetes en Linux El subsistema de filtrado en Linux recibe el nombre Netfilter. Netfilter provee todo la funcionalidad del núcleo del sistema operativo relativa a filtrado y traducción de paquetes de red y las herramientas de espacio de usuario para interactuar con su configuración. La 15 herramienta utilizada para configurar las reglas es el comando Iptables y esta implementada sobre Netfilter. Iptables permite generar un conjunto de reglas que nos permiten implementar el comportamiento deseado para nuestro sistema. Se basa en reglas divididas en una parte de selección y otra de acción. Las posibilidades que ofrece son tan amplias que se puede implementar muchas funcionalidades de filtrado y clasificación de tráfico e incluso, en algunos casos, de varias maneras cada una de ellas. Las reglas se agrupan en cadenas, que son conjuntos ordenados de reglas. A su vez las cadenas se agrupan en tablas según el propósito de las reglas que albergan. Existen unas cadenas predefinidas para cada uno de los estados por los que pasa un paquete en su tránsito por el sistema. Estas cadenas son las siguientes:  PREROUTING: Atravesada por los paquetes antes de que se tome la decisión sobre su enrutamiento, es decir por qué interfaz de red debe salir el paquete o si es local.  INPUT: Atravesada por los paquetes con destino local.  FORWARD: Atravesada por los paquetes con destino no local.  OUTPUT: Atravesada por los paquetes que tienen como origen el propio sistema.  POSTROUTING: Atravesada por todos los paquetes que salen del sistema una vez tomada ya la decisión de enrutamiento, es decir la interfaz de salida es ya conocida. Como hemos dicho las cadenas se agrupan en tablas de la siguiente manera:  Tabla filter: Contiene reglas cuyo objetivo es decidir sobre si un paquete es filtrado o no, es decir, si permitimos que continúe su paso por el sistema o lo descartamos. Contiene las cadenas INPUT, FORWARD y OUTPUT.  Tabla nat: Contiene reglas cuyo objetivo es aplicar mecanismos de traducción de direcciones para transformar las direcciones de los paquetes y así poder redirigirlos. Contiene las cadenas PREROUTING, OUTPUT y POSTROUTING.  Tabla mangle: Contiene reglas cuyo objetivo es modificar parámetros de los paquetes, tales como el tipo de servicio (TOS) o hacer marcado para tomar otras decisiones más adelante en el procesamiento de paquete. Contiene todas las cadenas mencionadas anteriormente. La figura 8 muestra cuál es el recorrido de un paquete y como va atravesando las cadenas de reglas desde que entra en el sistema hasta que sale de él. 16 Figura 8: Diagrama del flujo de paquetes por netfilter en Linux El funcionamiento de las cadenas de reglas consiste en que el paquete va recorriendo las reglas en orden y cuando llega a una regla en la que se cumple la condición de la regla se ejecuta la acción asociada. Hay dos tipos de acciones: acciones terminales y no terminales. Una acción terminal hace que se dejen de procesar las reglas restantes de la cadena, mientras que una acción no terminal hacer justamente lo contrario. Ejemplos de acciones terminales son ACCEPT y DROP que son las acciones usadas para aceptar y rechazar un paquete respectivamente. Como ejemplo de acción no terminal podemos nombrar la acción MARK, que permite marcar un paquete y continuar normalmente con su procesamiento, o también la acción LOG, que permite registrar el paso del paquete en el log del sistema. También es posible definir cadenas personalizadas y usar su nombre como acción para redirigir a ellas. En este caso si se desea interrumpir su procesamiento se podrá salir de ellas usando la acción RETURN. 4.2.2 Filtrado en capa de aplicación (Application-layer Firewall) Las reglas de filtrado que manipula iptables sólo afectan al nivel de red y transporte pero no es posible hacer selección de paquetes en función del protocolo de nivel de aplicación (capa 7). Para realizar este tipo de filtrado es necesario o bien realizar modificaciones en el núcleo Linux, ya que por defecto no incluye soporte para este tipo de filtrado, o bien utilizar una aplicación en espacio de usuario a la que el sistema operativo pasará los paquetes para que su contenido sea inspeccionado. Esta última opción implica el uso de un mecanismo de Netfilter 17 que permite la comunicación entre el núcleo del sistema operativo y un proceso de espacio de usuario. La aplicación encargada de analizar los paquetes es l7-filter que hace un marcado de paquetes cuando identifica un protocolo de nivel de aplicación, de manera que posteriormente se pueda usar la marca del paquete con las reglas de iptables para tomar la acción deseada. La implementación de este tipo de filtrado mediante un proceso de espacio de usuario requiere especial cuidado ante posibles fallos de dicho proceso, ya que si el proceso deja de estar en ejecución el sistema quedará completamente inoperativo ya que todo el tráfico de paquetes pasa a través del proceso. 4.2.3 Filtrado MAC El filtrado por dirección MAC permite establecer reglas que filtren determinadas tramas Ethernet en función de su origen. En Linux el filtrado MAC pude hacerse a dos niveles distintas. Lo normal es hacer el filtrado MAC a nivel de enlace, pero esa opción sólo está disponible si trabajamos con interfaces de tipo puente. En caso de trabajar con interfaces puente podemos, no sólo filtrar en el puente, sino que podemos hacer filtrado específico para cada uno de los puertos del puente. En caso de trabajar con interfaces normales, los paquetes no atraviesan el filtrado de nivel de enlace, y por tanto tenemos que usar los filtros IP para hacer el filtrado. En Linux los filtros en interfaces bridge se configuran con el comando ebtables. De las muchas opciones que ofrece nos centraremos en las funciones de filtrado básico, es decir dada una MAC y un puerto del bridge comprobar si aceptamos o denegamos ese tráfico. También permitiremos establecer la política del puerto de bridge. En el caso de querer filtrado MAC en interface no bridge, recurriremos a iptables, el cuál dispone de un módulo de selección que comprueba las direcciones MAC del paquete de forma similar a como lo haríamos para filtrar por direcciones IP. 4.2.4 Datos de configuración Como hemos comentado anteriormente una regla de firewall va a estar asociada a una interfaz y tendrá que tener los siguientes campos para poder establecer las condiciones de selección y acción:  Acción de la regla.  IP origen/destino y puerto origen/destino. Tanto textualmente como referencia a un alias.  Capacidad para especificar la inversión de cualquiera de los cuatro campos anteriores.  Protocolo de nivel de red y de nivel de aplicación. Para implementar el sistema de Alias se necesita una entidad que guarde los propios alias y otra con sus valores. Por tanto el modelo queda como se aprecia en la figura 9. 24 Asignación mínima y máxima del ancho de banda a cada tipo: Web: Mínimo 50% Máximo 100% Interactivo: Mínimo 20% Máximo 100% Resto de tráfico: Mínimo 5% Máximo 50% Dada la flexibilidad que permite Linux en este tema, las soluciones posibles son varias. Las colas se pueden combinar de cualquier manera formando un árbol, pero en nuestro caso no será necesaria una estructura muy compleja, ya que clasificación del tráfico se hará a un solo nivel, es decir, las clasificaciones de tráfico no contendrán otras subclasificaciones. 4.4.2.1 Hierarchy Token Bucket La disciplina de colas HTB permite clasificación de paquetes y definir una jerarquía de colas, en las que se puede definir individualmente las limitaciones de velocidad del tráfico. La jerarquía comienza definiendo un nodo raíz en el que se define el ancho de banda global. Posteriormente se pueden definir clases que cuelgan del nodo raíz, estableciendo límites de velocidad más específicos. La figura 14 muestra un ejemplo de jerarquía. Figura 14: Ejemplo distribución ancho de banda con HTB Una de las particularidades del algoritmo HTB es que permite establecer velocidades garantizadas para el tráfico. Las subclases de un nodo pueden tomar prestado ancho de banda del nodo superior respetándose siempre el ancho de banda garantizado. Si una clase no está usando su ancho de banda garantizado, este será redistribuido entre las demás clases que lo demanden, volviendo siempre a ser asignado a la primera clase si esta lo demanda. De esta manera se consigue que cada clase tenga su ancho de banda garantizado pero sin que esto sea un desaprovechamiento del ancho de banda si la demanda no llega al mínimo garantizado. 4.4.2.2 Stochastic Fairness Queueing La disciplina de colas SFQ no realiza ningún tipo de control de la velocidad del tráfico, sino que realiza una programación del envío de los paquetes basándose en una clasificación de flujos. Es decir, el algoritmo mantiene información sobre cada flujo de tráfico y programa el envío de cada paquete en función a esa información, de manera que haya una equidad (de ahí su nombre, fairness) en el consumo de ancho de banda de todos los flujos e impidiendo que un flujo acapare todo el ancho de banda disponible. De hecho sirve como un medio para mitigar 25 un ataque de denegación de servicio (DoS). En este contexto entendemos por flujo de tráfico una conexión TCP o UDP, un flujo ICMP, etc. En la figura 15 se pueden observar como SFQ clasifica los flujos. Figura 15: Esquema funcionamiento SFQ 4.4.2.3 Implementación con HTB y SFQ Para cumplir con los requisitos necesarios se ha implementado QoS con una mezcla de las dos disciplinas de colas explicadas anteriormente, HTB y SFQ. HTB nos permitirá garantizar/limitar el ancho de banda y priorizar los distintos tipos de tráfico. SFQ nos permitirá que dentro del mismo tipo de tráfico haya equidad entre todas las sesiones de manera que si una de ellas está usando mucho ancho de banda y el enlace se satura no perjudique a la latencia del resto de sesiones. La implementación consiste en un nodo raíz de HTB en el que crearemos una clase por cada cola que haya configurada en el sistema, cada una con su prioridad y su ancho de banda. En cada una de esas clases configuraremos una cola SFQ para dentro del mismo tipo de tráfico haya equidad entre sesiones. En la figura 16 se puede ver cómo quedaría la configuración de colas. Figura 16: Esquema implementación QoS elegida 4.4.3 Datos de configuración Como hemos dicho anteriormente la selección y clasificación del tráfico se realizará usando el mismo sistema de reglas utilizado para el Firewall (4.2). Con lo cual lo único que necesitamos es guardar las colas que vamos a utilizar para clasificar el tráfico, cada una con su prioridad y su ancho de banda reservado y limitado. Utilizaremos tantos por ciento en el ancho de banda ya que el ancho de banda de cada interfaz se especificara en su configuración (ver figura 17). 26 Figura 17: Entidades configuración QoS 4.5 VPN Las Redes Privadas Virtuales o Virtual Private Networks (VPN) permiten interconectar varias redes, que no tienen conectividad directa, a través de una red intermedia. Normalmente las redes a interconectar serán redes con direccionamiento privado, y la red intermedia será de direccionamiento público. En estas circunstancias es imposible hacer un enrutamiento entra ambas redes sin usar una solución VPN. Las soluciones VPN se basan en encapsular la información en los extremos de las redes privadas y enviarlos a través de paquetes IP en la red pública. De esta forma se consigue que las redes estén interconectadas manteniendo el direccionamiento privado. Además la conexión VPN permite el cifrado de datos, algo que lógicamente es muy importante si se va a trasmitir a través de una red pública. Este tipo de redes son muy usadas en la actualidad para ahorrar costes en interconexión de sedes de empresas. En vez de contratar un enlace privado con una compañía de telecomunicaciones, lo que se hace es usar internet (red pública) para conectar las distintas sedes. En la figura 18 presenta un esquema general de una red VPN: Figura 18: Diagrama general enlace VPN El túnel VPN se establece entre dos IPs que tienen conectividad directa y todo el tráfico que queramos hacer llegar de un extremo al otro será encapsulado a través del túnel. 4.5.1 Tipos VPN A grandes rasgos podemos distinguir dos clases de VPN según su uso. Por un lado tenemos las redes VPN para que clientes externos se conecten a una red interna de una organización. Normalmente estas redes se configuran utilizando una infraestructura de clave pública, extendiendo certificados a todos los usuarios de la red y teniendo así control sobre el uso de la misma. 27 Otro tipo de VPN son las extremo a extremo (site to site), que permiten unir dos redes de una organización en distintas sedes. Como el túnel VPN se establece entre los routers/firewalls en cada sede, el acceso desde los equipos a las demás redes de otras sedes es transparente. Figura 19: Diagrama enlace VPN site-to-site La figura 19 muestra un ejemplo de este tipo de VPN. Consiste en dos redes privadas de dos oficinas 10.1.1.0/24 y 10.1.2.0/24 unidas a través de un enlace VPN. Los routers VPN en ambos extremos disponen de dos IPs públicas. Como entre esas IPs hay conectividad directa se puede crear un enlace que servirá para encapsular paquetes de las redes privadas. De esta manera se crea un tunel al que se le ha asignado el rango 10.2.1.0/24 y las IPs 10.2.1.1 y 10.2.1.2 en los extremos. Después de esto lo único necesario para que haya conectividad entre las redes de las oficinas es que ambos routers tendrán que saber qué rangos de direcciones hay en la oficina del otro extremo para poder enrutarlos por el túnel. Es decir, por ejemplo en este caso, el router de la oficina 1 tendrá que saber que los paquetes con destino a 10.1.2.0/24 deberán ser enviados a 10.2.1.2 para que continue el enrutamiento ya dentro de la red de la oficina 2. En este sistema se han implementado los dos tipos de VPNs y en el caso de las VPN site to site se ha implementado también una técnica para obtener alta disponiblidad en el enalce. 4.5.2 Software empleado OpenVPN es un software libre que implementa técnicas VPN para crear conexiones punto a punto seguras. Poco a poco se ha ido estableciendo como estándar “de facto” en el mundo de las redes VPN libres. Como se ha comentado anteriormente en el apartado de interfaces, el fundamento de funcionamiento de este software son las interfaces virtuales que proporciona el sistema operativo. Las interfaces virtuales permiten conectar un proceso de usuario a la interfaz para que este implemente lo necesario para enviar y recibir el tráfico. Es decir, lo que hace un software VPN es escuchar en una interfaz virtual para recibir tráfico y posteriormente encapsularlo sobre una conexión cifrada a través de internet hasta su destino. 4.5.3 Agregación Como hemos dicho los túneles VPN nos facilitan llegar de una red a otra independientemente de la red intermedia y el camino que tome la información en dicha red. Teniendo en cuenta esto, podemos tener diversos túneles VPN con mismo origen y destino 28 pero que sean creados sobre distintas redes intermedias. Es decir, podemos tener por ejemplo un sistema con varios enlaces hacia internet y utilizar cada uno de ellos para realizar conexiones VPN. Desde un punto de vista abstracto no importa por qué túnel se encamine los paquetes de datos ya que el resultado en destino será el mismo. Por ello podemos utilizar un conjunto de túneles para balancear el tráfico sobre ellos, aumentando así el ancho de banda y aumentando la disponibilidad ante posibles fallos, como se puede observar en la figura 20. Figura 20: Esquema de agregación de varios enlaces VPN Para conseguir esta funcionalidad será necesario que el sistema operativo soporte la agregación de interfaces para poder hacer balanceo de la transmisión a nivel de enlace. Como se ha comentado en la sección de interfaces, la agregación de túneles en Linux se puede hacer mediante el driver de bonding. Como los túneles VPN se implementan mediante dispositivos virtuales TAP que a su vez son una emulación de un dispositivo Ethernet regular, entonces es posible añadirlos a una interfaz bonding como si de un dispositivo físico se tratase. También podremos configurar el modo de agregación de la misma manera que con interfaces físicas, es decir, modo de balanceo o modo de tolerancia a fallos. La única restricción es asegurar que todos los túneles añadidos a un bonding tengan como destino la misma máquina y además estén unidos en bonding también en destino, de lo contrario el comportamiento no será el esperado ya que los paquetes acabarán en distintos destinos. Otra cosa a tener en cuenta es cómo se realizan los enlaces internos, es decir el número de túneles internos y su origen y destino. En nuestro caso se ha optado por crear túneles desde cada IP a todas las del extremo opuesto. Por tanto si tenemos en un extremo N conexiones y en el otro M, tendremos N*M túneles intermedios. Esto nos garantiza alta disponibilidad y tolerancia a fallos siempre que al menos se mantenga operativa la conexión a través de un ISP en cada extremo. Para controlar que túneles están activos se realiza monitorización ARP del otro extremo del túnel mediante el driver de bonding. Si no se reciben respuestas ARP el túnel se considerará inoperativo y se excluirá al hacer la distribución de tráfico, como se puede ver en la figura 21. 29 Figura 21: Pérdida de un enlace en VPN agregada. 4.5.4 Datos necesarios en base de datos Para simplificar el modelo de datos se ha tratado de representar todos los tipos de túneles con una misma entidad, incluso los túneles agregados. En la figura 22 muestra el modelo para representar la configuración VPN. Figura 22: Entidades configuración VPN La relación con interfaces representa la interfaz o interfaces por las que se enrutará el túnel. Dependiendo del tipo de túnel se interpretará de una forma u otra. Si se trata de un túnel extremo a extremo se comprobará su modo y si es balanceo se usaran todas las interfaces en modo agregado. Si es modo failover se usara la primera que esté activa por orden de prioridad. En cambio sí es un túnel de acceso múltiple se ignora el modo y se toma la primera interfaz activa de las asignadas. Los demás datos necesarios son los datos de direccionamiento dentro del propio túnel y los puertos e IPs a las que establecer la conexión. También se incluyen referencias a las claves y certificados que harán falta para configurar la seguridad del túnel. De este tema se hablara con más detalle en el apartado de gestión de certificados (4.9.3). 30 4.6 Control de navegación Web Una de las funcionalidades del sistema es el control del tráfico de navegación web que atraviesa el sistema. De esta manera podemos tener registros del uso que se hace por parte de los usuarios e incluso establecer restricciones a ciertos tipos de webs. El control de navegación web se proporciona a través de un servidor proxy que hace de intermediario entre el equipo del usuario en la red local y los servidores reales de las páginas web en internet. Como se ha dicho su principal función, o al menos la que nos interesa en nuestro caso, es la del registro y control del tráfico web. Otra de sus funciones es hacer de caché de contenidos, para acelerar la navegación web, pero es algo que ha ido perdiendo interés con el paso de los años, según se han ido haciendo más rápidos los enlaces a internet y la web se ha ido haciendo cada vez más dinámica. Existen una gran cantidad de servidores proxy web, aunque se ha seleccionado el más completo y extendido. El software usado como servidor proxy es Squid ya que proporciona todas las funcionalidades requeridas: proporciona registros de navegación, autenticación, filtrado de contenidos y configuración en modo intercepción (transparente). Quizá sea algo pesado para su uso en un sistema empotrado, pero es difícil encontrar otro software capaz de contar con todos los requisitos necesarios. 4.6.1 Tipos Desde el punto de vista de la interacción del equipo del usuario con el proxy web hay dos tipos bien diferenciados, cada con sus ventajas y sus inconvenientes. Por un lado tenemos lo que sería un proxy web corriente. Los equipos de los usuarios tienen configurados sus navegadores para que envíen todas las peticiones a través del servidor proxy, del que lógicamente deberán conocer su dirección IP y puerto. Esos datos los han debido obtener alguna fuente, bien sea a través de configuración manual por los técnicos que administren los equipos o a través del protocolo de autodescubrimiento de proxy web WPAD del que se hablará más detalladamente en siguientes puntos. Como inconveniente de este método podemos destacar el tema de la necesidad de configuración en los puestos de usuario, aunque si se automatiza este problema será mínimo. Otro inconveniente es que los usuarios pueden llegar a saber que están navegando a través de un proxy. El otro tipo de proxy es de intercepción. Los equipos de usuario no conocen la existencia de un proxy en la red, es decir, sus peticiones hacia servidores web en internet se hacen de la manera habitual, como si no existiese proxy. En este caso es el propio firewall el que intercepta las conexiones hacia servidores web en internet y las reenvía hacia el servidor proxy local. La ventaja de este método es que el puesto del usuario no requiere configuración y que el proxy es indetectable por los usuarios. Y como inconveniente destacar que esté método no sirve para interceptar conexiones seguras SSL, ya que el hecho de interceptarlas supone una violación del protocolo y los navegadores lo detectarán como un ataque man-in-the-middle. 31 4.6.2 Autenticación Si usamos el proxy normal además podemos añadir autenticación de usuarios. Esto nos permitirá identificar claramente los historiales de navegación de los usuarios de la red. Squid permite autenticar contra muchos tipos de registros, incluso tiene una interfaz genérica para implementar la autenticación a mano. En nuestro caso hemos optado por permitir la autenticación contra un registro local de usuarios, que está almacenado en la propia base de datos de sistema, o contra un servidor LDAP externo. 4.6.3 Autoconfiguración Para que los navegadores de los puestos de usuario utilicen el servidor necesitan saber su localización (IP y puerto). Como se ha comentado anteriormente la opción de establecerlos manualmente es poco práctica si el número de puestos es numeroso. Para estos casos existe un protocolo llamado WPAD (Web Proxy Autodiscovery Protocol) que está soportado por la mayoría de navegadores web y que permite automatizar este proceso. Este protocolo está definido en el RFC3040 sección 6.4. El funcionamiento de WPAD se basa por un lado en unos ficheros llamados PAC (Proxy AutoConfiguration) que son ejecutados por el navegador y que contienen una función JavaScript que devuelve la IP y puerto del servidor proxy. Como estos ficheros se ejecutan en el navegador es posible contextualizar la respuesta que se da con variables del puesto del usuario, por ejemplo devolver un servidor proxy u otro en función de la red en la que se encuentra el equipo. La otra parte del protocolo es la que permite obtener al navegador dichos ficheros PAC. Y aquí presenta dos alternativas para llevarlo a cabo, ambas se basan en proporcionar al navegador una dirección URL de la que descargará el fichero PAC. La primera alternativa hace uso del protocolo DHCP. El navegador lanza una solicitud DHCP especial en la que se pide la dirección URL anterior, el servidor DHCP se la proporciona y el navegador la descarga. La otra alternativa hace uso del DNS. El navegador busca un host llamado "wpad" en la red y una vez recibe la IP trata de descargar el fichero PAC desde una ruta establecida por el protocolo (http://ip/wpad). El problema de este protocolo está la forma de obtener el fichero PAC ya que unos navegadores soportan el método DHCP (Internet Explorer) mientras que otros sólo soportan el DNS (Mozilla Firefox, Google Chrome, Safari). Esto hace que ambos métodos sean complementarios y haya que implementarlos los dos. 4.6.4 Datos de configuración Asumiendo que únicamente queremos dar servicio de proxy en las interfaces LAN, lo único que se necesita es saber el tipo de proxy que una interfaz tiene configurado, todo lo demás se puede obtener de la configuración del resto del sistema. En el caso de que se configure con autenticación sí que necesitamos datos de los usuarios autorizados, para ello se usa una tabla con ese propósito. En la figura 23 se puede ver el modelo. 32 Figura 23: Entidades configuración proxy web 4.7 Balanceo de tráfico de entrada (DNS) Como hemos dicho anteriormente es posible que el sistema cuente con varias interfaces que den acceso a internet (interfaces WAN). Con el balanceo de tráfico de entrada se pretende que las peticiones que lleguen desde internet sean distribuidas equitativamente entre todos los enlaces. Como cada enlace tendrá su correspondiente IP pública la única forma que tenemos de distribuir las peticiones entre varias IP es usar DNS. Para conseguir esta funcionalidad se ha configurado el software PowerDNS de forma que escuche peticiones DNS en las interfaces WAN. Las respuestas a dichas peticiones contendrán siempre las direcciones IP públicas de los enlaces WAN activos (ver punto 4.9.2). De esta manera bastará con configurar el dominio que queramos para que sus servidores DNS apunten a las IP públicas de las interfaces WAN. Si en la resolución DNS resulta que una de las interfaces WAN esta fuera de servicio se pasará a preguntar al siguiente servidor DNS del dominio tal y como especifica el estándar DNS, de esta forma conseguimos que un fallo en una conexión WAN pase desapercibido. 4.8 DHCP y DNS Este servicio implementa funcionalidad básica para el funcionamiento de una red local como son la asignación de direcciones IP y el servicio de resolución de nombres. Los requisitos que debe cumplir son los siguientes:  Servidor DHCP en cada interfaz de red.  Posibilidad de establecer concesiones DHCP estáticas por Hostname, IP y MAC.  Servidor DNS local para poder registrar nombres locales. Reenvío de peticiones a DNS global si no se encuentra el nombre en local (Forwarding).  Posibilidad de configurar los servidores DNS para un dominio específico. Partiendo de estos requerimientos se ha optado por usar el software Dnsmasq. Se trata de un servidor DHCP y forwarder DNS integrado. El hecho de que maneje funciones DHCP y DNS a la vez permite que podamos dar el servicio con un sólo proceso en el sistema, simplificando así su gestión. 4.8.1 Datos de configuración Según los requisitos comentados en el punto anterior necesitaremos para cada interfaz de red datos para configurar su servidor DHCP. Estos datos son el rango de direcciones que va a ofrecer y el tiempo de validez que tendrán las concesiones que haga (lease time). Para ello hemos añadido a la entidad Interfaz definida en el punto 4.1 los datos anteriores. Para declarar las concesiones estáticas se ha añadido otra entidad relacionada con la entidad Interfaz. Ésta entidad contendrá Hostname, IP y MAC (ver figura 24). 33 Figura 24: Entidades configuración hosts estáticos DHCP En cuanto a DNS necesitamos una entidad que guarde los nombres locales y otra que guarde los servidores DNS para dominios específicos (ver figura 25). Figura 25: Entidades configuración DNS 4.9 Otros servicios En este punto se enumeran otros servicios y funcionalidades de las que dispone el sistema. 4.9.1 Análisis y estadísticas de tráfico Además de todos los servicios que proveen funcionalidad a los equipos de la red, el sistema dispone de varios medios para obtener información sobre el funcionamiento de la red, como por ejemplo cantidad de tráfico a lo largo del tiempo, estado de las conexiones de red, tipo de tráfico en la red, etc. Estos servicios no influyen directamente sobre el funcionamiento de la red, simplemente permiten tener un mayor control sobre lo que está ocurriendo en ella y así tomar decisiones posteriores para corregir las anomalías detectadas. Se ha optado por dos software de los mucho que hay disponibles para ello. Por un lado Ntop que permite hacer un análisis del tráfico de red y Collectd que guarda en bases de datos RRD datos sobre el tráfico y rendimiento del sistema para su posterior análisis generando gráficas. 4.9.2 Monitorización de enlaces Para determinar si un enlace hacia internet está activo se utiliza el programa LSM 2 (Link Status Monitor) que comprueba la disponibilidad de conexión enviando tráfico ICMP hacia una serie de IP definidas. El programa genera un evento cuando se produce un cambio en el estado de los enlaces, de manera que ese evento sea capturado por los servicios que dependan del estado de los enlaces para mantener una configuración óptima. 2 http://lsm.foobar.fi/ 40 Bibliografía  Designing and Implementing Linux Firewalls and QoS using netfilter, iproute2, NAT and l7-filter – Lucian Gheorghe  Linux Advanced Routing & Traffic Control: http://lartc.org/  RFC sobre técnicas multi-homing: http://www.ietf.org/rfc/rfc4116.txt  RFC sobre DNS load balancing: http://tools.ietf.org/html/rfc1794  Documentación del proyecto Netfilter/Iptables: http://netfilter.org/documentation/  Documentación del proyecto iproute2: http://www.linuxfoundation.org/collaborate/workgroups/networking/iproute2  Documentación general sobre Networking en Linux: http://www.linuxfoundation.org/collaborate/workgroups/networking/group  Documentación del proyecto OpenVPN: http://openvpn.net/index.php/opensource/documentation.html  Documentación del proyecto PowerDNS: http://doc.powerdns.com/html/index.html  Documentación del proyecto Squid: http://www.squid-cache.org/Doc/  Documentación proyecto GNU: http://www.gnu.org/doc/doc.es.html  Documentación de PHP: http://php.net/manual/es/index.php  Documentación de Propel: http://propelorm.org/documentation/  Documentación de SQLite: http://www.sqlite.org/docs.html 41 A. Anexo Diagrama Entidad-Relación y Modelo Relacional En este anexo se muestran el Diagrama Entidad-Relación (DER) y su traducción al Modelo Relacional. En la descripción de las tablas del modelo se explica el propósito de cada uno de los atributos de las entidades.  Diagrama Entidad-Relación (DER) Interface usa 1 Device 1 tiene MACFilterRule DNATRule SNATRule FilterRule Alias Queue InterfaceGroup VPNTunnel enruta 0..N 0..N tiene tiene tiene usa usa usa clasifica Gateway enruta 0..N 0..1 1 0..N 0..N 0..N 0..N 0..1 pertenece0..N 0..N 1..N 1..N 1..N 0..1 0..1 0..1 10..N 1 111 Certification Authority CertificateSharedKey usa pertenece 0..1 0..N 0..1 ProxyUser Preference DnsHost DhcpStaticHost DnsOverride tiene tiene tiene 1 0..N 0..N 0..N usa 0..1 0..N usa 0..N 0..N Figura 29: Diagrama Entidad Relación (DER)  Modelo Relacional A continuación se describe la traducción de modelo ER al modelo relacional. Se describen todas las tablas, relaciones y cada uno de sus campos. o Tabla gateway:  id: integer, clave primaria  name: varchar, nombre del gateway  device_id: FK(device), device que tiene asociado 42  static_routes: varchar, rutas estáticas asociadas al gateway o Tabla interface  Id: integer, clave primaria.  Gateway_id: FK(gateway), gateway del que hereda.  Ip: varchar, IP asociada a la interfaz.  Cidr: integer, CIDR para generar máscara.  public_ip_static: varchar, IP pública estática de acceso a internet, usada por servicio VPN.  downbw: integer, Ancho de banda de recepción máximo, usado por servicio QoS.  upbw: integer, Ancho de banda de envío máximo, usado por servicio QoS.  dhcps_ip_range_start: varchar, ip de inicio del rango dhcp, usado por el servicio DHCP.  dhcps_ip_range_end: varchar, ip de fin del rango dhcp, usado por el servicio DHCP.  dhcps_lease_time: integer, tiempo de concesión dhcp, usado por el servicio DHCP.  dhcps_max_lease_time: integer, tiempo máximo de concesión dhcp, usado por el servicio DHCP.  proxy_type: integer, tipo de proxy web que funcionará en la interfaz, usado por el servicio de Proxy Web.  proxy_port: integer, puerto en el que funcionará el proxy web, usado por el servicio de Proxy Web.  proxy_ldap_ip: varchar, ip del servidor LDAP cuando la autenticación es LDAP, usado por el servicio de Proxy Web.  proxy_ldap_base_dn: varchar, DN del LDAP dónde buscar datos de autenticación, usado por el servicio de Proxy Web.  admin_status: integer, estado de la interfaz para enrutamiento, 1(AUTO), 2(UP), 3(DOWN). Usado por el servicio de Routing.  Clave(name). o Tabla device  Id: integer, clave primaria.  Name: varchar, Nombre del dispositivo.  Type: integer, Tipo de dispositivo (Interface, Vlan, Bonding, Bridge, Virtual).  Master_id: FK(device) referencia a dispositivo master.  Slave_id: FK(device) referencia a dispositivo esclavo.  Vlan: interger, tag vlan asociada al dispositivo.  Bonding_type: integer, tipo de bonding en el caso de que lo sea (ActiveBackup, BalanceRR).  Policy: integer, política para el filtrado MAC, (ACCEPT, DROP).  Mac: varchar, mac del dispositivo, para sobrescribir la original.  Clave(name). 43 o Tabla monitor_ip  Id: integer, clave primaria.  Intereface_id: FK(interface), referencia a la interfaz a la que pertenece.  Ip: varchar, ip que se monitoriza.  Clave(interface_id, ip). o Tabla interface_group  Id: integer, clave primaria.  Gateway_id: FK(gateway), gateway del que hereda.  Type: integer, tipo de grupo (Balancer, Failover, RoundRobinSticky)  Clave(name). o Tabla interface_interface_group  Id: integer, clave primaria.  Interface_id: FK(interface), referencia a interface.  Interface_group_id: FK(interface_group), referencia a interface_group.  Order: integer, orden de preferencia.  Clave(interface_id,interface_group_id). o Tabla alias  Id: integer, clave primaria.  Name: varchar, nombre del alias.  Clave(Name). o Tabla alias_value  Id: integer, clave primaria.  Alias_id: FK(alias), alias al que pertenece.  Value: varchar, valor del alias.  Type: integer, tipo de alias (IP,PORT).  Clave(alias_id,vale,type). o Tabla queue  Id: integer, clave primaria.  Name: vachar, nombre de la cola.  Down_bw_min: integer, % del ancho de banda de recepción mínimo.  Down_bw_max: integer, % del ancho de banda de recepción máximo.  up_bw_min: integer, % del ancho de banda de envío mínimo.  up_bw_max: integer, % del ancho de banda de envío máximo.  priority: integer, prioridad de la cola (1-7).  Clave(name). o Tabla filter_rule  id: integer, clave primaria.  interface_id: FK(interface), interfaz a la que pertenece.  disabled: integer, estado de activación (0 desactivada, 1 activada).  action: Enum(ACCEPT,DROP,REJECT), acción de la regla.  gateway_id: FK(gateway), gateway por el que se enrutará el tráfico.  queue_id: FK(queue), cola en la que se encolara el tráfico.  protocol_l7: varchar, protocolo de capa de aplicación del tráfico.  protocol: varchar, protocolo del tráfico. 44  src: varchar, IP origen del tráfico.  src_port: integer, puerto origen del tráfico.  dst: varchar, IP destino del tráfico.  dst_port: integer, puerto destino del tráfico.  src_alias_id: FK(alias), alias IPs origen del tráfico.  src_port_alias_id: FK(alias), alias puertos origen del tráfico.  dst_alias_id: FK(alias), alias IPs destino del tráfico.  dst_port_alias_id: FK(alias), alias puertos destino del tráfico.  not_src: integer, inversión del selector de IPs origen (0 no, 1 si).  not_dst: integer, inversión del selector de IPs destino (0 no, 1 si).  not_src_port: integer, inversión del selector de puertos origen (0 no, 1 si).  not_dst_port: integer, inversión del selector de puertos destino (0 no, 1 si).  order: integer, orden de la regla. o Tabla dnat_rule  id: integer, clave primaria.  interface_id: FK(interface), interfaz a la que pertenece.  disabled: integer, estado de activación (0 desactivada, 1 activada)  protocol: varchar, protocolo del tráfico.  ext_ports: varchar, puertos externos a los que afecta la regla.  nat_ip: varchar, IP a la que se traduce el destino del tráfico.  int_ports: varchar, puertos internos a los que se traduce el tráfico.  ext_ports_alias_id: FK(alias), alias puertos externos.  int_ports_alias_id: FK(alias), alias puertos internos.  fw_rule_auto_add: integer, generación automática de regla de firewall, (0 no, 1 si).  order: integer, orden de la regla. o Tabla snat_rule  id: integer, clave primaria.  interface_id: FK(interface), interfaz a la que pertenece.  disabled: integer, estado de activación (0 desactivada, 1 activada).  protocol: varchar, protocolo del tráfico.  src: varchar, IP origen del tráfico.  src_port: integer, puerto origen del tráfico.  dst: varchar, IP destino del tráfico.  dst_port: integer, puerto destino del tráfico.  src_alias_id: FK(alias), alias IPs origen del tráfico.  src_port_alias_id: FK(alias), alias puertos origen del tráfico.  dst_alias_id: FK(alias), alias IPs destino del tráfico.  dst_port_alias_id: FK(alias), alias puertos destino del tráfico.  translation_ip: varchar, IP origen a la que se traduce el tráfico.  translation_port: integer, puerto origen al que se traduce el tráfico. 45  static_port: integer, determina si se mantiene el mismo puerto o no, (0 no, 1 si).  order: integer, orden de la regla. o Tabla vpn_tunnel  id: integer, clave primaria.  gateway_id: FK(gateway), gateway del que hereda.  type: Enum(S2S,PKI_SERVER,PKI_CLIENT), tipo de túnel.  dev_type: Enum(TUN,TAP), tipo de dispositivo que se usará.  mode: Enum(Balance, Failover), modo de funcionamiento de alta disponibilidad.  remote_ips: varchar IPs remotas.  local_port: integer, puerto local del túnel.  remote_port: integer, puerto remoto del túnel.  protocol: Enum(tcp,udp), protocolo del túnel.  local_routes: varchar, rutas que van por el túnel.  remote_routes: varchar, rutas que se anuncian en el otro extremo.  address_pool: varchar, pool de direcciones para servidor PKI.  tunnel_local_ip: varchar, ip interna del túnel en modo extremo a exremo.  tunnel_remote_ip: varchar, ip interna del túnel en modo extremo a exremo.  shared_key_id: FK(shared_key), referencia a clave para cifrado.  certificate_id: FK(certificate), referencia a certificado para autenticación y cifrado.  autostart: integer, autoarrancar el túnel o no (0 no, 1 si). o Tabla interface_vpn_tunnel  vpn_tunnel_id, FK(vpn_tunnel), referencia al túnel vpn.  interface_id, FK(interface), referencia a la interfaz.  order: integer, orden de preferencia de la interfaz. o Tabla shared_key  id: integer, clave primaria.  name: varchar, nombre de la clave.  key: varchar, clave. o Tabla ca  id: integer, clave primaria.  name: varchar, nombre de la CA (Certification Authority).  crt: varchar, certificado (clave pública y firma).  key: varchar, clave privada.  crl: varchar, lista de revocación.  dh: varchar, parámetros DH.  index_txt: varchar, index de EasyRSA.  country: varchar, país de la CA. 46  province: varchar, provincia de la CA.  city: varchar, ciudad de la CA.  organization: varchar, organización de la CA.  email: varchar, email del responsable de la CA. o Tabla certificate:  id: integer, clave primaria.  ca_id: FK(ca), ca a la que pertenece el certificado, nulo si no pertenece a ninguna.  ca_crt: varchar, certificado de la CA (clave pública y firma).  cname: varchar, common name del certificado.  name: varchar, nombre del certificado.  type: Enum(Client,Server), tipo de certificado.  crt: varchar, certificado (clave pública y firma).  key: varchar, clave privada.  dh: varchar, parámetros DH.  crl: varchar, lista de revocación de la CA.  is_revoked: integer, estado de revocación (0 ok, 1 revocado). o Tabla dns_override  id: integer, clave primaria.  interface_id: FK(interface), interfaz a la que pertenece.  domain: varchar, dominio.  ip: varchar, IP del servidor DNS del dominio. o Tabla dhcp_static_host  id: integer, clave primaria.  interface_id: FK(interface), interfaz a la que pertenece.  mac: varchar, dirección MAC del host.  hostname: varchar, nombre del host.  ip: varchar, IP del host. o Tabla proxy_user  id: integer, clave primaria.  interface_id: FK(interface), interfaz a la que pertenece.  login: varchar, nombre de usuario.  password: varchar, contraseña del usuario. o Tabla mac_filter_rule  id: integer, clave primaria.  device_id: FK(device), dispositivo al que pertenece.  mac: varchar, dirección MAC a la que afecta la regla.  action: Enum(ACCEPT,DROP), acción de la regla. o Tabla host 47  id: integer, clave primaria.  name: varchar, nombre del host.  domain: varchar, dominio del host.  ip: varchar, IP del host. o Tabla preferences  id: integer, clave primaria.  name: varchar, nombre de la opción de configuración.  value: varchar, valor de la opción de configuración. 48 49 B. Anexo: Proceso de configuración de servicios En este anexo se describe el proceso de configuración de cada uno de los servicios del sistema. Para cada servicio se detallaran los comandos y ficheros que se generan para que el sistema funcione de la manera descrita en la base de datos. 1. Interfaces El servicio de configuración de interfaces configura las interfaces una a una empezando por la parte baja del árbol y subiendo hasta que todas han sido configuradas. Cada tipo de interfaz tiene, además de parámetros específicos, una forma distinta de ser configurada. A continuación se van a detallar todos los comandos que emplea el servicio para configurar las interfaces. Estado de interfaces Todas las interfaces, sean del tipo que sean, pueden estar habilitadas o deshabilitadas. Para habilitar o deshabilitar se usan los siguientes comandos: # habilitar $ ip link set dev eth0 up # deshabilitar $ ip link set dev eth0 down Cuando una interfaz está deshabilitada el sistema no enviará ni recibirá tráfico por ella, incluso aunque tenga asignada una configuración IP. Una vez el sistema se acaba de iniciar podemos obtener una lista de las interfaces disponibles con el siguiente comando: $ ip link 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:ff:47:d0 brd ff:ff:ff:ff:ff:ff 3: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 08:00:27:ff:18:a6 brd ff:ff:ff:ff:ff:ff En este ejemplo podemos observar la interfaz de loopback (lo) siempre presente para comunicaciones internas del sistema, y dos interfaces físicas (eth0 y eth1). Para crear las interfaces virtuales o compuestas se usan distintos comandos en cada caso. Administración de interfaces bridge o puente 56 3. Routing En líneas generales el proceso de configuración consiste en crear una tabla de enrutamiento para cada interfaz WAN. En cada una de esas tablas se asigna como ruta por defecto la ruta hacia el gateway que tiene configurado la interfaz. $ ip route show table WAN1 default via 192.168.1.1 dev eth1 Para que el tráfico alcance dichas tablas se le asigna a cada una una regla para que los paquetes marcados con una marca específica vayan a dicha tabla $ ip rule 0: from all lookup local 1000: from all lookup main 1001: from all fwmark 0x1/0xff lookup WAN1 1002: from all fwmark 0x2/0xff lookup WAN2 1008: from all fwmark 0x3/0xff lookup WAN3 32767: from all lookup default Para hacer el marcado de los paquetes se usa el gateway que tienen asignado las reglas del Firewall. Así se marcan dichos paquetes con el ID del Gateway en cuestión: iptables –t mangle -I ROUTINGMARK -j RULE{ID} iptables –t mangle -A RULE{ID} -i {INTERFAZ} {MATCH} -j MARK --set-mark {ID_GATEWAY}/0x00ff En el caso de que el gateway sea un grupo de interfaces tendremos que convertir esa marca a la marca de la interfaz real por la que vamos a enrutar el paquete. Para ello se escriben reglas específicas para cada grupo de interfaces. Si es Failover la marca se convertirá en la marca de la interfaz activa. Si es Balancer se asignara una marca aleatoria entre todas las interfaces activas del grupo # Saltamos a la cadena del grupo si tiene su marca iptables –t mangle -A BALANCE -m mark --mark 0x{MARK_GROUP}/0xff -j GROUP{NAME_GROUP} # Si es Failover, cambiamos la marca por la de la interfaz activa iptables –t mangle -A GROUP{NAME_GROUP} -j MARK --set-mark 0x{MARK_INTERFACE_1}/0xff # Si es Balancer, aleatoriamente a una interfaz o a otra iptables –t mangle -A GROUP{NAME_GROUP} -m mark --mark 0x{MARK_GROUP}/0xff 57 -m statistic --mode random --probability 0.33 -j MARK --set-mark 0x{MARK_INTERFACE_1}/0xff iptables –t mangle -A GROUP{NAME_GROUP} -m mark --mark 0x{MARK_GROUP}/0xff -m statistic --mode random --probability 0.5 -j MARK --set-mark 0x{MARK_INTERFACE_2}/0xff iptables –t mangle -A GROUP{NAME_GROUP} -m mark --mark 0x{MARK_GROUP}/0xff -j MARK --set-mark 0x{MARK_INTERFACE_3}/0xff Para conseguir que todos los paquetes de una misma conexión tengan la misma marca de enrutamiento se realiza el marcado únicamente en el primer paquete de la conexión posteriormente se guarda dicha marca en el tracking de conexiones de Netfilter y se restablece cada vez que llega un paquete de la misma conexión. # Restablece marca de conexión. iptables -t mangle -A PREROUTING -j CONNMARK --restore-mark --nfmask 0x0000ffff # Si el paquete no tiene marca (es 0) lo manda a la cadena de marcado iptables -t mangle -A PREROUTING -m mark --mark 0x000000/0x000000ff -j ROUTINGMARK # Guardamos la marca a la conexión. iptables -t mangle -A PREROUTING -j CONNMARK --save-mark --nfmask 0x0000ffff 58 4. Calidad de Servicio (QoS) Para implementar la configuración se hace uso de las marcas de paquete que establece el Firewall (ya usadas también para enrutamiento). De esta manera tenemos dos partes, una el marcado de los paquetes al ser identificados y otra la de configuración de las colas y de sus reglas de clasificado del tráfico que repartan los paquetes según la marca que tengan. En cuanto a la configuración de colas se hace con los siguientes comandos: # Configuramos el nodo raíz HTB. DEV es el dispositivo y BW ancho de banda tc qdisc add dev DEV root handle 1: htb default 99 tc class add dev DEV parent 1: classid 1:1 htb rate BW kbit burst 15k # Para cada una de las colas se configura: # Crea la clase dentro del nodo raíz HTB: # ID_COLA es un identificador de la cola. # PRIORITY es la prioridad que tiene la cola. # BWMIN y BWMAX son los anchos de banda mínimos y máximos calculados tc class add dev DEV parent 1:1 classid 1:{ID_COLA}0 htb prio PRIORITY rate BWMIN kbit ceil BWMAX kbit burst 15 # Añadimos un nodo SFQ como hijo de la clase HTB tc qdisc add dev DEV parent 1:{ID_COLA}0 handle {ID_COLA}00: sfq perturb 10 # Y finalmente añadimos la regla que hará que los paquetes marcados se clasifiquen en la cola tc filter add dev DEV parent 1:0 prio 0 protocol ip handle 0x{ID_COLA}00/0xff00 fw flowid 1:{ID_COLA}0 Para el marcado de los paquetes se hará igual que en enrutamiento aunque usando una máscara distinta para tener marcas de enrutamiento y calidad de servicio diferenciadas. 59 5. VPN Como hemos dicho para implementar el servicio VPN se ha usado el software OpenVPN. En este punto se detallara cuáles son las configuraciones necesarias para que dicho software nos de la funcionalidad necesaria. En las configuraciones que requieran agregado de túneles haremos uso de las capacidades de agregación de interfaces (bonding) comentadas en el punto 4.1. En todos los casos tendremos que tener muy clara la distinción entre direcciones internas del túnel y las direcciones y puertos que permiten que la conexión UDP o TCP subyacente al túnel pueda ser establecida. Estas últimas serán necesarias en todos los casos. Según las explicaciones anteriores podemos clasificar los tipos de configuraciones que hay que implementar como:  Acceso múltiple: Servidor.  Acceso múltiple: Cliente.  Extremo a extremo: Una interfaz local, una dirección remota.  Extremos a extremo: Múltiples direcciones remotas y locales. Para los dos primeros casos de acceso múltiple usaremos las siguientes platillas para configurar OpenVPN: # Servidor para múltiples clientes local IP_LOCAL # Dirección IP local en la que escucha el túnel port 1194 # Puerto en el que escucha proto udp # Protocolo del túnel dev tunserver-adsl # Dispositivo virtual que creará server 10.6.0.0 255.255.255.0 # Rango de direcciones que asignará a # los clientes # Certificados ca /env/firewall/etc/openvpn/server-adsl-ca.crt cert /env/firewall/etc/openvpn/server-adsl-cert.crt key /env/firewall/etc/openvpn/server-adsl-cert.key dh /env/firewall/etc/openvpn/server-adsl-cert.dh # Rutas locales accesibles para los clientes push "route 10.1.1.0 255.255.255.0" Para los casos de configuraciones extremo a extremo tendremos el caso básico en el que únicamente queremos establecer un túnel entre una IP local y otra IP remota. Para este caso nos basaremos en esta plantilla: local 192.168.1.200 # Dirección IP local en la que escucha el túnel remote 199.180.255.14 # Dirección IP remota del túnel lport 502 # Puerto del extremo local del túnel 60 rport 502 # Puerto del extremo remote del túnel proto udp # Protocolo de la conexión dev tapusabr # Dispositivo virtual secret /env/firewall/etc/openvpn/usabr.key # Clave de cifrado En el caso de múltiples interfaces locales y/o múltiples direcciones remotas será necesaria una configuración agregada. En decir, en este caso vamos a tener múltiples instancias de OpenVPN cada una con su configuración y su dispositivo virtual. Para agregar esos túneles intermedios crearemos una interfaz bonding a la que añadiremos todos esos dispositivos virtuales como esclavos. De esta manera conseguimos que la interfaz bonding se convierta de forma transparente para el resto del sistema en el extremo del túnel agregado. Figura 30: Enlaces generados en una VPN agregada A la hora de configurar es necesario hacer una asignación de puertos para cada uno de los enlaces ya que vamos a tener varias conexiones sobre una misma IP lo que hace imposible que todas usen el mismo rango de puertos. Esto se ha solucionado estableciendo el puerto de inicio en la configuración y automáticamente se hace una asignación en función del número de enlaces necesarios (ver figura 30). La configuración de las interfaces bonding se realiza como en el punto 4.1.3 y la única diferencia será que aquí configuraremos la monitorización ARP que proporciona el driver de bonding para que los sub-túneles inoperativos sean excluidos al distribuir el tráfico: # Añadimos el dispositivo “vpnbond” como bonding echo +vpnbond > /sys/class/net/bonding_masters # Configuramos la monitorización ARP con la ip del extremo del túnel echo 1000 > /sys/class/net/vpnbond/bonding/arp_interval echo +10.8.1.2 > /sys/class/net/vpnbond/bonding/arp_ip_target Para cada sub-túnel se realiza la configuración como en el caso simple con los puertos asignados a cada uno de ellos como se ha explicado anteriormente. 61 Estas configuraciones se basan en el estado de conectividad de las interfaces en el momento de configuración, pero es necesaria una configuración dinámica atendiendo al estado de conectividad. Las configuraciones son regeneradas cuando una de las interfaces del sistema pierde la conexión o la recupera. Aquí es donde entra la monitorización de interfaces explicada en el punto 4.9.2. Cuando una interfaz pierde o recupera la conexión se generan un evento que el servicio VPN intercepta para comprobar si la configuración de los túneles es la adecuada o se necesitan hacer cambios. Será necesario regenerar la configuración en los casos de túneles que tengan asignada más de una interfaz de enrutamiento y funcionen en modo failover, ya que la interfaz por la que estaban configurados ha podido perder la conectividad o por el contrario una interfaz con más prioridad que la actual ha recuperado la conectividad. 62 6. Control de navegación web Partiendo de los datos de configuración en base de datos vamos a tener que el servicio de Proxy puede prestar servicio a 1 o más interfaces de red y pudiendo ser diferente el tipo de funcionamiento para cada interfaz. Es decir, podemos tener dos interfaces LAN, una funcionando en modo intercepción y otra en modo normal con autenticación. Para conseguir este comportamiento se ha usado los ACL (Access Control List) que proporciona Squid. De esta manera configuraremos el servicio y luego diremos qué condiciones se deben cumplir desde cada rango de direcciones (cada LAN) desde las que llegan peticiones. El fichero de configuración quedaría así: # Configuraciones fijas acl all src all acl localhost src 127.0.0.1 follow_x_forwarded_for allow localhost access_log LOG_FILE squid pid_filename PID_FILE # Configuración de la autenticación, se crea el ACL "auth" # que se usara en las LAN que lo requieran auth_param basic program /usr/lib/squid/ncsa_auth USERS_FILE acl auth proxy_auth REQUIRED # Para cada LAN creamos un acl con su rango de IPs acl LAN1 src 10.1.1.0/24 acl LAN2 src 10.1.2.0/24 # Modo de acceso para cada LAN http_access allow LAN1 http_access allow LAN2 auth # Puerto en el que escucha el proxy # y habilitar modo transparente o intercepción http_port 127.0.0.1:3128 transparent Adicionalmente si el modo de funcionamiento es intercepción tendremos que configurar una regla en el Firewall para redirigir a Squid todo el tráfico con destino al puerto 80 iptables -t nat -A PROXY -i DEVICE_LAN -p tcp --dport 80 -j REDIRECT -- to-ports 3128 63 7. DHCP y DNS Como hemos dicho anteriormente, Dnsmasq proporciona todos estos servicios mediante un único proceso y su configuración. Por tanto la configuración del servicio consistirá en generar dicho fichero y lanzar el proceso. A continuación se van a detallar el formato y contenido del fichero de configuración. Cada línea del fichero representa una opción de configuración. Una parte del fichero son opciones fijas y otras son generadas consultando el contenido de la base de datos definido en el punto anterior. bind-interfaces domain=home no-resolv localise-queries dhcp-leasefile=/env/firewall/run/dnsmasq.leases dhcp-script=/opt/firewall/backend/bin/dhcp-event server=8.8.8.8 server=8.8.4.4 interface=br0 dhcp-range=br0,10.1.1.100,10.1.1.199,3600 dhcp-host=a0:0b:ba:a8:b3:cd,10.1.1.120,pc1 dhcp-host=c8:df:7c:09:29:a3,10.1.1.121