desarrollo de un portal cautivo y herramientas … · desarrollo de un portal cautivo y...

DESARROLLO DE UN

PORTAL CAUTIVO Y

HERRAMIENTAS DE

ADMINISTRACIÓN EN UN

ENTORNO WI

Memoria del proyecto de

Informática de Sistemas

Escuela Universitaria de Informática Sabadell, junio de 2010

DESARROLLO DE UN

PORTAL CAUTIVO Y

HERRAMIENTAS DE


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 2010

1

DESARROLLO DE UN

PORTAL CAUTIVO Y

HERRAMIENTAS DE


FI ABIERTO

i

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 2010

------------------------------ Firmado: David Megías Jiménez

iii

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 9.000 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.

v

Tabla de Contenidos Resumen iii Tabla de Contenidos v Capítulo 1: Introducción 1

1.1 Presentación 1 1.2 Estado del arte 2 1.3 Objetivos 3 1.4 Organización de la memoria 3

Capítulo 2: Análisis del sistema Actual 5 2.1 Introducción a las redes mesh 5 2.1.1 Esquema clásico 5 2.1.2 Esquema mesh /ad-hoc 6 2.1.3 Servicio de conexión a Internet 7 2.2 Estudio de Viabilidad 8 2.2.1 Introducción 8

2.2.2 Estudio de la situación actual 10 2.2.3 Requisitos del proyecto 12 2.2.4 Alternativas y selección de la solución 13 2.2.5 Planificación 14 2.2.6 Evaluación de riesgos 17 2.2.7 Presupuesto 18

2.3 Montaje del nodo 20 Capítulo 3: Diseño del sistema 23 3.1 Análisis de requerimientos 23 3.1.1 Requerimientos previos 23 3.1.2 Requerimientos funcionales 25 3.1.3 Requerimientos no funcionales 26 3.2 Descripción de la plataforma 27 3.2.1 Introducción 27 3.2.2 Sistema operativo 28 3.2.3 Directorios 29 3.2.4 Iptables 29 3.2.5 Wifidog 30 3.2.6 Estructura 33

Capítulo 4: Implementación 35 4.1 Introducción 35

4.2 Estructura 35 4.2.1 Página principal 35 4.2.2 Administrador 36

Capítulo 5: Mantenimiento y pruebas 45 Capítulo 6: Conclusiones 47 6.1 Conclusiones globales 47

6.2 Ampliaciones 49 Bibliografía 49 Agradecimientos 51 Anexo A: Creación del firmware 53

Introducción

1

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 802.11.

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 8.09.1. 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.

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

2

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 [http://graciasensefils/splash/]

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. 1.3. 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

Introducción

3

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.

1.4. 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.


4

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.

Análisis del sistema actual

5

2. Análisis del sistema actual

2.1 Introducción a las redes mesh 2.1.1 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


6

2.1.2 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.

__________________________________________________________________________Análisis del sistema actual

7

2.1.3 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.


8

2.2 Estudio de viabilidad

2.2.1 Introducción

2.2. 1.1 Tipología:

Desarrollo de un portal cautivo y herramientas de administración en un

entorno Wi-Fi abierto.

2.2. 1.2 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.

2.2. 1.3 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.


9

2.2. 1.4 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.

2.2. 1.5 Partes interesadas Perfiles de usuario

Perfil Responsabilidad Administrador del

nodo 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.

Usuario 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 Responsabilidad

Analista Colabora con el Director de proyectos en el estudio de viabilidad i la planificación del proyecto.

Programador Diseña y desarrolla la aplicación de acuerdo con el análisis y planificación prevista.

Técnico de pruebas Realiza las pruebas del software y participa en el control de calidad.

Técnico de hardware

Montaje un nodo.

Director del proyecto Supervisa el trabajo del proyectista


10

2.2.2 Estudio de la situación actual

2.2. 2.1 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.

2.2. 2.2 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.


11

� 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.

2.2. 2.3 Usuario y/o personal del sistema

Perfil

Responsabilidad

Administrador del nodo

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.

Usuario El usuario sólo podrá ver el mensaje de bienvenida del portal cautivo y el mensaje del propietario del nodo.

2.2. 2.4 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.


12

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

2.2.3 Requisitos del proyecto

2.2. 3.1 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

2.2. 3.2 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


13

2.2. 3.3 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.

2.2. 3.4 Catalogación y priorización de los requisitos func ionales (RF)

1 2 3 4 5 6 7 8 Esencial X X X

Condicional X X X Opcional X X

2.2. 3.5 Catalogación y priorización de los requisitos no f uncionales (RNF)

1 2 3 4 5 6 7

Esencial X X X Condicional X X X

Opcional X

2.2.4 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 8.09.1, 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.


14

� 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.

2.2.5 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.

2.2. 5.1 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)

