DESARROLLO DE UN PORTAL CAUTIVO Y HERRAMIENTAS DE ADMINISTRACIÓN EN UN ENTORNO WI-FI ABIERTO

Transcripción

1 DESARROLLO DE UN PORTAL CAUTIVO Y HERRAMIENTAS DE ADMINISTRACIÓN EN UN ENTORNO WI-FI ABIERTO Memoria del proyecto de Ingeniería Técnica en Informática de Sistemas Realizado por Alberto Moral Gómez Y dirigido por David Megías Jiménez Escuela Universitaria de Informática Sabadell, junio de

2

3

4

5 El firmante, David Megías Jiménez, Profesor de la Escuela de Ingeniería de la UAB, CERTIFICA: Que el trabajo al que corresponde la presente memoria ha sido realizado bajo su dirección por Alberto Moral Gómez Y para que conste firma la presente. Sabadell, junio de Firmado: David Megías Jiménez i

6

7 Resumen Aunque estemos en el siglo XXI todavía hay zonas geográficas donde conectarse a Internet es imposible, debido a que la línea de ADSL de las compañías no llega a todas las partes de Cataluña (en Cataluña o cualquier otro territorio). Es por ese motivo por el que se ha creado una nueva topología de red. Ya hay más de nodos esparcidos por Cataluña, sobretodo, ubicados en zonas cuyo acceso al ADSL es nulo: pueblos, casas aisladas en la montaña, etc. En este proyecto queremos que todos los usuarios que se conecten a nuestro nodo tengan la oportunidad de navegar por Internet. Por eso se han ido interconectando estos nodos, de este modo todos estos usuarios afectados puedan crear una red con una infraestructura más dinámica y navegar por Internet, algunos compartiendo su conexión a Internet y otros que no pueden tener una línea de ADSL ir interconectándose con los nodos para llegar a un nodo con conexión. Aparte de crear el sistema operativo para que esto sea posible, se ha creado un portal para informar al usuario y dar mayor ayuda a los usuarios que tienen un nodo y no saben cómo utilizarlo. Para ello se ha creado un manual. Todos estos pasos se explican detalladamente a continuación; mostrando desde el montaje de un nodo hasta su correcto funcionamiento. iii

8

9 Tabla de Contenidos Resumen Tabla de Contenidos iii v Capítulo 1: Introducción Presentación Estado del arte Objetivos Organización de la memoria 3 Capítulo 2: Análisis del sistema Actual Introducción a las redes mesh Esquema clásico Esquema mesh /ad-hoc Servicio de conexión a Internet Estudio de Viabilidad Introducción Estudio de la situación actual Requisitos del proyecto Alternativas y selección de la solución Planificación Evaluación de riesgos Presupuesto Montaje del nodo 20 Capítulo 3: Diseño del sistema Análisis de requerimientos Requerimientos previos Requerimientos funcionales Requerimientos no funcionales Descripción de la plataforma Introducción Sistema operativo Directorios Iptables Wifidog Estructura 33 v

10 Capítulo 4: Implementación Introducción Estructura Página principal Administrador 36 Capítulo 5: Mantenimiento y pruebas 45 Capítulo 6: Conclusiones Conclusiones globales Ampliaciones 49 Bibliografía 49 Agradecimientos 51 Anexo A: Creación del firmware 53

11 Introducción 1. Introducción 1.1. Presentación Este proyecto se basa en la creación de un portal cautivo en un S.O. que funciona en dispositivos empotrados. Este S.O. se llama OpenWRT, que configurado correctamente proporciona una conectividad inalámbrica Wi-Fi bajo el estándar El firmware se implementa en OpenWRT, distribución de GNU/Linux para dispositivos empotrados, que junto a unos protocolos de encaminamiento y otras utilidades se pueden conectar a una red mesh como las de guifi.net o graciasensefils. La versión de OpenWRT que se utiliza es la Kamikaze Aunque no es la más reciente, goza de la ventaja de haber sido probada y mejorada por los usuarios. Por lo tanto, no es extraño que proporcione proporciona mayor fiabilidad. Una vez creada la base del firmware con los paquetes necesarios para su correcto funcionamiento se ejecutará Wifidog, éste es un paquete de Kamikaze que se utiliza para bloquear el tráfico a Internet hasta que un usuario se autentifique en un servidor. Guifi.net da acceso a Internet de una forma libre, por lo tanto un objetivo básico es que los usuarios no tengan que autenticarse. Debido a esto se ha buscado otra forma para no tener que registrarse. De esta manera a un usuario le aparece el portal cautivo y sólo tiene que leer una normativa, y si está de acuerdo, sólo debe pulsar un botón. Antes de esto, el usuario tiene la opción para entrar a la página de guifi.net e informarse de todo su contenido con mayor detalle. A medida que los usuarios se conectan al nodo, se va guardando información útil para luego poder generar ficheros con datos posteriormente, con la finalidad de ayudar al administrador facilitándole información de lo que ocurre en su nodo. 1