2.2. 5.2 Recursos del proyecto

Recursos humanos Valoración

Jefe de proyecto 40€/h

Programador Analista Técnico de pruebas

Técnico de hardware

20€/h

Reuniones con la comunidad 0€/h


15

2.2. 5.3 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 15

11 - Descargar paquete Wifidog 3

12 - Configuración Wifidog 40

13 - Creación página Splash 75

14 - Creación del nuevo firmware 3

15 Realización pruebas 15

16 Finalización memoria 5

Duración Total de la planificación 297


16

2.2. 5.4 Planificación Diagrama de Gantt

Figura 2.8 Diagramas de Gantt

Figura 2.9 Diagramas de Gantt


17

2.2.6 Evaluación de riesgos

2.2. 6.1 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.

2.2. 6.2 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.


18

2.2.7 Presupuesto

2.2. 7.1 Estimación coste de personal

Personal Horas Coste Proyectista* 297 5.940€

* El proyectista a lo largo del proyecto realizará funciones de analista, programador, realizador de pruebas y técnico de hardware.

2.2. 7.2 Estimación coste de recursos

Coste amortización

Coste Periodo amortización

Periodo utilización

PC 375€ 1500€ 36 m 9 m

VMware 20€ 80 € 36 m 9 m

Ubuntu * * * *

OpenOffice.org * * * *

MSProject 90€ 360€ 36 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 MPCI256 MB USB

1 83,80 €

Fuente de alimentación 18 v. 0,8 A (15 W) 1 5,93 €

Compex WLM54SAG23 802.11 AGB 200mW 108 Mb/s

2 24,40 €

Pigtail 5 GHz UFL-N Jack Bulkhead 30 cm 2 5,19 €


19

MATERIAL Cantidad Precio

Antena Dipolo DUAL 5/2,4 Ghz 7 dBi Connector N Macho

2 22,28 €

Caja Universal IP65 ABS con conector RJ45 incluido

1 24,40 €

CompactFlash Transcend TS2GCF133 (4GB) 1 15,5 €

Total* 233,37 €

I.V.A ( 16% ) 37,34€

Total Presupuesto Nodo 270,71€

TOTAL= 270,71€

2.2.7.3 Resumen del presupuesto

Coste del desarrollo del proyecto………………………………………………………………5.940€ Coste de amortización del material…………………………………………..…………………...817,6€

TOTAL

6.757,6€


20

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


21

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 2.11. Se colocará el nodo en una zona lo más elevada posible para tener una

mejor conexión con los nodos vecinos, figura 2.12.

Figura 2.11 Montaje del nodo

Figura 2.12 Colocación del nodo


22

Diseño del sistema

23

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.

3.1. 1 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.


24

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 8.09.1. Para poder utilizar Wifidog, primero deberemos instalar una serie de paquetes:

� IPTABLES – 1.4.0-1 � IPTABLES – MOD – CONNTRACK – 1.4.0-1 � IPTABLES – MOD – EXTRA -1.4.0-1 � IPTABLES – MOD – IPOPT -1.4.0-1 � IPTABLES – MOD – NAT – 1.4.0-1 � IPTABLES – MOD – NAT – EXTRA – 1.4.0-1

� KMOD – IPIP – 2.6.25.17 –x86-1 � KMOD – IPT – CONNTRACK – 2.6.25.17-x86-1 � KMOD – IPT – CORE – 2.6.25.17-x86-1 � KMOD – IPT – EXTRA – 2.6.25.17-X86-1 � KMOD – IPT – IPOPT – 2.6.25.17-X86-1 � KMOD – IPT – NAT – EXTRA – 2.6.25.17-X86-1 � KMOD – IPT – NATHELPER - 2.6.25.17-X86-1

� OPKG – 4564 – 3 (Paquete que permitirá instalar y actualizar paquetes

en el sistema)

� PHP4 – 4.4.7 – 1 (Utilidad para poder ejecutar código PHP en las

páginas del servidor, fichero que ha de ser configurado)

� WIFIDOG – 1.1.5 – 2 (Paquete para anular todo tipo de tráfico a los

usuarios que se conecten al nodo)

� VI (Editor de textos)

__________________________________________________________________________________Diseño del sistema

25

3.1. 2 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 no do

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 n odo

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.


26

RF5: Conexión externa con guifi.net para obtener ma yor 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.

3.1. 3 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.


27

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 E-mail 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 3.2.1 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.


28

3.2.2 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.


29

3.2.3 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.

3.2.4 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.


30

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 “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

Si no Siempre se redirigirá al portal cautivo 3.2.5 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


31

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.


32

- 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).


33

- 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é. 3.2.6 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. 3.2.6.1 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


34

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. 3.2.6.2 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.


35

3.2.6.3 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.

Diseño del sistema

36

Implementación

37

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. 4.2.1 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_ADD R –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_ADD R –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.


38

* $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.

4.2.2 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 .

Implementación

39

� 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.


40

- 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.

Implementación

41

- 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


42

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 192.168.1.1 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.

Implementación

43

� 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 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 Texto Texto acursiva ccursiva Texto Texto

asubrayado csubrayado Texto 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.

44

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 .

Implementación

45

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.


46

Pruebas y mantenimiento

47

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


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 .


48

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 .



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.

Conclusiones

49

6. Conclusiones

6.1 Conclusiones globales

A lo largo del proyecto se han podido observar diferentes campos, como la construcción de un nodo, manejo de un sistema operativo desconocido y utilización de lenguajes de programación.

Para todo ello se ha tenido que adquirir una gran experiencia ya que al inicio del proyecto no se dominaba la mayoría de estos campos. Para solucionar dichos problemas, el proyectista se documentó todo lo posible y se inscribió en foros y listas.

En los foros se habla más sobre el sistema operativo para comprender mejor su funcionamiento y de los ficheros de los cuales está formado, se buscaba y dejaba información aunque muchas veces no se obtenía respuesta. También se recurrió a las listas sobre Wifidog, dónde se tenía que escribir en francés o inglés para que los usuarios comprendieran las dudas y las resolvieran.

En varias ocasiones se ha quedado con los creadores de guifi.net desde

reuniones en el Rabal hasta en Sant Joan Despí, en todas ellas se aprendían lecciones avanzadas sobre redes, por eso ir a todas era de gran ayuda.

Ha habido momentos de dificultad ya que al principio del proyecto no se

podía ni cumplir el objetivo número uno, que era que apareciese el portal cautivo.

Los resultados que ha obtenido el proyectista han sido positivos,

sobretodo porque al principio no se esperaba terminar el proyecto con tantos objetivos cumplidos y haber realizado una base del firmware ya compilada con toda su configuración.

Finalmente, cabe destacar que los conocimientos adquiridos sobre telecomunicaciones son beneficiosos ya que el proyectista se dedicará a ello en un futuro.


50

6.2 Ampliaciones El proyecto sólo consistía en generar un portal cautivo en el nodo, pero para que todos los usuarios que quieran disfrutar de él no sigan todos los pasos realizados previamente, se ha creado un archivo con unas instrucciones. Estas últimas permiten que, al ejecutarlo, se cree el sistema operativo con todos los archivos de configuración incluidos. En un futuro se podrían ampliar las características del portal cautivo, con la posibilidad de subir videos y un número mayor de fotos con una calidad superior y comandos más elaborados.

Bibliografía

51

Bibliografía Publicaciones impresas

[1] Andrew y Paul Hudson. La biblia de Ubuntu, Ed. Anaya Multimedia,

2008. Madrid.

[2] Mut, Jose Carlos. Desarrollo e implementación de un entorno Wi-Fi abierto. Proyecto de la universidad UAB Sabadell, 2009.

[3] Odom, Wendell. Cisco CCNA ICND1 y ICND2, Ed. Pearson, 2008. Madrid

Recursos electrónicos [4] Guifi.net [www.guifi.net]

o Último acceso: 28 de junio de 2010

[5] GraciasenseFils [www.graciasensefils.net] o Último acceso: 28 de junio de 2010

[6] Wifidog [dev.wifidog.org]


[7] OpenWRT [www.openwrt.org] o Último acceso: 28 de junio de 2010

[8] Foros del web [www.forosdelweb.com]


[9] Ubuntu [www.ubuntu-es.org] o Último acceso: 28 de junio de 2010

[10] Linux [www.linux-os.com]


[11] Landashop [www.landashop.com] o Último acceso: 28 de junio de 2010

[12] 3schools [www.3schools.com]


[13] Wireshark [www.wireshark.org] o Último acceso: 28 de junio de 2010


52

[14] UOC [www.uoc.edu]


[15] Lugro-mesh [www.lugro-mesh.org.ar] o Último acceso: 28 de junio de 2010

[16] Youtube [www.youtube.com]


Agradecimientos

53

Agradecimientos

Antes de todo el proyectista agradece todos los consejos y tiempo dedicado que le ha ofrecido el director del proyecto, David Megías. A la universidad por invertir en la compra de los recursos, que sin ellos no hubiera sido posible realizar el proyecto. Destacar también Jose Carlos Mut por todos sus consejos. Y Finalmente, a mi familia y sobre todo a mi padre por la ayuda ofrecida en la construcción del nodo y a mi novia por toda la paciencia que ha tenido. Gracias a todos.

Alberto Moral Gómez, Sabadell, junio 2010.

desarrollo de un portal cautivo y herramientas … · desarrollo de un portal cautivo y...

Documents