12 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto 1.2. Estado del arte Actualmente guifi.net posee un portal cautivo desarrollado con el paquete Squid, pero desde un principio siempre quisieron utilizar Wifidog. Sin embargo, no consiguieron ejecutarlo correctamente y decidieron buscar otra alternativa. El portal actual sólo posee un texto de bienvenida y un botón para aceptar su conexión y navegar por Internet. Figura 1.1 portal cautivo de graciasensefils [ Como se puede observar no hay posibilidad para cambiar el mensaje del nodo, ni subir fotos, ni tener un control del nodo de una manera eficaz, etc. Es esa la razón por la que en el proyecto se han desarrollado todas estas funciones para que el propietario del nodo, al ofrecer su conexión a Internet a otros usuarios pueda dar a conocer su negocio subiendo fotos y comentarios para hacer publicidad de su negocio. También los usuarios que no poseen conocimientos sobre GNU/Linux o redes en la sección del administrador se les han asignado comandos para ir monitorizando lo que ocurre en su nodo, todo con una explicación y un manual en formato pdf Objetivos El objetivo principal es que los usuarios que se conecten al nodo se les aparezcan un portal cautivo, bloqueando todo tipo de conexión hasta que no se acepte una normativa. Una vez aceptado el usuario podrá navegar libremente, con todos los puertos necesarios abiertos y sin ningún tipo de restricción. Pasado cierto 2

13 Introducción tiempo el portal volverá a recordar a los usuarios que están utilizando esa conexión gracias a guifi.net. Como todos los usuarios que se conectan al nodo son anónimos, no necesitan dejar ningún tipo de identificación, por eso cada vez que un usuario se conecte al nodo se generará un registro donde se guardaran la dirección IP y hora de cada usuario, para llevar un control y generar informes para el administrador. El administrador tendrá su propio espacio en el portal cautivo, dónde podrá autenticarse como tal y ver el funcionamiento del nodo, subir archivos al servidor, modificar una pequeña parte del portal o ejecutar algún comando para monitorizar el nodo. Otra parte consiste en el montaje de un nodo, con todos los componentes necesarios para proporcionar una conexión Wi-Fi Organización de la memoria La memoria se ha estructurado en seis capítulos: Inicialmente, se ha elaborado un resumen donde se explica de qué consta el proyecto y seguido de la tabla de contenidos. A continuación está el primer capítulo, una introducción sobre la base del proyecto, y los objetivos a cumplir. El segundo capítulo contiene una pequeña introducción sobre el funcionamiento del tipo de red utilizada, un estudio de viabilidad, y para acabar fotos de los componentes del nodo y su correcto montaje para luego instalarlo en un tejado. En el tercer capítulo, se explican los requerimientos del proyecto y conocimientos básicos: el sistema operativo utilizado, teoría para comprender mejor el funcionamiento del portal y, por último, cómo se han estructurado las páginas Web en el servidor. En el cuarto capítulo se explica cómo se han desarrollado las páginas Web para que el usuario pueda utilizar comandos y obtener información de lo que ocurre en su nodo y también códigos en PHP con la finalidad de modificar el portal. El quinto capítulo describe las pruebas y el mantenimiento del nodo, se utiliza un programa que intercepta paquetes para verificar que el portal cautivo funciona correctamente. 3

14 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto El último capítulo resume las conclusiones extraídas a lo largo de todo el proyecto. Finalmente, se detalla la bibliografía donde se describirán todas las fuentes utilizadas y para acabar, la última sección, la de agradecimientos. 4

15 Análisis del sistema actual 2. Análisis del sistema actual 2.1 Introducción a las redes mesh Esquema clásico El método clásico de red es una topología estrellada con infraestructura [5]. Es el caso de la figura 2.1, dónde todos los nodos están conectados directamente a un punto central y todas las comunicaciones se han de realizar a través de este supernodo, el cual puede comunicarse con otro abarcando grandes distancias. Figura 2.1 Esquema clásico Los nodos de esta red, no interactúan directamente entre sí, sino que deben conectar primero con el nodo en modo máster, que es el que distribuirá las solicitudes a los otros nodos. Inconvenientes: Si falla el nodo en modo máster, se desconectaría esa rama de la red, dejando los nodos totalmente incomunicados, figura 2.2. Figura 2.2 Fallo en el esquema clásico 5

16 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto Esquema mesh / ad-hoc Esta topología combinada con unos protocolos de encaminamiento, nos proporciona más estabilidad porque un nodo se conecta con todos los que tenga a su alrededor, siempre que esté a su alcance, figura 2.3. Figura 2.3 Red mesh Si tuviéramos un fallo entre los nodos, los protocolos de encaminamiento se encargarían de buscar un nuevo camino hacia el destino. Figura 2.4. Figura 2.4 Fallo en red mesh La red en modo ad-hoc no tiene un nodo central, por lo tanto todos los nodos están en igualdad de condiciones. Con la posibilidad de buscar varios caminos alternativos en caso de error. 6

17 Análisis del sistema actual Servicio de conexión a Internet Los nodos configurados como proveedores de Internet, al tener una conexión directa, por defecto utilizan esta conexión para acceder a Internet [4], como muestra la figura 2.5. Los nodos que no tienen proveedor de Internet lo que hacen es buscar un camino hasta los nodos proveedores, puede haber caminos alternativos, pero siempre se escogerá el mejor (los protocolos de encaminamiento se encargan de ello), figura 2.6. Figura 2.5 Proveedor de Internet Figura 2.6 Ruta alternativa Estos nodos que están configurados como proveedores de Internet comprueban constantemente la conexión directa a Internet, para saber si hay fallos o no. En caso de perder la conexión directa a Internet el nodo que estaba configurado como proveedor de Internet deja de serlo y busca a otro candidato, hasta que no recupera su conexión directa otra vez. Todo este procedimiento es transparente para el usuario. Como ya he mencionado anteriormente, los protocolos de encaminamiento se encargan de buscar el mejor camino hacia Internet. Se ha utilizado una aplicación para este tipo de red, que en cuanto un usuario se conecta aparezca un portal cautivo que avisa de una normativa que puede ser aceptada para que los usuarios puedan navegar libremente, utilizando todas las ventajas de la red mesh. 7

18 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto 2.2 Estudio de viabilidad Introducción Tipología: Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto Descripción: El proyecto a realizar irá destinado exclusivamente a aquellos nodos que utilizan distribuciones de OpenWRT basado en GNU/Linux. Éstos se utilizan por guifi.net para dar acceso a una red mesh. La función principal del proyectista es crear un portal cautivo incluyendo el correcto montaje de un nodo para que los usuarios puedan conectarse a él y compartir una conexión a Internet. OpenWRT ya posee varios paquetes que podrían hacer de portal cautivo, pero se alejan de los objetivos finales, como la utilización de bases de datos para almacenar usuarios con contraseña. Sin embargo esto cargaría demasiado al nodo y no cumpliría los objetivos del proyecto Objetivos del proyecto: Los objetivos que son expuestos van de mayor prioridad a menor: Ofrecer una interfaz para el portal cautivo. Autenticar al propietario del nodo. Visualizar una parte estática que se muestre en todos los nodos. Monitorizar actividades que se ejecutan en el nodo. Monitorizar a los usuarios conectados en el nodo. Parte dinámica que pueda ir cambiando el propietario del nodo. Subir imágenes con comentarios. Permitir acceso a la página de guifi.net para dar más información. Dividir el portal en un mensaje, parte modificable, y un menú. Montaje del nodo. 8

19 Análisis del sistema actual Definiciones, acrónimos y abreviaciones Host: Ordenador que funciona como el punto de inicio o final de las transferencias de datos. Ad-Hoc: Red inalámbrica descentralizada. Nodo: Es un router que se conecta con otros formando una red mesh. S.O.: Sistema operativo. Shell Script: Lenguaje de programación que en este proyecto se utiliza para interactuar con el servidor y obtener datos de él Partes interesadas Perfiles de usuario Perfil Administrador del nodo Usuario Responsabilidad Podrá acceder al portal cautivo mediante autenticación y podrá modificar su interfaz Web, y también monitorizar desde los usuarios conectados al nodo hasta los procesos ejecutados en él. El usuario sólo podrá ver el mensaje de bienvenida del portal cautivo y el mensaje del propietario del nodo. Equipo de proyecto Descripción Analista Programador Técnico de pruebas Técnico de hardware Director del proyecto Responsabilidad Colabora con el Director de proyectos en el estudio de viabilidad i la planificación del proyecto. Diseña y desarrolla la aplicación de acuerdo con el análisis y planificación prevista. Realiza las pruebas del software y participa en el control de calidad. Montaje un nodo. Supervisa el trabajo del proyectista 9

20 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto Estudio de la situación actual Contexto La red mesh es una red ad-hoc descentralizada, por lo tanto, cada nodo puede reenviar los datos a los demás y la decisión de que nodos envían a los demás se crea de forma dinámica gracias a los protocolos de encaminamiento. Difiere de las redes inalámbricas convencionales. En la figura 2.7 se observa que todos los nodos de color rojo, están conectados entre sí. Si un nodo dejara de funcionar, se calcularía otra ruta para contactar con el destino al que se quiera llegar. El nodo de color negro está tan separado de los demás que no puede comunicarse con ellos, por lo tanto ese nodo no puede acceder a ninguno. Figura 2.7 Ejemplo nodos conectados Son conexiones inalámbricas por lo tanto los nodos deben situarse en puntos elevados, lo más altos posibles como tejados, chimeneas, etc. Una buena colocación proporcionará una mejor recepción de la señal, hecho que conlleva a una mayor calidad en la conexión Desarrollo del proyectista Guifi.net ya dispone de un portal cautivo, pero sólo muestra un mensaje de bienvenida, una simple página en HTML. Sin embargo, lo que se pretende es que el usuario tenga cuatro partes bien diferenciadas cuando visualice el portal cautivo: La primera parte será estática. Todo host cuando se conecte al nodo verá un mensaje, por ejemplo Bienvenido a la red guifi.net. Este mensaje será común para todos los nodos.

21 Análisis del sistema actual La segunda parte será dinámica. El propietario del nodo podrá modificar el portal cautivo, poniendo texto y fotos con comentarios. Así cuando los usuarios se conecten a ese nodo podrán ver la publicidad o el texto redactado del administrador. La tercera parte es un menú bastante simple pero que proporciona información tanto a los usuarios como al administrador. La cuarta parte será un espacio reservado para el administrador con herramientas de administración y monitorización del nodo Usuario y/o personal del sistema Perfil Administrador del nodo Usuario Responsabilidad Podrá acceder al portal cautivo mediante autenticación y podrá modificar su interfaz web, y también monitorizar desde los usuarios conectados al nodo hasta los procesos ejecutados en él. El usuario sólo podrá ver el mensaje de bienvenida del portal cautivo y el mensaje del propietario del nodo Diagnóstico del sistema o Deficiencias El portal cautivo es muy simple visualmente. No se puede modificar ni subir fotos. No distingue entre administrador y usuario. No se obtiene información del nodo. No hay ningún control sobre los usuarios conectados al nodo. 11

22 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto o Mejoras Aspecto más atractivo Posibilidad de ser modificado. Enlace con página de guifi.net Espacio para el administrador Monitorización del nodo Información sobre los usuarios conectados al nodo. Herramientas de administración Requisitos del proyecto Requisitos funcionales (RF): 1 Visualización portal cautivo 2 Autenticación por parte del usuario del nodo 3 Visualización de un mensaje de bienvenida 4 Monitorización de actividades/usuarios en el nodo 5 Modificación del portal con capacidad para soportar imágenes 6 Conexión externa con guifi.net para obtener mayor información 7 Estructuración del portal 8 Montaje del nodo Requisitos no funcionales (RNF): 1 Rendimiento del sistema 2 Disponibilidad de servidor 3 Calidad de imagen 4 Eficiencia 5 Soporte 6 Necesidad de recursos 7 Velocidad de carga del portal 12

23 Análisis del sistema actual Restricciones 1 La aplicación se ha implementado utilizando software libre. 2 El proyecto ha de estar finalizado antes del 30 de Junio. 3 El portal cautivo puede que no funcione en todos los nodos. Puede necesitar que se instalen algunos paquetes que no posee Catalogación y priorización de los requisitos funcionales (RF) Esencial X X X Condicional X X X Opcional X X Catalogación y priorización de los requisitos no funcionales (RNF) Esencial X X X Condicional X X X Opcional X Alternativas y selección de la solución El desarrollo del proyectista se hará basándose en un paquete: Wifidog que es compatible con Kamikaze , en caso de no tener éxito se buscarían soluciones como: Alternativa 1: Si el paquete de Wifidog no es compatible con Kamikaze, se implementaría en otra versión llamada WhiteRussian, ésta es una versión más antigua y más testeada por los usuarios. Alternativa 2: Crear un servidor con el paquete Lighttpd, servidor muy completo que destaca por su rapidez, y con algún lenguaje de programación bloquear todo tipo de conexiones. 13

24 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto Alternativa 3: Se utilizaría otro paquete que incorpora GNU/Linux, llamado Squid, el cual posee un Proxy caché para dar mayor velocidad a la hora de re direccionar páginas Planificación del proyecto Antes de todo, es necesario explicar que este proyecto tiene un desarrollo evolutivo, es decir, el proyectista tiene una ligera idea de los requerimientos, pero no todos son conocidos al inicio del proyecto. Esto implica que requiere un especial cuidado en la manipulación de documentos, códigos de ejecución, etc. Cada cambio en el proyecto debe ser registrado para que los documentos sean fácilmente recuperables, todo esto dependiendo de la fase Planificación Calendario del proyecto: el proyecto se desarrollará de octubre del 2009 hasta el 29 de Junio del 2010 Fecha de comienzo: 1 de Octubre del 2009 Fecha de finalización: 20 de Junio del 2010 Herramientas de planificación: Microsoft Project 2007 (Diagramas de Gantt) Recursos del proyecto Recursos humanos Jefe de proyecto Programador Analista Técnico de pruebas Reuniones con la comunidad Técnico de hardware Valoración 40 /h 20 /h 0 /h 14

25 Análisis del sistema actual Planificación del proyecto con MSProject # Tarea Duración 1 Estudio y documentación guifi.net 25 2 Documentación Portales cautivos 32 3 Estudio y documentación Ubuntu 30 4 Reuniones con la comunidad 12 5 Estudio de viabilidad 15 6 Aprobación del estudio de viabilidad 2 7 Análisis de requisitos 20 8 Montaje del nodo 5 9 Creación del portal cautivo 10 - Base del firmware instalada Descargar paquete Wifidog Configuración Wifidog Creación página Splash Creación del nuevo firmware 3 15 Realización pruebas Finalización memoria 5 Duración Total de la planificación

26 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto Planificación Diagrama de Gantt Figura 2.8 Diagramas de Gantt Figura 2.9 Diagramas de Gantt 16

27 Análisis del sistema actual Evaluación de riesgos Riesgos R1. Planificación temporal optimista: no se acaba en la fecha prevista, los recursos aumentan y por lo tanto el coste sería mayor. R2. Falta alguna tarea: volver a reconstruir la planificación, retraso en el proyecto. R3. Cambio de requisitos: retraso en el proyecto. R4. Posibilidad de que los nodos se averíen: volver a comprar otros, aumento de presupuesto. R5. Diferentes versiones de los nodos: puede que el software desarrollado sólo funcione en unos nodos con un firmware específico. R6. Abandonar el proyecto antes de su finalización: no se cumplen los objetivos, frustración por parte del proyectista Medidas R1. Afrontar que no se acabará en ese período y asumir que habrá pérdidas. R2. Modificar el estudio de viabilidad en el apartado de planificación y asumir que podría variar el presupuesto. R3. Modificar el estudio de viabilidad en el apartado de planificación y asumir que podría variar el presupuesto. R4. Comprar otros nuevos, aumento del presupuesto del proyecto. R5. Documentarse de los tipos de nodos que hay y mirar de instalar los paquetes necesarios para que el software desarrollado funcione. R6. No tiene solución. 17

28 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto Presupuesto Estimación coste de personal Personal Horas Coste Proyectista* * El proyectista a lo largo del proyecto realizará funciones de analista, programador, realizador de pruebas y técnico de hardware Estimación coste de recursos Coste amortización Coste Periodo amortización Periodo utilización PC m 9 m VMware m 9 m Ubuntu * * * * OpenOffice.org * * * * MSProject m 9 m * Es gratuito TOTAL = 547,5 El proyectista incluye cada componente que tiene un nodo con su respectivo precio [11]: MATERIAL Cantidad Precio PC- engines ALIX 2D2 LX800 2 LAN 2 MPCI ,80 MB USB Fuente de alimentación 18 v. 0,8 A (15 W) 1 5,93 Compex WLM54SAG AGB 200mW ,40 Mb/s Pigtail 5 GHz UFL-N Jack Bulkhead 30 cm 2 5,19 18

29 Análisis del sistema actual MATERIAL Cantidad Precio Antena Dipolo DUAL 5/2,4 Ghz 7 dbi Connector N 2 22,28 Macho Caja Universal IP65 ABS con conector RJ ,40 incluido CompactFlash Transcend TS2GCF133 (4GB) 1 15,5 Total* 233,37 I.V.A ( 16% ) 37,34 Total Presupuesto Nodo 270,71 TOTAL= 270, Resumen del presupuesto Coste del desarrollo del proyecto Coste de amortización del material ,6 TOTAL 6.757,6 19

30 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto 2.3 Montaje del nodo En esta sección se detalla de qué componentes está formado el nodo y como montar uno en pasos muy reducidos para más tarde instalarlo en el hogar. Componentes: 1xCaja estanca 1xPlaca Alix c2c 2xMini-PCI 1xTarjeta CompactFlash 2xPigtails 2xAntenas Caja estanca En la caja donde irán todos los componentes electrónicos del nodo, se tiene que hacer tres agujeros, dos para la colocación de las antenas, y otro para la salida de la corriente y cable Ethernet (Algunos nodos no necesitan cable de corriente ya que se alimentan directamente por el de Ethernet utilizando PoE). Alix c2c con las Mini-PCI Figura 2.10 Placa Alix 20

31 Análisis del sistema actual Conectamos en la placa las 2 Mini-PCI. De cada Mini-PCI se le conectará un pigtail que irá conectado a la base de una antena. Es decir un Mini-PCI para la antena de 2,4 Ghz y otra mini-pci para la antena de 5 Ghz conectados mediante los pigtails. Una vez hecho esto se mete la placa en la caja y se atornilla en los extremos para inmovilizarla. Insertamos la CompactFlash con nuestro sistema operativo en la única ranura posible, en la figura 2.10 se observa que está en la parte superior derecha. Se conecta el cable RJ-45 y el de corriente (si fuera necesario) y se extraen por el tercer agujero hecho en la caja, una vez sacados se cierra presionando bien los tornillos para que encaje perfectamente. Recordamos que la caja estará al aire libre sufriendo todo tipo de condiciones atmosféricas. Finalmente se subiría el nodo al tejado con un cable RJ-45 lo suficientemente largo para que llegue al interior del hogar, figura Se colocará el nodo en una zona lo más elevada posible para tener una mejor conexión con los nodos vecinos, figura Figura 2.11 Montaje del nodo Figura 2.12 Colocación del nodo 21

32 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto 22

33 Diseño del sistema 3. Diseño del sistema 3.1 Análisis de requerimientos En esta sección se tratarán y analizarán los requerimientos, tanto desde la creación del firmware como del correcto funcionamiento del paquete Wifidog. Estos requerimientos pueden variar, debido a los rápidos cambios de las versiones de Kamikaze. Es posible que el paquete de éste no funcione en según qué versiones, o que el paquete descargado no sea el idóneo para la arquitectura del nodo Requerimientos previos El proyectista empezará a explicar estos requerimientos, ya que si no se cumplieran no funcionaría Wifidog, por lo tanto se han de seguir ciertos pasos para compilar el firmware. RP1: Compilador Es necesario tener una máquina que sea capaz de compilar el firmware. Se utilizará una máquina virtual en un ordenador, con el S.O. Ubuntu, que posee todo lo necesario para compilar con éxito el firmware. Para que funcione el compilador tiene que haber una serie de paquetes instalados en el sistema, de no ser así se tienen que descargar e instalar. RP2: Acceso a Internet Al generar el firmware con los paquetes que hayamos seleccionado en el make menuconfig, tendrá que acceder a Internet para podérselos descargar e incluir en el firmware. RP3: Grabador CompactFlash Una vez finalizado el proceso del firmware, el proyectista tendrá que copiar la imagen generada durante la compilación en la CompactFlash. 23

34 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto RP4: Paquetes Uno de los paquetes esenciales es Wifidog. Éste es un paquete que podemos encontrar en el repositorio de Kamikaze concretamente el de la versión Para poder utilizar Wifidog, primero deberemos instalar una serie de paquetes: IPTABLES IPTABLES MOD CONNTRACK IPTABLES MOD EXTRA IPTABLES MOD IPOPT IPTABLES MOD NAT IPTABLES MOD NAT EXTRA KMOD IPIP x86-1 KMOD IPT CONNTRACK x86-1 KMOD IPT CORE x86-1 KMOD IPT EXTRA X86-1 KMOD IPT IPOPT X86-1 KMOD IPT NAT EXTRA X86-1 KMOD IPT NATHELPER X86-1 OPKG (Paquete que permitirá instalar y actualizar paquetes en el sistema) PHP (Utilidad para poder ejecutar código PHP en las páginas del servidor, fichero que ha de ser configurado) WIFIDOG (Paquete para anular todo tipo de tráfico a los usuarios que se conecten al nodo) VI (Editor de textos) 24

35 Diseño del sistema Requerimientos funcionales RF1: Visualización portal cautivo Este requerimiento es prioritario a todos los demás, es la base para que el proyecto tenga éxito y se puedan cumplir los demás objetivos. En esta página aparecerá un botón donde el usuario, después de leer la normativa, podrá aceptar para navegar libremente por Internet. RF2: Autenticación por parte del propietario del nodo El propietario del nodo tendrá un usuario y contraseña dónde podrá acceder a la información del nodo, usuarios conectados, gráficas, estadísticas, monitorización del correcto funcionamiento de los protocolos y más herramientas. RF3: Monitorización de actividades/usuarios en el nodo Una sección importante del portal, es que el propietario del nodo podrá extraer información de los usuarios conectados a él. También podrá monitorizar los procesos que se están ejecutando en el nodo y ejecutar comandos para informarse sobre las interfaces activas, calidad de la señal Wi-Fi, etc. RF4: Modificación del portal Una vez identificado el propietario del nodo, podrá subir fotos y distribuir su página a convenir, por ejemplo si el propietario del nodo tiene un bar, podrá poner el menú del día, la carta con sus precios, horarios de apertura, etc. 25

36 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto RF5: Conexión externa con guifi.net para obtener mayor información En el portal cautivo se hallará cierta información sobre la red de guifi.net, pero en una versión muy reducida, por eso se da la posibilidad de que los usuarios puedan acceder a todo el contenido de la página de guifi.net. RF6: Estructuración del portal El portal cautivo estará dividido por tres partes. Cada sección tendrá una finalidad distinta, un menú, una normativa que será igual en cada nodo y el mensaje del propietario del nodo Requerimientos no funcionales RNF1: Rendimiento del sistema Se calcula que el número de personas que se conecten al nodo sea de aproximadamente veinte personas. Un número superior podría influir en el rendimiento del sistema y ralentizar el nodo. RNF2: Disponibilidad del servidor Si el servidor de guifi.net no está disponible por mantenimiento, cambio de web, etc., el usuario no podrá acceder para informarse. RNF3: Calidad imagen El nodo tiene espacio limitado, en el caso del proyectista una CompactFlash de 4 Gb, para asegurarnos de tener espacio en un futuro se recomienda subir imágenes lo más pequeñas posibles ya que así tardarán menos en cargarse y ocuparán menos espacio. 26

37 Diseño del sistema RNF4: Eficiencia Dado el poco conocimiento previo, se intentará hacer que funcionen los objetivos prioritarios aunque tengan consecuencias en el rendimiento, como por ejemplo mucha carga en CPU o uso de memoria excesivo. RNF5: Soporte En caso de algún tipo de duda o problema, el usuario deberá ponerse en contacto vía con algún técnico de guifi.net o en el foro de guifi.net. La respuesta puede demorarse. RNF6: Necesidad de recursos Los nodos tienen poca capacidad de almacenamiento, memoria, etc. Por lo tanto se tendrán que optimizar, reduciendo imágenes para que ocupen menos espacio, permitir que el propietario del nodo tenga informes del consumo de cada usuario, por si alguno tiene un uso demasiado elevado, etc. RNF7: Velocidad de carga del portal Si el usuario no respeta unas pautas, como tener un tamaño reducido en la calidad de las imágenes puede que el tiempo de carga del portal sea excesivo. 3.2 Descripción de la plataforma Introducción Se ha estructurado este apartado en varias partes para que se pueda ir asimilando poco a poco todo el proyecto. Hay desde una pequeña explicación del sistema operativo donde se ha implementado el proyecto hasta un fragmento donde se especifica cómo están distribuidas las páginas del portal cautivo. 27

38 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto Sistema Operativo Se ha desarrollado su proyecto en un sistema operativo distribuido por GNU/Linux y que se utiliza en dispositivos empotrados [7]. En este caso, un router. OpenWRT no tiene interfaz gráfica, es decir, sólo se puede utilizar la línea de comandos, lo que conlleva a tener un dominio básico del sistema operativo. OpenWRT posee 2 versiones: WhiteRussian y Kamikaze, ésta última ha sido la elegida ya que es la más reciente, pero tiene un inconveniente, ya que cada cierto tiempo se va actualizando puede que no funcionen los paquetes de otras versiones. Tiene licencia GPL, por ello se pueden encontrar diferentes versiones ya que los usuarios pueden modificar archivos del propio S.O. e instalar los paquetes que crean necesarios. Al ser distribuido por GNU/Linux tiene comandos muy similares, pero no iguales, ya que al ser más ligero el S.O. los comandos no tienen todas las funciones. Por ejemplo, el comando grep si lo ejecutamos en el nodo, nos aparece las opciones de la figura 3.1, pero si lo ponemos en una versión de GNU/Linux para dispositivos que no son empotrados nos salen tres veces más de opciones para poder utilizar. Figura 3.1 Captura opciones del comando grep en Kamikaze Siempre se ha tenido en cuenta todos los comandos del nodo, ya que pueden funcionar en una versión de GNU/Linux, y luego al pasar el código al nodo, no funcionar. 28

39 Diseño del sistema Directorios Los directorios que tiene son similares que en Linux [1], pero destacaremos dos. En éstos se hallan los archivos más importantes para el correcto funcionamiento del proyecto. /etc Aquí se hallarán dos archivos esenciales wifidog.conf y php.ini y los archivos de configuración del sistema. El primero da unas características específicas de la configuración de Wifidog y el segundo se ha de modificar y permitir funcionalidades para poder ejecutar código PHP en las páginas web del servidor. /www En este directorio se hallará toda la configuración del portal cautivo. Desde las páginas Web en Shell Script, HTML, PHP hasta las imágenes utilizadas en estas páginas. También podemos encontrar los archivos de texto que formarán el portal cautivo: el título, el texto y los comentarios de las fotos que ponga el administrador Iptables En ocasiones el término Iptables [8] se confunde con Netfilter. Éste último es un Framework situado en el núcleo de Linux que permite interceptar y manipular paquetes de red en diferentes estados del procesamiento. Iptables es el componente más popular de Netfilter, se utiliza para que un administrador cree sus propias políticas o normas de envío o recepción de paquetes. Para aclararlo, sería similar a un portero de discoteca, donde la cola de gente serían los paquetes que llegan de Internet y que más tarde el portero analizará. Éste posee una lista con una serie de normas en la vestimenta, tipo de peinado, etc. Si una persona no la cumple, no puede dejarla pasar. Éste es un ejemplo muy simple, pero deja bastante claro el concepto de las Iptables. Al ejecutar Wifidog, crea una serie de Iptables, normas que han de cumplir los paquetes que son interceptados por el nodo, al principio bloquean todo tipo de tráfico y redirigen al portal cautivo a todos los usuarios. Wifidog está diseñado para que los usuarios se autentiquen en el servidor, y cuando lo hagan se les da el privilegio de navegar por la red mesh. 29

40 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto Pero en nuestro caso no queremos que los usuarios se autentifiquen, queremos una red libre sin restricciones. Por eso, mientras que el programa mientras espera una autenticación lo que hacemos es crear las dos Iptables básicas para que el usuario si acepte la normativa pueda navegar. Wifidog sigue éste pseudocódigo: Si El usuario tiene una Iptable que deja de redirigirlo al portal cautivo Si no Si El usuario tiene una Iptable que le da acceso a Internet Usuario con conexión a Internet Si no Por mucho que deje de redirigirse al portal cautivo, si no tiene una vía de salida, jamás podrá ir a Internet Siempre se redirigirá al portal cautivo Wifidog Para instalar Wifidog [6] deberemos seleccionarlo antes de compilar nuestro propio firmware. Con el comando make menuconfig, en la sección Network en Portales cautivos. Este proceso se explica más detalladamente en el Anexo A. Una vez instalado, Wifidog crea un archivo de configuración en el directorio /etc llamado wifidog.conf, éste archivo se modifica con los parámetros deseados: - Interfaz de entrada - Interfaz de salida a Internet - Direcciones IP que serán bloqueadas - Direcciones IP que permitiremos conectarse a los usuarios - Puerto que utilizará Wifidog 30

41 Diseño del sistema Anteriormente se explica que Wifidog anula todo tipo de tráfico a los usuarios, pero habilita una dirección IP en concreto, la del servidor de guifi.net. Así cuando a los usuarios les salga el portal cautivo, si quieren más información podrán ir a un enlace que les lleva directamente a la página de guifi.net. Sólo está habilitada esta página. Si el usuario intenta ir a otro sitio web que no sea éste siempre será redirigido al portal cautivo. Wifidog está diseñado para servidores de autenticación, pero en nuestro caso sólo queremos que se bloquee el acceso a Internet a los usuarios que no acepten una normativa. Si el usuario acepta la normativa podrá navegar libremente por Internet, en caso contrario el usuario no tendrá ningún tipo de privilegio y será redirigido siempre al portal cautivo. Si creamos nuestro firmware con Wifidog, al ejecutarlo en el nodo tendríamos que seguir unos ciertos pasos para configurarlo y cada vez que creáramos el firmware se repetiría este proceso. Para hacerlo de una manera más eficaz se ha creado un archivo de configuración genérico que sustituye al fichero de configuración predeterminado de Wifidog, como se menciona al inicio de esta sección, se explica en el anexo A. Wifidog.conf Se explican los conceptos básicos de este fichero de configuración sin entrar en detalle, donde se configura el funcionamiento que queremos de Wifidog. - Interfaz de Salida Figura 3.2 Asignar interfaz de salida Aquí se pondrá cuál es la interfaz de salida a Internet para que Wifidog sepa dónde tiene que bloquear el tráfico. - Interfaz de entrada Figura 3.3 Asignar interfaz de entrada Esta será la interfaz donde los usuarios se conectaran al nodo, la Wi-Fi de 2,4 Ghz. 31

42 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto - Puerto utilizado Figura 3.4 Asignar puerto Por defecto el puerto utilizado por Wifidog es el 2060, pero puede ser modificado. En este puerto estará escuchando constantemente, para analizar las peticiones de los usuarios. - Servidor de Autenticación Figura 3.5 Asignar dirección IP del nodo Estas líneas sirven para saber cuál es el servidor de autenticación, poniendo la dirección IP del nodo y la ruta hacia la página del portal cautivo. Un fallo en la ruta significaría que no se mostraría ninguna página como portal, daría el típico error: Request not found. - Usuarios desconocidos Figura 3.6 Asignar normas Para los usuarios que no hayan aceptado la normativa, sólo se les permitirá acceso a lo mostrado en la última captura. Se acepta las direcciones IP de servidores (puerto 53), DHCP (puerto 67) y conexión con el servidor de guifi.net (puerto 80 habilitado). 32

43 Diseño del sistema - Bloquear usuarios Figura 3.7 Asignar direcciones IP a bloquear En caso de tener problemas con ciertos usuarios, el administrador podrá poner su dirección IP en esta norma del fichero impidiéndole la conexión con el nodo. Wifidog crea varias Iptables, pero nosotros nos centraremos en las dos más importantes llamadas WiFiDog_WIFI2Internet y WiFiDog_Unknown más tarde explicaré el porqué Estructura La estructura de las páginas del portal cautivo es muy simple. Hay una página principal que sería el portal cautivo, otra página donde se autenticaría el administrador del nodo y por último las encargadas de modificar el portal implementadas en PHP Página principal La página principal está formada por un menú, un mensaje e información sobre el propietario del nodo, tanto con fotos con su respectivo comentario como con otro mensaje personalizado. En el menú encontramos, la sección del administrador, un enlace a la página de guifi.net, por si el usuario quiere informarse más detalladamente sobre la conexión que va a utilizar. Más abajo, se informa del puerto utilizado y la dirección IP del nodo al cual está conectado el usuario y la página a la cual iba a visitar. La página que iba a visitar el usuario, se refiere a que cuando un usuario se conecta al nodo por primera vez, va al explorador y pone una dirección URL del servicio www. El usuario solicita una petición por el puerto 80, pero no está autorizado a utilizar la red de guifi.net ya que no ha aceptado previamente una normativa. El nodo comprueba que no hay ninguna Iptable para esa dirección 33

44 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto IP y contesta su petición por el puerto 2060, donde le muestra el portal cautivo. La página que el usuario había solicitado inicialmente se guarda, si el usuario acepta la normativa abajo aparece un enlace con esa página web, para que pueda ir a ese sitio web, sin tener que ir al explorador y volverlo a escribir. El mensaje de información es igual en todos los nodos, y abajo hay un botón por si el usuario acepta. Como Wifidog no está diseñado para nuestro propósito, lo que se hace cuando el usuario acepta la normativa es crear dos Iptables. Estas dos Iptables son básicas para dar paso al usuario hacia Internet. Debajo del mensaje, el propietario del nodo podrá poner un título, un texto, y subir varias fotos al nodo. Con cada foto el propietario podrá poner un comentario para explicar mejor su contenido. Cuando los usuarios se conecten al nodo verán lo que el administrador haya escrito y subido. En los siguientes apartados se explica con más detalle como se ha implementado Administrador El administrador tiene su espacio reservado. Sólo tiene que autenticarse para poder acceder a su sección. La página está distribuida en comandos asociados a botones para que los propietarios del nodo que no tengan conocimientos sobre redes ni GNU/Linux, puedan obtener información. Hay comandos más complejos que otros, por ejemplo asignar una dirección IP cómo salida a Internet, ver el estado de todas las interfaces, etc. Por eso al pulsarlo sale una pequeña explicación de la finalidad de esa instrucción. Gracias a la información que adquiera el administrador, podrá tomar decisiones. Por ejemplo puede ver si un usuario consume demasiado ancho de banda. De ser así puede restringirle la conexión al nodo durante un cierto período de tiempo. En ésta misma página hay una sección para la modificación del portal, éste lleva a unas páginas en PHP encargadas de ello. 34

45 Diseño del sistema Modificar portal La página está dividida en dos partes, una para poner un título, y redactar un texto, y la otra para poner una foto con su comentario. Una vez subida la foto con su comentario podrá ser eliminada. La página donde modifica el portal tiene el mismo aspecto que el portal cautivo, a medida que se va modificando se van observando los cambios. 35

46 Diseño del sistema 36

47 Implementación 4. Implementación 4.1 Introducción En esta sección se explica más detalladamente y a un nivel más técnico el funcionamiento de las páginas web [9]. 4.2 Estructura Este apartado está organizado como el anterior, primero se comentará la página principal que es el portal cautivo y en los apartados posteriores se detalla la parte del administrador y la modificación del portal. Resaltando los códigos más importantes Página principal Como se comenta en el apartado anterior al pulsar el botón de la normativa las Iptables que se crean son: Iptables t nat I WiFiDog_Unknown 1 s $REMOTE_ADDR j ACCEPT Iptables t nat I WiFiDog_WIFI2Internet s $REMOTE_ADDR j ACCEPT Estas dos Iptables [3] son vitales para el correcto funcionamiento del portal cautivo. A continuación están explicadas con detalle. Iptables t nat I WiFiDog_Unknown 1 s $REMOTE_ADDR j ACCEPT Deja de re direccionar al portal cautivo. Es decir, si no pusiéramos este comando, aunque tuviéramos acceso a Internet, no podríamos visitar otras páginas ya que el nodo nos redirigiría siempre al portal cautivo. Iptables t nat I WiFiDog_WIFI2Internet s $REMOTE_ADDR j ACCEPT Da paso a Internet. Este comando hará que el nodo deje de bloquear tráfico al usuario y permita navegar libremente por la red. 37

48 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto * $REMOTE_ADDR, es una variable de Shell Script, cuando el usuario pulsa el botón aceptando la normativa, se crean las dos Iptables con la dirección IP del usuario que ha pulsado en el botón. Aparte de mostrar el mensaje inicial estático por guifi.net, el propietario del nodo puede crear una parte dinámica, para mostrar el título y el texto, se llama a la función: Cat título.txt Cat cuerpo.txt Titulo.txt contiene como bien dice el nombre, el título que haya puesto el administrador, y en cuerpo.txt se halla el texto que haya redactado. Para las fotos y sus comentarios, se crea un bucle foreach que por cada foto que esté en la carpeta se muestra la imagen, junto con su comentario. Para mostrar el comentario de las fotos se vuelve a utilizar el comando cat del archivo, sabemos a qué comentario pertenece cada foto porque se llaman igual pero uno acabado en.jpg y el otro en.txt. Por lo tanto se coge el nombre de la foto y se concatena con la extensión.txt. Se ha creado una función en Shell Script que recoge los parámetros pasados por el método GET, para que coja el que contenga la variable URL. En esta variable se guarda el contenido de la primera página que solicitó el usuario. Así cuando acepte la normativa le saldrá un enlace justo debajo para que pueda seguir navegando a esa página. Lo mostramos con un echo $url, y el usuario sólo tiene que pulsarlo y se redirigirse al sitio web. Exactamente de misma forma se hace para las variables del puerto utilizado y dirección IP del router que se muestran en el menú. Aunque se utilice una función más simple Administrador La parte reservada al administrador posee comandos para la correcta monitorización del nodo y de los usuarios conectados a él, a continuación comentaré cada uno de las instrucciones ejecutadas agrupadas por sus funciones. Gráficas, página donde se muestran las gráficas de los paquetes recibidos y transmitidos de cada interfaz. Reiniciar, con este comando reiniciamos el nodo, reboot. 38

49 Implementación Modificar contraseña, posibilidad de cambiar la contraseña para acceder al nodo, primero se ha de verificar la actual, y luego en dos campos poner la nueva. Hay dos campos para controlar que el administrador coloque la misma, sin margen de error. Al utilizar por primera vez el S.O. no hay contraseña, por eso en el manual que va adjunto en la sección del administrador se recomienda poner una de inmediato. Protocolos de encaminamiento, El nodo funciona con tres protocolos de encaminamiento, BMX, OSLR y BATMAN, junto a cada protocolo hay un botón correspondiente a su activación o desactivación. Si se activa o desactiva se muestra un mensaje, cómo BMX iniciat o BMX parat. Configuración de la Mesh, Éste es un fichero dónde podemos configurar opciones del nodo, como la longitud o latitud de donde está situado, las direcciones de IP de servidores y configuración de la LAN. Cabe la posibilidad de habilitar el nodo para que sea el servidor DHCP y los usuarios soliciten direcciones IP libres, activar o desactivar NAT. Este proceso consiste en pasar de una dirección IP privada a una pública cuando queremos acceder a Internet. Información del Nodo - PROCESOS, Obtener la información de los procesos ejecutados en el nodo. Se ejecuta el comando ps y se muestra una lista con todos los procesos ejecutados en el nodo. - HISTORIAL DE USUARIOS CONECTADOS AL NODO, Cuando el usuario acepta la normativa se guarda su dirección IP, su hora exacta de conexión y su primera página de inicio. Al solicitar esta información se ejecuta el comando ya utilizado anteriormente cat registro.txt donde está toda esta información almacenada. Se crea un fichero conjunto con toda la información de todos los usuarios. 39

50 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto - INFORMACIÓN SOBRE LA CPU, es información muy detallada sobre la CPU, como la familia, tamaño de la caché, velocidad., etc. El comando utilizado es cat /proc/cpuinfo. - INFORMACIÓN SOBRE LA MEMORIA UTILIZADA, comando muy similar al anterior, pero en este caso sobre la memoria, cuánto espacio tiene ocupado, cuánto le queda disponible, caché, buffers, etc. Esta información varía constantemente mientras el sistema está en funcionamiento. El comando utilizado es cat /proc/meminfo. - ESPACIO DISPONIBLE EN LA COMPACTFLASH, comando que nos permite saber el espacio de la CompactFlash utilizado, el espacio disponible, el porcentaje de uso total y por último el punto de montaje del sistema. El comando utilizado es el df -h. Se puede observar que también nos indica las unidades montadas en el sistema. Información de red - INFORMACIÓN INTERFACES ACTIVAS, Mostramos todas la interfaces activas con dos comandos, cat /proc/net/dev y ifconfig, los dos obtienen información muy útil. cat /proc/net/dev Lista todas las interfaces activas, y extrae datos tanto los bytes como los paquetes recibidos/transmitidos, errores, paquetes comprimidos, etc. ifconfig Lista todas las interfaces configuradas en el nodo, con su dirección IP y máscara, dirección MAC, métrica, paquetes transmitidos (TX), paquetes recibidos (RX), etc. 40

51 Implementación - USUARIOS CONECTADOS AL NODO, Se ejecuta el comando cat /proc/net arp el protocolo ARP nos dice todos los dispositivos que están conectados al nodo, tanto por Wi-Fi como por cable. Nos hace una lista de todos los vecinos del nodo. - INFORMACIÓN ESPECÍFICA DEL USUARIO, Podemos sacar mayor información de cada usuario si ponemos una dirección IP concreta, como por ejemplo su dirección MAC, los paquetes y la cantidad de información transmitida, y la misma información que en registro.txt. Este Fichero que contiene la hora exacta de conexión al nodo y la primera página web visitada. Para hacer todo esto se saca la información del comando Iptables -L-v y se pasa por pipes con las instrucciones cut y awk para sacar toda la información que queremos mostrar. Se ejecuta también el comando ping y traceroute. El primero para saber si la conexión que tenemos con ese usuario es buena, y el segundo para saber cuántos saltos hay hasta llegar a él. Los saltos son los routers o nodos que hay en todo el camino hasta llegar al usuario. - ESTADO DE LA WIRELESS, Este comando nos dice la calidad de la Wi-Fi de las dos antenas, también el ruido y los paquetes descartados. - TABLA DE ENCAMINAMIENTO, Con el comando route -n, nos muestra todas las rutas que posee nuestro nodo, y a que interfaces están asociadas. (eth0, eth1, ath0, ath1, etc.). - ESTABLECER UNA RUTA POR EFECTO, cuando un usuario conecta su nodo por primera vez o lo reinicia, hay rutas que desaparecen, por ejemplo un usuario tiene el nodo conectado a un router por un cable RJ-45, él se conecta al nodo y el nodo tiene como salida a Internet el router del 41

52 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto proveedor de Internet. Gracias a este comando podemos especificar por donde queremos tener salida a Internet. En el caso del usuario sería por ejemplo la porque es la dirección IP que tiene su router. La dirección IP se inserta en un textarea y se guarda en una variable y se ejecuta el siguiente comando: Ip route add default gw $VARIABLE - NETSTAT, este comando se usa para mostrar el estado de la red. Tiene varios parámetros que pueden mostrar toda la información que se necesite, en este caso el comando utilizado es el netstat -a. Wifidog - ACTIVAR WIFIDOG, Para activarlo se ejecuta el paquete Wifidog, comando wifidog f d 7. Las opciones -f y -d significa que se ejecuta en segundo plano y en modo debugging. - DESACTIVAR WIFIDOG, Se ejecuta el comando killall de Wifidog, sólo si está en los procesos activos. - IPTABLES, Podemos visualizar las Iptables creadas por Wifidog, e ir viendo todos los usuarios que van accediendo a nuestro nodo, por cada usuario que acepta la normativa se generan Iptables para dar paso a Internet. Para ver los usuarios que van aceptando la normativa, sólo hace falta ir a la Iptables WiFiDog_WIFI2Internet e ir viendo cómo se van añadiendo las direcciones IP. 42

53 Implementación Modificar portal Nos dirige a unas páginas en PHP con la finalidad de modificar una parte del portal cautivo [12]. Una vez allí podemos ver que hay dos textareas. En ella se visualiza el contenido actual del título y el texto escrito por el propietario del nodo. Como no se pueden añadir negritas, cursivas ni subrayado, se han creado una serie de normas. Por ejemplo si se quiere crear un texto con negrita al inicio del textarea se pone anegrita y al final cnegrita. Éstas cadenas serán intercambiadas por <b> </b> respectivamente, así cuando el usuario abra la página web se interpretará en código HTML y saldrá en negrita. ABRIR CERRAR EQUIVALE anegrita cnegrita <b>texto </b> Texto acursiva ccursiva <i> Texto </i> Texto asubrayado csubrayado <u> Texto</u> Texto Estas cadenas se explican en un fichero aparte para que el usuario adquiera estos conocimientos para hacer su página más atractiva, con la posibilidad de poner cursiva, negrita, subrayado y cambiar el tamaño del texto. A medida que vamos subiendo fotos al nodo, éstas van apareciendo con su comentario y un checkbox al lado. Además las fotos pueden verse en versión reducida en la parte inferior de la página, para ir controlando el número de fotos que vamos subiendo. Se utiliza un bucle similar al de la página principal para que vayan apareciendo las imágenes con sus respectivos comentarios, en el recuadro que aparece al lado podemos seleccionarlo para borrar la foto deseada. Las páginas titulo.php, cuerpo.php, subearchivo.php, delete.php, tienen un código en PHP que se redirigen directamente a la página de modificar. Es decir, cuando se sube una foto o se cambia un título, depende de lo que se haga va a una página PHP o a otra. Para no tener que volver atrás una vez se ha puesto un título, hay un código en todas las páginas que hace que se re direccione, de manera que veamos automáticamente los cambios efectuados. 43

54 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto Código para re direccionar: <?php $tiempo = 0 ; $pagina = login.php > <meta http-equiv= refresh content= <?= $tiempo; url=$pagina?> > Creamos una variable para almacenar el tiempo en segundos. En este caso es 0 segundos ya que no se quiere que dé tiempo a visualizar la página. Además, se crea otra variable para el contenido de la página, que en todos los casos será la misma, Login.php. Figura 4.1 Como se muestra en la figura 4.1, Login llama a las páginas para borrar y subir fotos, editar texto y editar el título y automáticamente vuelven a Login. A continuación explicaré el funcionamiento básico de estas páginas: Titulo.php y Cuerpo.php El código de estas dos páginas es exactamente igual. El valor del título o del texto de la página se almacena en una variable, y se guarda en un fichero nuevo llamado titulo.txt o cuerpo.txt. Así cuando estamos en la página principal lo podemos ver ejecutando el comando cat titulo.txt y cat cuerpo.txt. 44

55 Implementación Subearchivo.php Su funcionamiento es cargar un archivo del ordenador y subirlo al servidor junto con su comentario. Tiene unas condiciones que de no cumplirse no se completará la subida del archivo. La foto debe estar en un formato.jpg o.gif y no debe ocupar más de 10 Megabytes. En caso de error se notificaría con un mensaje. Delete.php Este fichero sirve para borrar las fotos del servidor y su respectivo comentario. Para ello se selecciona un checkbox que va al lado de cada foto de manera que se pasa el nombre del archivo. Como el comentario tiene el mismo nombre pero con una extensión diferente se concatena el nombre de la foto con.txt para la correcta eliminación. Se utiliza la función unlink($foto), donde el contenido de la variable foto, es el nombre de la fotografía a borrar. 45

56 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto 46

57 Pruebas y mantenimiento 5. Pruebas y mantenimiento Las pruebas para comprender mejor el comportamiento del portal cautivo se han realizado con un programa llamado Wireshark [13], que permite obtener en tiempo real información detallada de cada paquete de datos que entra o sale de nuestra red. Figura 5.1 Captura Wireshark Figura 5.2 Captura Wireshark En la fila del No. 16 se observa como Wifidog permite acceso al puerto 53, que son las direcciones de IP de servidores por eso deja pasar los paquetes cuando solicitamos por primera vez la página de Apple. Se ve claramente que el origen es el usuario que solicita la página y el destino es el nodo, que luego se encargará de buscar esa información, para posteriormente, realizar el recorrido inverso, como se ve en el No. 17. En el No. 18 el usuario ya tiene la dirección IP de la página solicitada y comienza con la petición para conectarse al servidor que contiene la página de Apple. Seq=0. En el No. 19, el servidor con la página de Apple le contesta, diciendo que ha recibido su petición y que espera establecer una conexión con el usuario. Seq=0 Ack=1. 47

58 Desarrollo de un portal cautivo y herramientas de administración en un entorno Wi-Fi abierto En el No. 20, el usuario le devuelve una respuesta diciéndole que ha recibido correctamente la aceptación de conexión con el servidor. Seq=1 Ack=1. Figura 5.3 Captura Wireshark Figura 5.4 Captura Wireshark En el No. 33, el usuario le dice al nodo que quiere conectarse a la dirección IP del servidor de Apple. En los Nos. 34 y 35 empieza otra vez la negociación para establecer una conexión como en los pasos 18, 19 y 20. En el No. 36, una vez se ha conectado, el servidor contesta con la página de inicio del portal cautivo. 48