Raspberry Pi-practicas Estacion Servicios.13.3.v2

IMPLEMENTACIÓN DE

SERVICIOS DE RED MEDIANTE UNA

RASPBERRY PI VERSIÓN 13.3.2

IES TIEMPOS MODERNOS Zaragoza – ESPAÑA Arturo Martín Romero

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 1

Hace escasamente un año, en febrero del 2012 salió al mercado el microcomputador Raspberry Pi con la finalidad de acercar y facilitar a los docentes la enseñanza de la arquitectura de computadores gracias a su reducido coste (en torno a 30€). Tras su lanzamiento, muchos usuarios pronto le encontraron otro tipo de uso a la Raspberry Pi como equipo “media center” o como sistema microcontrolador avanzado. Además de estas, otra posibilidad de uso de la Raspberry Pi es la que se va a presentar en el presente tutorial de prácticas, en la que se presenta a la Raspberry Pi como una perfecta estación de servicios de red: Gateway, DNS, DHCP, proxy HTTP, controlador de dominio principal, servidor HTTP/HTTPS, unidad de red NAS SMB/NFS/SSHFS, servidor VPN, servidor de control domótico, etc. que va a hacer dura competencia a los sobredimensionados servidores que las empresas tienen funcionando, y a los sistemas operativos propietarios como Windows Server. Según el informe del año 2012 del Ministerio de Industria, Energía y Turismo, en enero del 2011 había en España 3.246.986 empresas, de las cuales el 99.8% eran PyMes (entre 0 y 249 asalariados), de las cuales a su vez, el 95.2% tenían menos de 9 asalariados. Teniendo en cuenta que toda empresa necesita de una informatización para una mayor competitividad, el uso de un microcomputador como la Raspberry Pi puede ser la solución perfecta en este tipo de empresas donde la carga de trabajo es reducida o moderada, a la hora de cubrir multitud de servicios dentro de este tipo de PyMes gracias a su reducidísimo coste, mínimo volumen y bajísimo consumo eléctrico. Espero que este manual despierte en muchos el interés por el área de la informática relativa a la implementación de servidores, y aumente al mismo tiempo su sagacidad y un mayor afán de experimentación. El manual se encuentra bajo licencia “creative commons”, por lo cual eres libre para compartir, copiar, distribuir, ejecutar y comunicar públicamente la obra, además de hacer obras derivadas. Tan sólo tendrás que tener en cuenta la atribución al autor, hacer un uso no comercial de ella, y en caso de compartirlo, hacerlo bajo la misma licencia.

Para cualquier cuestión, constructiva o destructiva, que pueda mejorar el presente manual, por favor no dudéis en poneros en contacto conmigo. Saludos, Arturo Martín Romero [email protected]

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 2

MicroComputador Raspberry Pi Servicios Gateway/DHCP/DNS/Proxy HTTP Punto de acceso/Repetidor Controlador de Dominio Principal (PDC) Servicio de autenticación RADIUS Servicio NAS (SMB/FTP/NFS/SSHFS) Copias de Seguridad Remotas Servicio HTTP/HTTPS Servicio de Correo WebMail Servicio VPN Control Domótico Vía Web

Índice de Prácticas Práctica nº1.-Instalación del Sistema Operativo Raspbian..............................................................5 Práctica nº2.-Primer Arranque de la Raspberry Pi...........................................................................7 Práctica nº3.-Conexión a Internet de la Raspberry........................................................................10 3.1.- Configuración de la Interfaz Inalámbrica de manera gráfica (GUI).................................10 3.2.- Configuración de la Interfaz Inalámbrica desde la terminal (CLUI)................................10 3.3.- Actualización de los Repositorios y del Software del Sistema.........................................11 Práctica nº4.-Configuración de la Raspberry como servidor DHCP..............................................12 4.1.- Instalación del software servidor DHCP...........................................................................13 4.2.- Configuración del servicio DHCP....................................................................................13 4.3.- Configuración de los clientes DHCP................................................................................14 Práctica nº5.-Configuración de la Raspberry como servidor DNS................................................16 5.1.- Instalación y Configuración del servicio DNS.................................................................16 5.2.- Raspberry Pi como servidor DNS Maestro......................................................................16 5.3.- Comprobación del servicio DNS......................................................................................17 Práctica nº6.-Configuración de la Raspberry como Puerta de Enlace...........................................19 6.1.- Configuración básica de la Raspberry como Firewall......................................................20 6.2.- Configuración de la Raspberry como Punto de Acceso (AP)...........................................21 Práctica nº7.-Configuración de la Raspberry como servidor RADIUS.........................................24 7.1.- Introducción al servicio RADIUS....................................................................................24 7.2.- Definiciones previas: RADIUS, NAS, WEP, WPA..........................................................25 7.3.- Instalación y Configuración de FreeRADIUS..................................................................28 7.3.- Configuración del punto de Acceso..................................................................................30 Práctica nº8.-Configuración de la Raspberry como unidad de red Network-Attached Storage (NAS).............................................................................................................................................31 8.1.- Configuración de la Raspberry como servidor FTP..........................................................32 8.2.- Configuración de la Raspberry como servidor CIFS/SMB..............................................36 8.3.- Configuración de la Raspberry como servidor SSHFS....................................................38 8.4.- Configuración de la Raspberry como servidor NFS.........................................................39 Práctica nº9.-Configuración de la Raspberry como servidor HTTP/HTTPS................................42 9.1.- Creación de la Entidad Certificadora (CA).......................................................................42 Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 3

9.2.- Creación de las claves y certificados del servicio HTTPS...............................................42 9.3.- Configuración de Apache para dar un servicio HTTPS....................................................43 Práctica nº10.-Configuración de la Raspberry como Proxy HTTP................................................47 10.1.- Configuración previa del Entorno de Red......................................................................48 10.2.- Instalación del software servidor....................................................................................50 10.3.- Configuración de la Raspberry como proxy no transparente.........................................50 10.4.- Configuración de la Raspberry como proxy transparente..............................................53 Práctica nº11.-Configuración de la Raspberry como servidor VPN..............................................56 11.1.- Configuración del Router ISP.........................................................................................57 11.2.- Instalación del Software OpenVPN................................................................................58 11.3.- Instalación de OpenSSL. Creación de la Autoridad de Certificación (CA), y las Claves y Certificados del Servidor y de los Clientes............................................................................58 11.4.- Configuración del Servidor VPN....................................................................................59 11.5.- Configuración de los clientes VPN.................................................................................61 Práctica nº12.-Raspberry como controlador de dominio primario (PDC).....................................64 12.1.- Registro de los nombres de dominio en el servidor DNS Bind......................................65 12.2.- Instalación del software servidor PDC: Samba..............................................................66 12.3.- Configuración de Samba como PDC..............................................................................66 12.4.- Creación de Cuentas de Usuario del Dominio................................................................68 12.5.- Creación de Cuentas de Máquinas Clientes del Dominio...............................................69 12.6.- Configuración del Cliente para agregarlo al Dominio....................................................69 Práctica nº13.-Configuración de la Raspberry como servidor Webmail........................................70 13.1.- Configuración del servicio DNS Bind............................................................................71 13.2.- Instalación y Configuración del servidor SMTP PostFix...............................................73 13.3.- Instalación y Configuración del servidor IMAP Dovecot..............................................75 13.4.- Instalación y Configuración del servidor HTTP WebMail: Apache y Squirrelmail.......76 Práctica nº14.-Configuración de la Raspberry para gestión Domótica..........................................82 14.1.- Control directo del GPIO de la Raspberry......................................................................83 14.1.1.- Control directo del GPIO: Instalación de wiringPi......................................................83 14.1.2.- Gestión Domótica vía web en modo seguro HTTPS: Control directo del GPIO........84 14.2.- Raspberry con Shield Arduino. Configuración previa....................................................88 14.2.1.- Ejemplos básicos de control de dispositivos externo mediante el Shield Arduino......88 14.2.2.- Gestión Domótica vía web en modo seguro HTTPS de dispositivos externos mediante Shield Arduino..........................................................................................................................92 Práctica nº15.-Implementación final de la Estación de Servicios..................................................98

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 4

Práctica nº1.- Instalación del Sistema Operativo Raspbian Antes de instalar el sistema operativo deberemos descargar previamente desde Internet la última versión de la distribución que queramos instalar en nuestra Raspberry. En concreto puedes instalar como sistema operativo “Raspbian” (versión Debian para Raspberry), “Arch Linux” o “Risc OS”. Por comodidad y mayor facilidad para el alumno, para la presente práctica se ha optado por “Raspbian”. Puedes descargar una imagen de cualquiera de los sistemas anteriores, y así probarlos, desde “http://www.raspberrypi.org/downloads”. Tras su descarga, deberás descomprimirla antes de su instalación: [arturo@linux]$ unzip Descargas/version-raspbian.zip Tras descomprimirlo dispondremos de la imagen del sistema operativo raspbian “version-raspbian.img” para grabarla en la memoria SD. ¡¡Importante!! En relación a esta memoria SD, sería conveniente antes de adquirirla tener en cuenta para que tipo de aplicaciones queremos utilizar la “Raspberry”. Si queremos utilizarla como servidor HTTP, servidor Web, servidor de autenticación o servidor de control domótico posiblemente con una memoria SD de clase 4 (≥4MB/sg de transmisión de datos) tal vez sea suficiente, pero si queremos utilizarla como servidor de archivos, “Media Center”, servidor multimedia o “estación de juegos”, seguramente debería adquirirse una de clase 6 (≥6MB/sg) o clase 10 (≥10MB/sg). A continuación insertaremos la memoria SD en la ranura de nuestro equipo. Para comprobar que nuestro equipo GNU/Linux la ha detectado correctamente tan sólo deberemos ejecutar el comando “df -h”: [arturo@linux]$ df -h S.ficheros Tamaño /dev/sdb1 23G udev 3,8G tmpfs 1,6G none 5,0M none 3,8G none 100M /dev/sda5 910G /dev/sdc1 3,7G

Usado 5,2G 4,0K 1,3M 0 1,1M 0 706G 32K

Disp 16G 3,8G 1,6G 5,0M 3,8G 100M 159G 3,7G

Uso% 25% 1% 1% 0% 1% 0% 82% 1%

Montado en / /dev /run /run/lock /run/shm /run/user /home /media/0520-EB19

Tras la ejecución del comando anterior, “df -h” deberemos advertir como ha detectado vuestro sistema a vuestra memoria SD. En mi caso, lo detecta como dispositivo “sd”, y número de unidad detectada “c” (sdc). Es decir, el tercer dispositivo o disco detectado por el sistema, tras el “/dev/sda” y “/dev/sdb”. El “1” del final, es simplemente la partición existente en ese disco. Por último, como usuario “root”, desmontaremos la tarjeta SD, y volcaremos la imagen del sistema operativo descargada y descomprimida mediante el comando “dd” (duplicate disk): [root@linux]$ umount /dev/sdc1 Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 5

[root@linux]# dd bs=4M if=Descargas/version-raspbian.img of=/dev/sdc ¡¡Importante!! Ovbiamente en lugar de “/dev/sdc”, habrá que indicar el nombre del dispositivo de nuetra memoria detecatada por el sistema, sin indicar número de partición. También puede hacerse uso de la interfaz gráfica para gramar la imagen “*.img” en la tarjeta SD mediante el software usb-imagewriter en Ubuntu.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 6

Práctica nº2.- Primer Arranque de la Raspberry Pi. Para poder empezar a disfrutar de nuestra Raspberry introduciremos la tarjeta SD en la ranura correspondiente del Raspberry Pi. Después, le conectaremos los cables de red (o interfaz wireless) y vídeo, los dispositivos USB (ratón y teclado). Por último lo alimentaremos mediante el alimentador a la red eléctrica o desde un puerto USB libre de nuestro equipo. En breve deberíamos observar en la pantalla como arranca el sistema Raspbian. Al tratarse de la primera vez que la Raspberry arranca nos mostrará una ventana de configuración (Raspi-config), desde la cual podremos configurar aspectos básicos para trabajar con nuestra Raspberry (indicar que esta aplicación de configuración puede ejecutarse en cualquier momento ejecutando la aplicación “Raspi-config”):

En concreto, cabría destacar que podemos configurar los siguientes aspectos: 1) “change_locale” y “change_timezone”, nos permitirá indicar la configuración del juego de caracteres (es_ES.UTF8) y la zona horaria (Europe – Madrid). En cualquier otro momento pueden reconfigurarse ejecutando las aplicaciones “dpkg-reconfigure locales” y “dpkg-reconfigure tzdata”. Para configurar el juego de caracteres también puede modificarse el archivo del sistema “/etc/default/locale”: [root@raspberry]# nano /etc/default/locale # File generated by update-locale LANG=es_ES.UTF-8 2) “configure_keyboard”, nos permitirá configurar el teclado. En cualquier otro momento puede reconfigurarse ejecutando la aplicación “dpkg-reconfigure keyboard-configuration”. Una forma muy cómoda de configurar el teclado es modificar directamente el archivo Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 7

“/etc/default/keyboard”: [root@raspberry]# nano /etc/default/keyboard # KEYBOARD CONFIGURATION FILE XKBMODEL="pc105" XKBLAYOUT="es" XKBVARIANT="" XKBOPTIONS="" BACKSPACE="guess" 3) “ssh”, nos permitirá activar por defecto el servicio SSH, de tal forma que dicho servicio se iniciará automáticamente en los siguientes arranques. La activación SSH es fundamental para acceder y gestionar remotamente la Raspberry, y poder configurar unidades en red vía SSHFS. Ahora tan sólo necesitaremos conocer la dirección IP que tiene asignada la Raspberry: “ssh pi@dirIP_Raspberry_Pi”. 4) “boot_behaviour”, nos permite seleccionar la opción de arrancar en modo consola o en modo gráfico. Dependiendo de la finalidad para la que la se use la Raspberry convendrá más elegir una opción u otra. Por ejemplo, si queremos utilizar la Raspberry como “media center”, la opción idónea es indicar que se desea iniciar en modo gráfico (acceso al escritorio o Desktop de Raspbian). En cambio si vamos a utilizar la Raspberry como servidor, por ejemplo, como almacén de copias de seguridad, unidad de red NAS o control domótico, no tiene sentido el modo gráfico debido a los recursos que estaría consumiendo inútilmente; en ese caso seleccionaremos en modo consola. No obstante, si se elige en modo consola, en cualquier momento se puede acceder al escritorio o entorno gráfico (GUI, Interfaz de Usuario Gráfica) ejecutando el comando “startx” (por ejemplo, para realizar posteriores configuraciones de la Raspberry puede resultar más cómodo acceder a su entorno gráfico). 5) “expand_rootfs”, nos permite agrandar la partición raíz del sistema con la finalidad de aprovechar al máximo la capacidad de la tarjeta SD. Esto es necesario ya que el archivo “*.img” de la distribución Raspbian una vez volcado sobre la tarjeta SD no ocupa todo el espacio disponible, quedando una buena parte del espacio de la memoria SD sin asignar. En el caso de querer hacer varias particiones, es recomendable utilizar alguna herramienta gráfica como “gparted”, una vez ejecutado el comando “dd”, disponible en cualquier distribución GNU/Linux. En el caso de que el software “gparted” nos informe sobre algún tipo de problema al redimensionar y gestionar las particiones de la memoria SD, sería conveniente ejecutar previamente los siguientes comandos: [root@linux]# e2fsck -f /dev/sdc2 #Debe corresponderse con tu partición raiz Raspbian [root@linux]# e2fsck /dev/sdc2 [root@linux]# gparted

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 8

6) “change_pass”, cambiar la contraseña “raspberry” que viene por defecto para el usuario “pi”. Para ejecutar comandos de administración habrá que precederlos del comando “sudo”, o suplantar al usuario administrador ejecutando “sudo su”. También es conveniente asignar una password al usuario administrador “root” por si ocurriera algún desastre con nuestra cuenta habitual de usuario. Para ello: [pi@raspberry]# sudo su [root@raspberry]# passwd root

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 9

Práctica nº3.- Conexión a Internet de la Raspberry Para conectar nuestra Raspberry a Internet tenemos dos opciones: mediante la interfaz Ethernet cableada, o insertando a uno de los dos puertos USB una interfaz wireless. Por comodidad, y por las ventajas que presenta, esta segunda opción es la recomendada. A la hora de elegir entre los diferentes USB wireless que existen en el mercado podría usarse por ejemplo la “TP-LINK 150Mbps Wireless N Nano USB (chipset wn725n)” por coste y fiabilidad. Además esta interfaz wireless es detectada por el sistema Raspbian sin la necesidad de la instalación de ningún tipo de driver. Para comprobar la correcta detección de la interfaz inalámbrica por el sistema Raspbian, podemos ejecutar el comando “iwconfig”. Este nos debería mostrar por pantalla una mínima información en relación a ella (p.e. “wlan0”). En el caso de que tras pinchar el adaptador USB Wireless no lo reconozca, es conveniente echar un ojo a la siguiente documentación: http://elinux.org/RPi_VerifiedPeripherals#USB_Wi-Fi_Adapters (para saber cual es el tipo de chipset del USB Wireless ejecuta el comando “lsusb”). Los chipset no reconocidos de uso más habitual son de “zydas” y “ralink”. En estos casos se puede instalar los drivers mediante la instalación de los siguientes paquetes: 1) Si se trata de un chipset Zydas deberías instalar: [root@raspberry]$ apt-get install zd1211-firmware 2) Si se trata de un chipset Ralink deberías instalar: [root@raspberry]$ apt-get install firmware-ralink

3.1.- Configuración de la Interfaz Inalámbrica de manera gráfica (GUI) Tras reconocer nuestro sistema a nuestra interfaz inalámbrica, necesitaremos configurarla. Para ello, y por facilidad, haremos uso de la Interfaz Gráfica (GUI, Interfaz de Usuario Gráfica). Para ello, conectaremos nuestra Raspberry a un monitor, preferiblemente mediante un cable HDMI por su mayor resolución, y ejecutaremos el comando “startx”. Tras iniciarse la sesión gráfica, configuraremos la interfaz mediante las herramientas disponibles como “wpa_gui”.

3.2.- Configuración de la Interfaz Inalámbrica desde la terminal (CLUI) Tras reconocer nuestro sistema la interfaz inalámbrica, podemos configurarla sin necesidad de iniciar una sesión gráfica desde la propia Interfaz de Usuario de Línea de Comandos (CLUI) o terminal. Para ello, si suponemos que la red inalámbrica a la que deseamos conectarnos requiere de una autenticación WPA2-PSK de clave compartida seguiremos los siguientes pasos: a) Obtendremos una codificación en formato hexadecimal de la clave compartida WPA2-PSK que se requiere para conectarnos a la red inalámbrica mediante el comando “wpa_passphrase”. Esta clave codificada se utilizará a posteriori en el archivo de configuración “/etc/network/interfaces”, evitando de esta forma que la clave original pueda ser legible: Sintaxis de “wpa_passphrase”: wpa_passphrase ESSID PASSPHRASE/PASSWORD Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 10

[pi@raspberry]$ wpa_passphrase red1 1234567890 network={ ssid="red1" #psk="1234567890" psk=b8d6df971fa7795334a6f97a505a0374b63ee4e4d8391cf05feeac5687cb6cd8 } b) Editaremos el archivo “/etc/network/interfaces” para informar a nuestra Raspberry de cual es la configuración que deseamos para nuestra interfaz inalámbrica. En la directiva de configuración “wpa-psk” deberemos indicar la clave codificada suministrada en el paso anterior: [pi@raspberry]$ sudo su [root@raspberry]# nano /etc/network/interfaces auto lo iface lo inet loopback iface eth0 inet dhcp iface default inet dhcp allow-hotplug wlan0 ##iface wlan0 inet manual ##wpa-roam /etc/wpa_supplicant/wpa_supplicant.conf iface wlan0 inet static address 192.168.1.254 netmask 255.255.255.0 network 192.168.1.0 gateway 192.168.1.1 wpa-ssid "red1" wpa-psk b8d6df971fa7795334a6f97a505a0374b63ee4e4d8391cf05feeac5687cb6cd8 c) Por último tan sólo tendremos que reiniciar el servicio de red para que surtan efecto los cambios. En el pero de los casos, reiniciar la propia red. [root@raspberry]# /etc/init.d/networking restart [root@raspberry]# init 6 # Si necesitaramos reiniciar la Raspberry

3.3.- Actualización de los Repositorios y del Software del Sistema Una vez que ya tengamos conexión con Internet, es aconsejable actualizar los repositorios y el software instalado antes de instalar cualquier otro paquete software. Para ello haremos uso del comando “apt-get”: [root@raspberry]# apt-get update; apt-get upgrade ¡¡Aclaración!! Para saber más sobre la herramienta de gestión de software “apt-get” puede ejecutarse el comando “apt-get -h”, el cual nos proporciona un buen resumen de sus posibilidades, o si queremos información más detallada, podemos consultar el manual en línea “man apt-get”.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 11

Práctica nº4.- Configuración de la Raspberry como servidor DHCP. En la presente práctica se mostrará como configurar una Raspberry como servidor DHCP mediante la instalación de “dhcp3-server”, y su posterior configuración. El cliente tan sólo tendrá que solicitar una renovación de dirección IP mediante el comando “dhclient” para comprobar el correcto funcionamiento del servicio.

Antes de empezar a configurar un servidor DHCP deberemos tener claro que rango de direcciones IP dentro del rango que tengamos disponible queremos asignar (por ejemplo, 192.168.1.101-240). De igual forma, nos podrá interesar que determinadas máquinas (servidores, equipos NAS, impresoras, etc.) reciban del servidor DHCP siempre la misma dirección IP para dar un correcto servicio en la red. Dicha asignación deberemos reflejar igualmente en la configuración del servicio. Según esto, en la configuración del servicio distinguiremos dos partes: 1) Configuraremos el servidor DHCP para asignar dinámicamente direcciones IP a los clientes que lo soliciten de manera indiferente a quien haga la solicitud. Según esto el servidor asignará al equipo cliente en cuestión la primera dirección IP que tenga libre dentro del rango de asignación. 2) Configuraremos el servidor DHCP para asignar determinadas direcciones IP a determinadas máquinas en la red. Para ello necesitaremos conocer las direcciones hardware o dirección MAC de los equipos clientes DHCP que deseamos que reciban siempre la misma IP. Por ejemplo, para conocer la MAC de un equipo GNU/Linux tan sólo tendremos que ejecutar el comando “ifconfig”. [root@servidordhcp]# ifconfig eth0 eth0 Link encap:Ethernet direcciónHW e8:03:9a:ba:e9:3c Direc. inet:192.168.1.1 Difus.:192.168.1.255 Másc:255.255.255.0 Dirección inet6: fe80::c685:8ff:fe1d:d61b/64 Alcance:Enlace ACTIVO DIFUSIÓN MULTICAST MTU:1500 Métrica:1 Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0 Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0 colisiones:0 long.colaTX:1000 Bytes RX:0 (0.0 B) TX bytes:0 (0.0 B) Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 12

4.1.- Instalación del software servidor DHCP. Aunque existen otras alternativas de software para convertir a nuestra Raspberry en un servidor DHCP, para este caso práctico haremos uso del software más afamado en este área, el “dhcp3-server”: [root@servidordhcp]# apt-get install dhcp3-server

4.2.- Configuración del servicio DHCP. En primer lugar indicaremos a nuestra raspberry a través de que interfaces de red escucharemos solicitudes de renovación de dirección IP, y por tanto, a través de que interfaces de red daremos el servicio. Para ello, simplemente deberemos editar el archivo “/etc/default/dhcp3-server”, y asignar a la directiva de configuración “INTERFACES” la lista de las tarjetas de red que deseemos. Si por ejemplo, nuestra raspberry tiene una interfaz ethernet (eth0) y una inalámbrica (wlan0), y quisiéramos dar servicio por la primera, la segunda interfaz, o por ambas: [root@servidordhcp]# nano /etc/default/dhcp3-server … INTERFACES=”eth0” # INTERFACES=”wlan0” # INTERFACES=”eth0 wlan0” ... A continuación editaremos el archivo principal de configuración del servicio ubicado en “/etc/dhcp3/dhcpd.conf”, introduciendo algo similar a lo siguiente: ## PARTE Nº1 – Asignación dinámica de direcciones IP independiente del solicitante ## Indicamos la dirección de la red o subred con su correspondiente máscara en la que se encuentra el servidor DHCP subnet 192.168.1.0 netmask 255.255.255.0 { ## Establecemos el rango de direcciones IP que asignará dinámicamente el servidor range 192.168.1.101 192.168.1.240; ## Indicamos la dirección IP de la puerta de enlace o gateway, y de los servidores DNS que deberá quedar configurada en los clientes, la máscara de red o subred, y la correspondiente dirección de broadcast (la dirección IP más alta de la red o subred) option routers 192.168.1.254; option domain-name-servers 8.8.8.8, 195.55.130.247; option subnet-mask 255.255.255.0; option broadcast-address 192.168.1.255; ## Establecemos los tiempos (por defecto, y máximo) tras los cuales el cliente tendrá que hacer una renovación de dirección IP. Si transcurrido ese tiempo, el cliente no solicita renovación, el servidor entenderá que el equipo cliente esta apagado o ya no la requiere, y será libre de asignarla a otro cliente que la solicite default-lease-time 600; max-lease-time 7200; ## En el caso de que pertenezcamos a un dominio puede indicarse este option domain-name "iestiemposmodernos.es"; } Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 13

## PARTE Nº2 – Asignación dinámica de direcciones IP dependiente del equipo solicitante ## Cuando nos interese que determinados clientes DHCP reciban siempre la misma IP (servidores de la intranet/Internet, unidades de red NAS, impresoras, etc.) incluiremos un bloque similar al siguiente host servidor1 { hardware ethernet 08:00:27:ea:69:f0; fixed-address 192.168.1.250; } host nas1 { hardware ethernet 08:00:27:ad:b9:a8; fixed-address 192.168.1.251; } Tras terminar de configurar el servicio DHCP tan sólo tendremos que reiniciar el servicio para que surtan efecto los cambios introducidos en la configuración: [root@servidordhcp]# /etc/init.d/dhcp3-server restart

4.3.- Configuración de los clientes DHCP. Para comprobar el correcto funcionamiento del servicio DHCP anterior, tan sólo tendremos que solicitar la renovación de la dirección IP desde un equipo cliente mediante “dhclient” seguido de la tarjeta de red que queremos que reciba la configuración dinámica, por ejemplo, “eth0”: dirección IP, dirección IP de la puerta de enlace al exterior de la red privada y la o las direcciones IP de los servidores DNS necesarios para usar nombres de dominio. [root@clientedhcp]# dhclient eth0 En el caso de que la asignación sea efectiva: 1) Al ejecutar un comando “ifconfig eth0” deberá mostrarse la dirección IP asignada por el servidor. [root@clientedhcp]# ifconfig eth0 eth0 Link encap:Ethernet direcciónHW 08:00:27:ea:69:f0 Direc. inet:192.168.1.250 Difus.:192.168.1.255 Másc:255.255.255.0 Dirección inet6: fe80::c685:8ff:fe1d:d61b/64 Alcance:Enlace ACTIVO DIFUSIÓN MULTICAST MTU:1500 Métrica:1 Paquetes RX:0 errores:0 perdidos:0 overruns:0 frame:0 Paquetes TX:0 errores:0 perdidos:0 overruns:0 carrier:0 colisiones:0 long.colaTX:1000 Bytes RX:0 (0.0 B) TX bytes:0 (0.0 B) 2) Tras ejecutar el comando “route -n” en el equipo cliente deberá aparecer como puerta de enlace o gateway por defecto el indicado en la configuración del servicio DHCP, “option routers 192.168.1.254”: [root@clientedhcp]# route -n Destino Pasarela 0.0.0.0 192.168.1.254 192.168.1.0 0.0.0.0

Genmask 0.0.0.0 255.255.255.0

Indic Métric UG 0 U 1

Interfaz eth0 eth0

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 14

3) Si ejecutamos un “more /etc/resolv.conf” en el cliente deberían mostrarse los servidores DNS indicados en la configuración del servicio “option domain-name-servers 8.8.8.8, 195.55.130.247”: [root@clientedhcp]# more /etc/resolv.conf nameserver 8.8.8.8 nameserver 195.55.130.247 domain iestiemposmodernos.es search iestiemposmodernos.es

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 15

Práctica nº5.- Configuración de la Raspberry como servidor DNS. Otra opción interesante es configurar a la Raspberry como servidor DNS caché (en el caso de querer configurar a la Raspberry como servidor DNS maestro, convendría repasar el capítulo asociado a la implementación de este servicio). Esto nos permitiría disponer dentro de nuestra Intranet de un servidor de nombres que resolviera los nombres de dominio (p.e. “www.google.com”, “www.gmail.com”) sin necesidad de depender de un servidor externo. Su puesta en marcha nos ahorraría el ancho de banda consumido por los equipos de la Intranet a lo hora de solicitar la resolución de nombres necesaria previa al acceso de cualquiera de los servicios que se nos ocurra (HTTP, FTP, SMTP, etc.). En concreto, nuestra Raspberry al actuar como servidor DNS caché se encargará de cachear en memoria toda aquella resolución de nombres que se le solicite. En el caso de que no este cacheada la respuesta, saldrá a Internet a obtenerla, consultando directamente a los servidores DNS raíz (TNS, “Top Name Servers”). Una vez cacheada, mantendrá dicha información cacheada sin actualizar el tiempo indicado en la directiva TTL (Time To Live) que haya sido especificada en el servidor DNS maestro correspondiente al dominio consultado.

5.1.- Instalación y Configuración del servicio DNS. Para convertir nuestra Raspberry en un servidor DNS cache tan sólo será necesario instalar el software “bind9”. Además no habrá que realizar ninguna post-configuración del servicio tras su instalación ya que su comportamiento por defecto es ese, comportarse como un servidor DNS caché. [pi@servidordns]# sudo su [root@servidordns]# apt-get install bind9

5.2.- Raspberry Pi como servidor DNS Maestro. En ocasiones puede interesarnos configurar la Raspberry como servidor DNS maestro. Una situación real muy típica donde se requiere de este servicio es en la implementación de un dominio Windows mediante Samba, donde es necesario una servidor DNS maestro para que todos los equipos que forman parte del dominio tengan un nombre cualificado. A modo de ejemplo, a continuación se recordará como configurar un dominio llamado “aulainformatica.es”: 1) Editamos el fichero principal de configuración del servicio Bind9, “named.conf”, e incluimos el archivo de configuración “miszonas.conf” donde se definirá la zona “aulainformatica.es”: [pi@servidordns]# sudo su [root@servidordns]# nano /etc/bind/named.conf ... include "/etc/bind/miszonas.conf"; 2) Damos de alta la zona o dominio “aulainformatica.es” en el archivo “miszonas.conf”: [root@servidordns]# nano /etc/bind/miszonas.conf zone “aulainformatica.es” in { type master; file "/etc/bind/maestras/maestra.aulainformatica.es"; Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 16

}; 3) Editamos el archivo asociado a la zona “aulainformatica.es” indicado en la configuración de la zona anterior, “/etc/bind/maestras/maestra.aulainformatica.es”. En el deberemos registrar todos los equipos pertenecientes al dominio: [root@servidordns]# mkdir /etc/bind/maestras [root@servidordns]# nano /etc/bind/maestras/maestra.aulainformatica.es $TTL 604800 @ IN SOA localhost. root.localhost. ( 2012100501 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS nameserver nameserver IN A 192.168.1.254 ;Indicaríamos la dirección IP de la Raspberry servidorweb IN A 192.168.1.254 ;IP del servidor Web del dominio www IN CNAME servidorweb ;Definición de www como alias aulainformatica.es. IN MX 10 correo correo IN A 192.168.1.254 ;IP del servidor de correo del dominio webmail IN CNAME correo ficheros IN A 192.168.1.254 ;IP del servidor de archivos ftp IN CNAME ficheros ;Alias del servidor de archivos impresora1 IN A 192.168.1.250 ;IP de la impresora ; Identificamos a diferentes equipos dentro de varios subdominios $GENERATE 100-125 equipo$.seccion1 IN A 192.168.1.$ $GENERATE 200-225 equipo$.seccion2 IN A 192.168.1.$

5.3.- Comprobación del servicio DNS. Para comprobar el correcto funcionamiento del servicio anterior, tan sólo habrá que decirle a los equipos cliente que su servidor DNS es la dirección IP de la Raspberry. Para hacer una comprobación temporal (ya que al reiniciar la máquina o el servicio de red esta configuración se pierde) puede modificarse el fichero “/etc/resolv.conf”: [root@clientedns]# echo “nameserver dirección-IP-Raspberry” > /etc/resolv.conf A continuación, desde el cliente comprobaremos la correcta resolución de nombres haciendo uso de aplicaciones como “dig” o “nslookup”: ¡¡Importante!! El comando “dig” y “dnslookup” son unas utilidades cliente DNS proporcionadas por “bind9” que nos permite comprobar el correcto funcionamiento del servicio ofrecido por “bind9”. Para poder hacer uso de estas y otras utilidades habrá que instalar el paquete “dnsutils”: [root@clientedns|servidordns]# apt-get install dnsutils [root@clientedns]# dig www.google.com //Información detallada del nombre de dominio [root@clientedns]# dig -t MX gmail.com //Nos permite saber su Mail eXchange Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 17

[root@clientedns]# dig -t MX aulainformatica.es [root@clientedns]# dig impresora1.aulainformatica.es [root@clientedns]# dig equipo105.seccion1.aulainformatica.es [root@clientedns]# dig -t CNAME gmail.com //Nos permite saber sus alias [root@clientedns]# nslookup www.google.com

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 18

Práctica nº6.- Configuración de la Raspberry como Puerta de Enlace Una vez que nuestra Raspberry dispone de conexión con Internet, y ofrece los servicios DHCP y DNS, podemos complementarlo utilizando a esta para que otros equipos clientes de la red salgan a Internet a través de ella. Es decir, podemos hacer que nuestra Raspberry haga de gateway o puerta de enlace hacia el exterior para el resto de equipos de la red. Para la presenta práctica nos basaremos en el esquema que se muestra a continuación. Tal como se puede observar en el esquema anterior, la Raspberry dispone de dos interfaces de red, una inalámbrica, configurada previamente, y una cableada, haciendo de intermediaria entre Internet y la Intranet. En concreto, la interfaz cableada esta unida a un punto de acceso (deberá tener inhabilitado el servicio DHCP para evitar conflicto con el servicio ofrecido por la Raspberry) que permitirá a los equipos clientes inalámbricos poder comunicarse con la Raspberry, de tal forma que esta se encargará de asignarles un configuración IP a través del servicio DHCP, de resolverles nombres de dominio a través del servicio DNS y garantizarles una conexión a Internet al hacer de gateway. Al mismo tiempo, mediante el firewall “iptables” podremos controlar quien y que servicios se accede.

Para configurar a la Raspberry como puerta de enlace, tan sólo serán necesarias dos cosas: •

Activar el reenvío de paquetes TCP/IP entre las diferentes interfaces de red de la Raspberry. A esto se le suele llamar más comúnmente activar el “ip_forward”. Para ello tenemos dos opciones:

1ª Opción: Introducir un “1” el fichero virtual “/proc/sys/net/ipv4/ip_forward”. Para ello podemos ejecutar un “echo” cada vez que queramos que nuestra Raspberry funcione como gateway, o incluirlo en el script de arranque “/etc/rc.local” garantizando de esta forma que la configuración se haga automáticamente al arrancar la Raspberry: [root@gw]# echo “1” > /proc/sys/net/ipv4/ip_forward Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 19

[root@gw]# nano /etc/rc.local # Contenido del rc.local. Añadimos la siguiente línea: … echo “1” > /proc/sys/net/ipv4/ip_forward … exit 0 2ª Opción: Editar el archivo “/etc/sysctl.conf” y descomentar la línea que hace referencia al “ip_forward”: [root@gw]# nano /etc/sysctl.conf # Contenido del sysctl.conf: ... # Uncomment the next line to enable packet forwarding for IPv4 net.ipv4.ip_forward=1 … •

Activar el NAT Postrouting. Para evitar problemas de encaminamiento en los paquetes de vuelta correspondientes a solicitudes de conexión a servicios por parte de los equipos clientes de la Intranet, es conveniente que los paquetes TCP/IP generados por estos y que tratan de salir hacía el exterior/Internet, justo antes de salir de la Raspberry por su interfaz “wlan0” se modifiquen, y en campo de la cabecera de los paquetes asociado a la dirección IP de origen, aparezca la dirección IP de la Raspberry de la interfaz wlan0 y no la dirección IP privada de la Intranet. A este proceso se le denomina enmascaramiento (MASQUERADE). El no hacerlo, provocaría que tras contestar el servidor de Internet a la solicitud realizada por el cliente, al llegar al router ISP (obligatoriamente hace NAT Postrouting para que los paquetes salgan con la IP pública) este observando su tabla de enrutamiento no sabría como devolverlo al equipo cliente originario. Para su habilitación, tan sólo es necesario ejecutar el siguiente comando “iptables” (lo incluiríamos en el script “rc.local” para que se habilite la NAT nada más que arranque la Raspberry):

[root@gw]# iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE [root@gw]# nano /etc/rc.local # Contenido del rc.local. Añadimos las siguientes líneas: … echo “1” > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE … exit 0

6.1.- Configuración básica de la Raspberry como Firewall Siguiendo con la configuración como gateway de la Raspberry, sería interesante aprovecharnos de la potencia de su firewall para controlar el acceso de los clientes de la Intranet a los servicios de la Internet. Para ello pondremos un siguiente ejemplo de diseño (para saber más ver el apéndice de iptables, recopilado del libro de la Editorial Mira de los autores Arturo Martín Romero y Juanjo Martín Romero): •

Diseñar un firewall para que los equipos clientes de la Intranet puedan conectarse Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 20

únicamente a servicios HTTP, HTTPS y FTP ofrecidos en internet, exceptuando las páginas de “www.youtube.com” y “www.facebook.com”. Además al equipo de la Intranet con dirección IP 192.168.2.43 únicamente debemos permitirle el acceso a servicio HTTP, pero no HTTPS ni FTP: [root@gw]# nano /etc/rc.local # Contenido del rc.local. Añadimos las siguientes líneas: … echo “1” > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE # Reglas de filtrado: iptables -t filter -A FORWARD -d www.youtube.com -j DROP iptables -t filter -A FORWARD -d www.facebook.com -j DROP iptables -t filter -A FORWARD -s 192.168.2.43 -p tcp -m multiport --dport 20,21,443 -j DROP iptables -t filter -A FORWARD -s 192.168.2.43 -p udp -m multiport --dport 20,21,443 -j DROP iptables -t filter -A FORWARD -i eth0 -p tcp -m multiport --dport 20,21,80,443 -j ACCEPT iptables -t filter -A FORWARD -i eth0 -p udp -m multiport --dport 20,21,80,443 -j ACCEPT iptables -t filter -A FORWARD -m state --state ESTABLISHED,RELATED -j ACCEPT # Si el servidor DNS no es la Raspberry, sino que es externo deberíamos dejarles acceder a él : iptables -t filter -A FORWARD -p tcp --dport 53 -j ACCEPT iptables -t filter -A FORWARD -p udp --dport 53 -j ACCEPT iptables -t filter -P FORWARD DROP … exit 0

6.2.- Configuración de la Raspberry como Punto de Acceso (AP) Otra de las posibilidades interesantes que nos ofrece la Raspberry, gracias a su reducido consumo de potencia y reducido volumen, es hacerla trabajar como “punto de acceso” o como “repetidor”. Esto evitaría tener que disponer de un punto de acceso dedicado para el esquema práctico anterior. En concreto, tal como se muestra en la siguiente figura, haríamos uso de dos interfaces inalámbricas “wlan0” y “wlan1”.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 21

¡¡Importante!! Para poder implementar esta configuración la interfaz USB wireless que utilicéis debe soportar alguno de los modos siguientes: “mode master/repeater/ad-hoc”. En el caso de que estemos utilizando la interfaz wireless USB aconsejada en la práctica Nº3, el único modo soportado es el “ad-hoc”. Para probar su comportamiento como punto de acceso, a continuación se muestran los comandos que la configurarían para dar servicio wireless en un red inalámbrica llamada “red2”, siendo consecuentes con la figura: [pi@puntoacceso]# sudo su [root@puntoacceso]# iwconfig wlan1 mode ad-hoc [root@puntoacceso]# iwconfig wlan1 essid “red2” [root@puntoacceso]# ifconfig wlan1 192.168.2.254 [root@puntoacceso]# iwconfig wlan1 key 12345678 Tras la configuración anterior, el cliente de la Intranet recibirá la configuración IP suministrada por el servicio DHCP ofrecido por la Raspberry tras conectarse a la red inalámbrica “red2”. El rango de direcciones IP asignadas vía DHCP deberá ser del mismo rango que la que tiene la propia Raspberry en su interfaz inalámbrica “wlan1” (en el ejemplo, 192.168.2.0/24). Una vez comprobado su correcto funcionamiento, deberíamos crear un script que contenga los comandos de configuración anteriores y asegurarnos que se ejecuta al iniciarse la Raspberry. Una posibilidad sería incluir los comandos de configuración en el script de arranque “/etc/rc.local” tal como hemos hecho con la configuración del gateway y el firewall, otra crear un script con dichos comandos y enlazarlo en el directorio “/etc/rc2.d”, en el caso en que el runlevel sea el de por defecto (ejecuta el comando “runlevel” y comprueba antes que se inicia en nivel 2), o una última opción sería editar el archivo de configuración “/etc/network/interfaces” e incluir hay la configuración deseada (mirar la práctica Nº3 para más información relativa a la configuración de las interfaces de red). Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 22

[root@puntoacceso]# nano /etc/network/interfaces ... iface wlan1 inet static address 192.168.2.254 netmask 255.255.255.0 network 192.168.2.0 broadcast 192.168.2.255 wireless_essid red2 wireless_channel 6 wireless_mode ad-hoc wireless_keymode open wireless_key1 12345678 wireless_defaultkey 1 [root@puntoacceso]# /etc/init.d/networking restart

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 23

Práctica nº7.- Configuración de la Raspberry como servidor RADIUS. Siguiendo con redes inalambricas, en su implementación nos puede interesar disponer de un servdior de autenticación que controle el acceso de los equipos clientes a la red Wireless, pero no de la manera clásica, sino mediante el uso de un login y una password. Es decir, en la mayoría de las redes Wireless actuales el único requisito de acceso, independientemente de quien sea el usuario que acceda, es conocer una frase de paso o contraseña (WEP/WPA/WPA2), pero puede interesarnos que el acceso sea más personalizado: controlar quien accede mediante un login/password por usuario (no por máquina), a que servicios se le da acceso una vez autentificado, más una auditoría de todo ello. Una herramienta software que nos va a permitir, entre otras muchas opciones, gestionar la autenticación en una red inalámbrica es hacer uso de un servicio RADIUS. De esta forma, el usuario que quiera hacer uso de la infraestructura Wireless, será necesario que el servidor RADIUS le valide el login y la password introducidos por él.

7.1.- Introducción al servicio RADIUS. RADIUS (Remote Authentication Dial-In User Server) es un protocolo ampliamente empleado para controlar el acceso a servicios en red. Para ello haremos uso de un software servidor de código abierto llamado FreeRADIUS, y lo configuraremos para un uso concreto: controlar el acceso a una red inalámbrica. Dentro de esta parte práctica, lo primero que vamos a estudiar es la teoría asociada a este Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 24

protocolo, viendo también conceptos relacionados con el mismo, como AAA, NAS, y mecanismos de protección de redes inalámbricas (como WEP y WPA). Después instalaremos FreeRADIUS en nuestra Raspberry y la configuraremos como servidor para que dé servicio a los distintos puntos de acceso que pueden encontrarse en la Intranet a la que pertenece. Obviamente también tendremos que configurar el punto de acceso para que funcione como cliente del servicio ofrecido por la Raspberry. En concreto necesitaremos informar a los puntos de acceso de la dirección IP de la Raspberry, el puerto por el que da el servicio RADIUS, y una clave secreta que validará el servidor RADIUS antes de atender una solicitud de autenticación procedente de un punto de acceso. Por último, probaremos nuestra nueva configuración de la red inalámbrica conectando a dicha red una máquina cliente de la Intranet bajo GNU/Linux o Windows. En definitiva, la estructura que vamos a implementar, es una estructura cliente-servidor de doble nivel. Es decir, el equipo cliente de la Intranet solicita un servicio Wireless al punto de acceso, y este a su vez hace de cliente para el servidor RADIUS, al solicitarle la comprobación de autenticación en relación al login y passwords introducidos por el cliente de la Intranet. 7.2.- Definiciones previas: RADIUS, NAS, WEP, WPA. En este punto introduciremos diversos conceptos cuyo conocimiento es clave para poder entender cuestiones posteriores de la práctica. 7.2.1) Definición de RADIUS . RADIUS (Remote Authentication Dial-In User Server) es un protocolo que nos permite gestionar la “autenticación, autorización y registro” de usuarios remotos sobre un determinado recurso. La tupla “autenticación, autorización y registro” es más conocida como AAA, al ser éste su acrónimo de su denominación original inglesa “Authentication, Authorization, and Accounting”. Veamos a continuación a qué se refiere cada uno de estos términos: •

Autenticación (authentication) hace referencia al proceso por el cual se determina si un usuario tiene permiso para acceder a un determinado servicio de red del que quiere hacer uso. El proceso de autenticación se realiza mediante la presentación de una identidad y unos credenciales por parte del usuario que demanda acceso.

Un tipo habitual de credencial es el uso de una contraseña (o password) que junto al nombre de usuario nos permite acceder a determinados recursos. El nombre de usuario es nuestra identidad, que puede ser públicamente conocida, mientras que la contraseña se mantiene en secreto, y sirve para que nadie suplante nuestra identidad. Otros tipos más avanzados de credenciales son los certificados digitales tal como se ha visto en el servicio SSH, para crear usuarios de confianza. Existen muchos métodos concretos que implementan el proceso de la autenticación. Algunos de ellos, soportados por RADIUS, son: - Autenticación de sistema (system authentication), típica en un sistema Unix, normalmente realizada mediante el uso del fichero “/etc/passwd”. - Los protocolos PAP (Password Authentication Protocol), y su versión segura CHAP (Challenge Handshake Authentication Protocol), que son métodos de autenticación usados por proveedores de servicios de Internet (ISPs) accesibles vía PPP. - LDAP (Lightweight Directory Access Protocol), un protocolo a nivel de aplicación (sobre TCP/IP) que implementa un servicio de directorio ordenado, y muy empleado como base de datos para Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 25

contener nombres de usuarios y sus contraseñas. - Kerberos, el famoso método de autenticación diseñado por el MIT. - EAP (Extensible Authentication Protocol), que no es un método concreto sino un entorno universal de autenticación empleado frecuentemente en redes inalámbricas y conexiones punto a punto. - Freeradius también se permite la autenticación basada en ficheros locales de configuración del propio servidor RADIUS “/etc/freeradius/users”. •

Autorización (authorization) se refiere a conceder servicios específicos (entre los que se incluye la “negación de servicio”) a un determinado usuario, basándose para ellos en su propia autenticación, los servicios que está solicitando, y el estado actual del sistema. Es posible configurar restricciones a la autorización de determinados servicios en función de aspectos como, por ejemplo, la hora del día, la localización del usuario, o incluso la posibilidad o imposibilidad de realizar múltiples “logins” de un mismo usuario.

El proceso de autorización determina la naturaleza del servicio que se concede al usuario, como son: la dirección IP que se le asigna, el tipo de calidad de servicio (QoS) que va a recibir, el uso de encriptación, o la utilización obligatoria de túneles para determinadas conexiones. Los métodos de autorización soportados habitualmente por un servidor de RADIUS incluyen bases de datos LDAP, bases de datos SQL (como Oracle, MySQL y PostgreSQL), o incluso el uso de ficheros de configuración locales al servidor. No se debe confundir los términos autenticación con autorización. Mientras que la autenticación es el proceso de verificar un derecho reclamado por un individuo (persona o incluso ordenador), la autorización es el proceso de verificar que una persona ya autenticada tiene la autoridad para efectuar una determinada operación. •

Registro (accounting, a menudo traducido también como contabilidad) se refiere a realizar un registro del consumo de recursos que realizan los usuarios. El registro suele incluir aspectos como la identidad del usuario, la naturaleza del servicio prestado, y cuándo empezó y terminó el uso de dicho servicio. Es decir, auditar.

Es interesante el uso del protocolo RADIUS cuando tenemos redes de dimensiones considerables sobre las que queremos proporcionar un servicio de acceso centralizado (aunque posiblemente jerarquizado por medio de diversos servidores RADIUS). Por este motivo, uno de los principales usos de RADIUS se encuentra en empresas que proporcionan acceso a Internet o grandes redes corporativas, en un entorno con diversas de tecnologías de red (incluyendo módems, xDSL, VPNs y redes inalámbricas) no sólo para gestionar el acceso a la propia red, sino también para servicios propios de Internet (como e-mail, Web o incluso dentro del proceso de señalización SIP en VoIP). Un uso de RADIUS que queremos enfatizar mediante esta práctica con Raspberry, es la autenticación en redes inalámbricas (Wi-Fi), sustituyendo métodos más simples de clave compartida (pre-shared key, PSK), que son bastante limitados al gestionar una red cuando ésta alcanza un determinado tamaño. Aunque RADIUS es el protocolo para AAA más extendido en la actualidad, ya existe un nuevo protocolo que está llamado a sustituir a RADIUS. Su nombre es DIAMETER, y también proporciona manejo de errores y comunicación entre dominios.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 26

7.2.2) Definición de NAS . ¡¡Aclaración!! No confundir con la definición de NAS vista en otras prácticas que se harán con la Raspberry como “NAS, Network-Attached Storage”, que comúnmente se refiere a unidades de almacenamiento compartidas en red. Un Network Access Server (NAS) es un sistema que proporciona acceso a la red. En algunos casos también se conoce como Remote Access Server (RAS) o Terminal Server. En general, NAS es un elemento que controla el acceso a un recurso protegido, que puede ser desde un sencillo teléfono para VoIP o una impresora, hasta el acceso a una red inalámbrica o a Internet (proporcionado por un ISP). Cuando un cliente quiere hacer uso de uno de estos servicios se conecta a NAS, quien a su vez se conecta a un servidor de AAA (típicamente RADIUS) preguntando si las credenciales proporcionadas por el cliente son válidas. Basándose en su respuesta, NAS le permitirá acceder o no a este recurso protegido. El sistema NAS no contiene ninguna información sobre los usuarios que se pueden conectar ni sus credenciales, sino que utiliza esta información para enviarla a RADIUS, y que éste le informe sobre los permisos del cliente. Observa que nos encontramos en un escenario en el que hay dos niveles de la arquitectura cliente-servidor. Desde un punto de vista más global, tenemos la típica arquitectura en la que un usuario quiere acceder a un servicio, siendo el usuario el cliente, y el servidor el sistema que proporciona dicho servicio. Sin embargo, si nos centramos en el proceso de AAA, el cliente sería el sistema que proporciona el acceso a la red (p.e. NAS), mientras que el servidor es el sistema que autoriza o no dicho acceso (p.e. RADIUS). Como esta práctica se centra en este proceso, nosotros hablaremos de servidores RADIUS cuyos clientes son los elementos a proteger (p.e. un punto de acceso para la conexión inalámbrica). Por tanto, desde nuestro punto de vista, los usuarios que quieren acceder al recurso protegido (p.e. La persona que se desea conectar a la red inalámbrica por medio del punto de acceso), no son clientes de RADIUS sino que se denominan suplicantes. Una ventaja del uso de RADIUS es que sus clientes tan sólo tienen que implementar el protocolo de comunicación con RADIUS, y no todas las posibilidades de AAA existentes (PAP, CHAP, LDAP, kerberos, mySQL, etc.). En el ejemplo del punto de acceso, tan sólo necesitamos implementar una solución NAS que realice las consultas a RADIUS. Otra ventaja del protocolo RADIUS es que, en su comunicación con NAS, nunca transmite las contraseñas directamente por la red, lo que se conoce como en “Cleartext”, ni siquiera al usar PAP, sino que usa algoritmos para ocultar las contraseñas como MD5. Sin embargo, al no ser considerado MD5 un sistema de protección de credenciales demasiado seguro, es aconsejable utilizar sistemas adicionales de protección para cifrar el tráfico de RADIUS, como puede ser túneles de IPsec. 7.2.3) Definición de seguridad en tecnologías de red inalámbrica . En redes inalámbricas se utiliza un punto de acceso (wireless access point, WAP o simplemente AP) para interconectar todos los dispositivos inalámbricos de la red. Usualmente un AP se conecta también a una red cableada, transmitiendo datos entre los dispositivos conectados a la red cable y los dispositivos inalámbricos. La seguridad es un tema importante en las redes inalámbricas porque, al contrario que en una red cableada a la que sólo tienen acceso las personas que físicamente pueden conectarse, cualquier persona de la calle o pisos o edificios vecinos pueden conectarse a una red inalámbrica o ver el contenido de los paquetes que circulan por ella si ésta no está convenientemente protegida. Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 27

Algunos de los principales protocolos estándar para proporcionar seguridad en redes inalámbricas IEEE 802.11 son: •

•

•

WEP (Wired Equivalent Privacy). Fue introducido en 1997 con objeto de proporcionar un nivel de confidencialidad similar al de las redes cableadas. Usa una clave estática de 64 ó 128 bits con el algoritmo RC4. Su uso se desaconseja completamente, ya que aunque es muy fácil de configurar y está muy extendido al ser el primero que surgió, presenta graves fallos de seguridad. WPA (Wi-Fi Protected Access) fue creado para corregir los múltiples fallos detectados en el protocolo WEP. WPA fue diseñado por el consorcio “Wi-Fi Alliance” basándose en un borrador del estándar 802.11i (es un subconjunto del mismo), y utiliza TKIP (Temporal Key Integrity Protocol) como protocolo de cifrado que sustituye a WEP sin necesidad de modificar el hardware existente (podría funcionar actualizando el firmware). En concreto, WPA sigue usando RC4 como algoritmo de cifrado con claves de 128 bits, pero usa TKIP para cambiar dinámicamente estas claves. WPA fue diseñado para ser usado junto a un servidor AAA (habitualmente RADIUS), de manera que se le asignan claves distintas a cada uno de los posibles usuarios. Sin embargo, para entornos domésticos o pequeñas oficinas también se puede usar, de forma menos segura, con una única clave compartida (pre-shared key, PSK). En este caso hablamos de WPA-PSK. WPA2 se basa en el nuevo estándar 802.11i, y el cambio más significativo respecto a WPA es que usa el protocolo de cifrado AES en lugar de RC4. Mientras que WAP puede ejecutarse en el hardware que soporte WEP, WAP2 necesita un hardware más nuevo. Sin embargo, se sabe que WAP también terminará siendo comprometido a medio plazo y por tanto sólo se recomienda como transición a WAP2.

Otro concepto relacionado con la seguridad en redes inalámbricas que merece la pena destacar es EAP (Extensible Authentication Protocol). EAP es un marco general de autenticación, y no un mecanismo de autenticación concreto. EAP proporciona algunas funciones comunes y un método para negociar el mecanismo de autenticación a usar. Actualmente hay más de 40 métodos distintos. En esta práctica haremos uso del denominado EAP protegido (PEAP) para la autenticación de nuestro usuario en la red inalámbrica, ya que los suplicantes, equipos bajo GNU/Linux o Windows, o un móvil bajo sistema Android soportan PEAP con MSCHAPv2. 7.3.- Instalación y Configuración de FreeRADIUS. En primer lugar instalaremos el software que convertirá nuestra Raspberry en un servidor RADIUS: [pi@raspberry]# sudo su [root@raspberry]# apt-get install freeradius Después lo configuraremos en tres pasos: A) configuración de equipos clientes, B) creación de cuentas de usuario (login/password) válidas en la autenticación, y C) protocolos a usar en el proceso de autenticación. Todos los archivos de configuración necesarios los encontraremos en “/etc/freeradius”. En concreto, el archivo principal de configuración es “radiusd.conf”, y en este se encuentran incluidos el resto mediante directivas “$INCLUDE”, lo que facilita su gestión y configuración: [root@raspberry]# more radiusd.conf | grep '$INCLUDE' # $INCLUDE line. $INCLUDE proxy.conf Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 28

$INCLUDE clients.conf $INCLUDE ${confdir}/modules/ $INCLUDE eap.conf # $INCLUDE sql.conf # $INCLUDE sql/mysql/counter.conf # $INCLUDE sqlippool.conf $INCLUDE policy.conf # This next $INCLUDE line loads files in the directory that $INCLUDE sites-enabled/ A) Indicaremos al servidor quienes van a ser sus clientes. En concreto, le indicaremos quienes van a ser nuestros puntos de acceso que van a solicitarle comprobación de la autenticación del usuario. Para ello editaremos en primer lugar el archivo “/etc/freeradius/clients.conf” y añadiremos lo siguiente: [root@raspberry]# nano /etc/freeradius/clients.conf #client dirección_IP_AP_Cliente { # secret = Password_AP_acceso_servicio_RADIUS # shortname = alias_AP # nastype = other #} client 192.168.1.201 { secret = passap1 shortname = ap1 nastype = other } client 192.168.1.202 { secret = passap2 shortname = ap12 nastype = other } # Lo siguiente nos permitiría englobar a todos los AP bajo la misma clave de acceso al servicio client 192.168.1.0/24 { secret = passap s shortname = aps nastype = other } B) Daremos de alta cuentas de usuario con las que puedan validarse los usuarios de la red inalámbrica y así poder acceder al servicio. Aunque existen otro tipo de gestión de cuentas más eficiente (p.e. Mediante una BD MySQL), aquí usaremos la más simple: editar el fichero “users”. [root@raspberry]# nano /etc/freeradius/users # Cleartext-Password := # Reply-Message = "" arturo Cleartext-Password := "1234" Reply-Message = "Hola, %{User-Name}, Bienvenido!!" usuw1 Cleartext-Password := "usuwireless1" Reply-Message = "Hola, %{User-Name}, Bienvenido!!"

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 29

C) Indicaremos el protocolo de autenticación. Como ya se ha dicho previamente tanto los equipos como dispositivos móviles que funcionan bajo Windows como GNU/Linux (Ubuntu, Debian, Android, etc.) soportan PEAP con MSCHAPv2. Para ello comprobaremos la configuración que se encuentra en “/etc/freeradius/eap.conf”: [root@raspberry]# nano /etc/freeradius/eap.conf eap { ##default_eap_type = md5 | tls | ttls | ... default_eap_type = peap peap { default_eap_type = mschapv2 ... } md5 { .. } tls { .. } ttls { .. } } Por último, reiniciaremos el servicio para que surtan efecto los cambios realizados en la configuración. También tenemos la opción de arrancar el servicio en modo “debug”, ejecutando “freeradius -X”, para comprobar su correcto funcionamiento mediante la herramienta “radtest” desde un equipo cliente, haciendo uso de la password “secret” que se indico en el archivo de configuración “clients.conf” (la dirección IP del cliente debe figurar en “clients.conf”): [root@raspberry]# freeradius -X [root@cliente]# radtest [root@cliente]# radtest arturo 1234 dir_IP_Raspberry 1812 pass_secret [root@raspberry]# /etc/init.d/freeradius restart 7.3.- Configuración del punto de Acceso. En la configuración del punto de acceso deberemos indicarle los parámetros de configuración del servicio RADIUS que se soliciten: dirección IP de la Raspberry que hace de servidor RADIUS, el puerto por el que da dicho servicio, y el “secret” indicado en el fichero “clients.conf” para el punto de acceso en cuestión. Ahora ya deberíamos poder acceder a la red inalámbrica mediante una autenticación previa.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 30

Práctica nº8.- Configuración de la Raspberry como unidad de red Network-Attached Storage (NAS). A continuación se mostrará como compartir archivos en red mediante nuestra Raspberry haciendo uso de diferentes tipos de servicios. De igual forma, se indicará como controlar las operaciones de lectura y escritura mediante listas de control de acceso (ACL), y como limitar el espacio en disco ocupado por los usuarios con permisos de almacenaje (STOR) o escritura (WRITE) mediante el uso de cuotas. ¡¡Importante!! El kernel actual de Raspbian de la Raspberry no soporta la configuración de cuotas. No obstante, se muestra a continuación como se implementarían en el caso en que en un futuro sean soportadas. Para poder establecer un control el acceso mediante ACLs y limitar el espacio en disco mediante cuotas será necesario instalar previamente los paquetes siguientes: [root@linux]$ apt-get install acl quota quotatool Para asignar las cuotas se hará uso del comando “setfacl”, y para asignar las cuotas “quotatool”. A continuación se muestran algunos ejemplos (repasar el capítulo relacionado con ACLs y cuotas): [root@raspberry]# setfacl -Rm u:nombre_usuario:r-x nombre_directorio|nombre_archivo [root@raspberry]# setfacl -Rm g:nombre_grupo:--- nombre_directorio|nombre_archivo [root@raspberry]# quotacheck –ugmv /punto/de/montaje [root@raspberry]# quotaon -ugv /punto/de/montaje [root@raspberry]# quotatool -u arturo -b -q 500MB -l 700MB -i -q 100000 -l 100500 /mnt/datos En cuanto a las opciones posibles para convertir nuestra Raspberry en un servidor de archivos en red, tenemos varias, entre las cuales podríamos destacar las siguientes: 1) Configurarla como Servidor FTP. 2) Configurarla como Servidor CIFS/SMB. 3) Configurarla como Servidor SSHFS. 4) Configurarla como Servidor NFS. A modo de ejemplo (se podrían proponer infinidad de ellos), para comprender la importancia de disponer de una unidad de almacenamiento “NAS”, nos pondremos en un hipotético caso correspondiente a una red, cuyo mantenimiento esta en nuestras manos. Asumiendo, que una de las labores que debe llevar a cabo todo personal de mantenimiento es instalar, actualizar, y resolver aquellos problemas que puedan surgir con el software en cada uno de los equipos de la red, tendríamos dos posibles opciones para llevar dicha labor a cabo: 1ª) Ir con un montón de CD’s de instalación encima, correspondientes a los muchos programas que pueden resultar útiles para los equipos de la red, e ir instalando lo que corresponda en cada uno de ellos. 2ª) Disponer de un equipo en la red, que comparta todo el software de instalación anterior, y en caso Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 31

de requerirlo, conectarnos a este desde cualquier equipo de la red, descargarlo y llevar a cabo la instalación. En este caso, la máquina que nos suministra el software remotamente, se dice que esta “exportando” sus archivos al resto de la red, y que hace las funciones de “servidor” de archivos. En cambio, al equipo desde el que llevamos a cabo la “importación” y que se beneficia de la información proporcionada por el servidor, se denomina “cliente”. En definitiva, el uso de nuestra Raspberry como una unidad de red nos garantizaría entre otros beneficios: 1) Evitar redundancia de información en la red. Es decir, en una red puede suceder que varios equipos de ésta necesiten consultar ficheros comunes, con la finalidad de llevar a cabo su trabajo: realización de informes, noticias actualizadas, disponibilidad de audio y vídeo, etc. Una solución sería realizar tantas copias de la información como usuarios (equipos) la requieran, con los innumerables inconvenientes que ello supone: desperdicio de espacio al redundar la información, además de poder encontrar posibles problemas de inconsistencia. Otra solución sería ubicar toda esa información en un único equipo (o distribuida entre varios, pero sin redundancia), y que accedan a él todo aquel que lo requiera para su consulta. 2) Favorecer el mantenimiento y gestión de la red. Permite que todos los usuarios de la red guarden sus datos en un nodo central, garantizando que desde cualquier equipo de la red tengan la información disponible. Esto puede llevarse al extremo, configurando los equipos de tal forma que el “HOME” (“/home/”) de todos los usuarios de una red sea montado por NFS nuestra Raspberry. 3) Todo lo anterior puede traducirse igualmente, que en una red con múltiples equipos con una configuración muy similar, puedan compartir los ficheros de configuración, ubicándolos en un único nodo de la red, lo que favorecería el posterior mantenimiento. 4) Y todo ello nos lo permitiría nuestra Raspberry con una consumo de energía eléctrica muy reducido.

8.1.- Configuración de la Raspberry como servidor FTP. Para convertir nuestra Raspberry como servidor FTP tan sólo tendremos que instalar el software “proftpd”: [pi@raspberry]$ sudo su [root@raspberry]$ apt-get install proftpd A modo de ejemplo, a continuación se mostrará como configurar el servicio FTP para que cumpla unas especificaciones dadas: • Se ha supuesto que los ficheros servidos por la Raspberry se ubican en un disco duro externo conectado a uno de sus puertos USB, y que esta montado en “/mnt/discoftp”. • Se ofrecen 2 servicios FTP independientes mediante dos VirtualHosts, uno “no anónimo”, y otro híbrido (acceso “anónimo” y “no anónimo”). El primero se ofrecerá por el puerto por defecto, 21, y el segundo por el puerto 21000. • Suponemos que la Raspberry tiene la dirección IP “192.168.1.1”. • Las cuentas de usuario FTP no tendrán una shell válida para evitar accesos indeseados por otras vías que no sea FTP. Por ello al crear los usuarios se les asignará una shell falsa Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 32

•

•

“/bin/false”. Estas cuentas de usuario se agruparán en tres grupos “ftpg1”, “ftpg2” y “ftpg3”. Para evitar que los usuarios que accedan al servicio puedan navegar por todo el sistema de archivos del servidor, restringiremos la navegación a su HOME. Por ello, al crear los usuarios les asignaremos como directorio HOME el directorio FTP donde queramos que puedan acceder, e incluiremos la directiva “DefaultRoot ~” en la configuración del servicio. Mediante ACL y cuotas gestionaremos los permisos de los usuarios y la cantidad de espacio en disco que pueden ocupar respectivamente. A modo de ejemplo, con la finalidad de cumplir las especificaciones que aparecen en la siguiente tabla, se muestra como ejemplo los comandos necesarios para configurar una de las cuentas de usuario:

[root@raspberry]$ mkdir /mnt/discoftp/ftp1 [root@raspberry]$ cd /mnt/discoftp/ftp1 [root@raspberry]$ mkdir privado publico subidas [root@raspberry]$ groupadd ftpg1 [root@raspberry]$ useradd -d /mnt/discoftp/ftp1 -s /bin/false -g ftpg1 ftpusu1 ftpusu1 [root@raspberry]$ setfacl -m g:ftpg1:rw- /mnt/discoftp/ftp1 [root@raspberry]$ setfacl -m g:ftpg1:--- /mnt/discoftp/ftp1/privado [root@raspberry]$ setfacl -m g:ftpg1:rwx /mnt/discoftp/ftp1/publico [root@raspberry]$ setfacl -m g:ftpg1:rwx /mnt/discoftp/ftp1/subidas [root@raspberry]$ quotatool -u ftpusu1 -b -q 10MB -l 12MB -i -l 20 /mnt/discoftp VirtualHost / Auditoría

dir_IP_Raspberry Puerto 21 serftp1.raspFTP.es Auditoría: /var/ftp/serftp1

dir_IP_Raspberry Puerto 21000 serftp2.raspFTP.es

DocumentRoot

Permisos/ACL

Usuarios Permitidos / Cuotas

/mnt/discoftp/ftp1 /mnt/discoftp/ftp1/privado /mnt/discoftp/ftp1/publico /mnt/discoftp/ftp1/subidas

Leer Leer/Stor Leer/Escribir

Usuarios: “profesor” Grupos: “ftpg1” (“ftpusu1”, “ftpusu2”) Cuota : 10MB/12MB - 20 files

/mnt/discoftp/ftp1 /mnt/discoftp/ftp1/privado /mnt/discoftp/ftp1/publico /mnt/discoftp/ftp1/subidas

Leer Leer/Escribir Leer Leer/Stor

Grupos: “ftpg2” (“ftpusu3”, “ftpusu4”) Cuota: 650MB/700MB - 220 files

/mnt/discoftp/anonimo /mnt/discoftp/anonimo/publico /mnt/discoftp/anonimo/privado /mnt/discoftp/anonimo/subidas

Leer Leer/Escribir Leer/Stor

Anónimo (suplantar a un usuario llamado “anonimo”) Cuota: 695MB/730MB - 1999 files

/mnt/discoftp/anonimo /mnt/discoftp/anonimo/publico /mnt/discoftp/anonimo/privado /mnt/discoftp/anonimo/subidas

Leer/Stor Leer/Escribir Leer/Escribir Leer/Escribir

Usuarios: “profesor” Grupos: “ftpg3” (“ftpusu5”, “ftpusu6”) Cuota: 50MB/62MB - 800 files

Auditoría: /var/ftp/serftp2

En cuanto a la configuración del servicio FTP propiamente dicha, en lugar de modificar el archivo “/etc/proftpd/proftpd.conf”, crearemos uno propio y lo incluiremos en este: [root@raspberry]$ nano /etc/proftpd/proftpd.conf Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 33

# Introducimos al comienzo del archivo el siguiente “include”: Include /etc/proftpd/miservicioftp.conf … # Resto del contenido del archivo /etc/proftpd/proftpd.conf [root@raspberry]$ nano /etc/proftpd/miservicioftp.conf # Contenido de “/etc/proftpd/proftpd.conf/miservicioftp.conf” Port 21 Requirevalidshell off DefaultRoot ~ AllowUser profesor AllowGroup ftpg1 AllowGroup ftpg2 DenyAll DenyAll AllowUser profesor AllowGroup ftpg1 DenyAll DenyAll AllowGroup ftpg2 DenyAll AllowGroup ftpg2 AllowGroup ftpg1 AllowUser profesor DenyAll Port 21000 Requirevalidshell off Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 34

DefaultRoot ~ AllowUser profesor AllowGroup ftpg3 DenyAll AllowAll AllowAll AllowAll AllowAll Denyall Requirevalidshell off User anonimo Useralias anonymous anonimo DenyAll AllowAll AllowAll DenyAll Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 35

DenyAll

8.2.- Configuración de la Raspberry como servidor CIFS/SMB. CIFS/SMB es uno de los protocolos más utilizados tanto por redes Windows como GNU/Linux a la hora de implementar unidades en red. Por tanto, la configuración de nuestra Raspberry como servidor de archivos compartidos en formato CIFS/SMB garantizará que una red híbrida compuesta por equipos con sistema operativo Windows, GNU/Linux, o dispositivos móviles con sistema operativo Android, iPhone iOS o Windows Mobile, puedan acceder a los archivos compartidos sin muchas complicaciones. Para configurar nuestra Raspberry en un servidor CIFS/SMB será necesario instalar el paquete “samba”: [pi@raspberry]# sudo su [root@raspberry]# aptitude search samba # Para conocer paquetes relacionados con samba [root@raspberry]# apt-get install samba samba-common samba-common-bin A continuación tan sólo deberemos configurar el servicio adecuadamente. Para ello editaremos el archivo de configuración “/etc/samba/smb.conf”. Este archivo esta dividido en secciones acotadas por un encabezamiento entre corchetes, “[nombre_sección]” que la identifica. La sección más importante es “[global]” al contener las directivas de configuración generales. Dicha sección sólo habrá que editarla en el caso en que deseemos modificar su comportamiento: configurarlo como PDC, indicar por que interfaces de red dar servicio, nombre NetBios del equipo, etc. ¡¡Aclaración!! Para saber más sobre la sección [global] mirar el apéndice asociado a Samba. En el caso de querer crear una nueva unidad de red accesible para el resto de equipos de la red (Intranet e Internet) que tengan acceso a la Raspberry, tan sólo será necesario crear una nueva sección con el nombre que le queramos dar a la unidad de red, junto a una serie de directivas de configuración que personalizarán los permisos en el acceso. A continuación se muestran dos ejemplos: Recurso Compartido

Usuarios Permitidos (LOGIN)

Path – Ruta del recurso

Permisos

recursogeneral

Todos

/mnt/disco2/publico

lectura

recursoespecial

gruposamba (ususamba1, ususamba2, ususamba3)

ususamba3: lectura /mnt/disco2/privado

ususamba1, ususamba2: lectura y escritura

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 36

Ejemplo de configuración de SAMBA (archivo “smb.conf”): [root@raspberry]$ nano /ect/samba/smb.conf … # Al final de una de las secciones de samba, [nombre-seccion], introducimos lo siguiente: [recursogeneral] path = /mnt/disco2/publico # Ruta del recurso a compartir por Samba read only = yes # Recurso de sólo lectura. No se permite la escritura browseable = yes # Será visible en el entorno de red guest ok = yes # Permiso de acceso como cuenta de invitado: nobody/nogroup public = yes # Permiso de acceso a Todos – Permiso de acceso Anónimo: nobody/nogroup [recursoespecial] path = /mnt/disco2/privado read only = yes # Recurso de sólo lectura. Sólo permite escritura a “write list” write list = ususamba1 ususamba2 max connections = 10 browseable = yes guest ok = no public = no # Permiso de acceso No Anónimo. Sólo accederán autenticandose “valid users” valid users = @gruposamba # Usuarios con posibilidad de acceso (LOGIN) En relación a la configuración de este último recurso compartido por samba “recursoespecial” aclarar que al tratarse de un recurso “no anónimo” (no se permite acceso público), hay que dar de alta las cuentas de usuario del sistema dentro del sistema Samba. Es decir, una cuenta de usuario del sistema, por defecto no es usuario del servicio Samba, y por tanto, al tratar de acceder a un recurso compartido no anónimo por samba no se puede autentificar con el “login” y “password” con los que inicia sesión normalmente en el sistema. Para dar de alta un nuevo usuario Samba ejecutaremos el siguiente comando “smbpasswd”: [root@raspberry]# smbpasswd -a ususamba1 [root@raspberry]# smbpasswd -a ususamba2 [root@raspberry]# smbpasswd -a ususamba3 La opción “-a” (add) del comando “smbpasswd” permite añadir un usuario del sistema al servicio Samba. Al ejecutarlo, nos pedirá una password. Dicha password haremos que sea la misma que utiliza el usuario para iniciar sesión en el sistema, y así de esta forma, el usuario hará uso de una única password para todo (cuando inicie sesión vía SSH o al acceder al recurso compartido). ¡¡Importante!! En relación a los privilegios o permisos de lectura y escritura concedidos vía Samba, tenemos que tener clarísimo que dichos permisos deben ser congruentes con los asignados a nivel de sistema de ficheros. Es decir, si vía Samba permitimos la escritura a un usuario sobre un recurso compartido, y a nivel de sistema de archivos este usuario no tiene permisos de escritura, no escribirá. Por tanto, será necesario programar las ACLs (mirar apéndice correspondiente a ACLs) correspondientes: [root@raspberry]$ setfacl -Rm g:ususamba1:rwx /mnt/disco2/privado [root@raspberry]$ setfacl -Rm g:ususamba2:rwx /mnt/disco2/privado [root@raspberry]$ setfacl -Rm g:ususamba3:r-x /mnt/disco2/privado Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 37

Una vez configurado Samba, podemos comprobar si hemos cometido algún error sintáctico al escribir las directivas de configuración ejecutando “testparm”. Este comando nos informará en el caso de que encuentre problemas al procesar alguna de las secciones o recursos compartidos. En caso de que este correcto, tan sólo será necesario reiniciar el servicio: [root@raspberry]$ testparm [root@raspberry]$ /ect/init.d/samba restart Para conectarse a la unidad de red compartida desde el cliente existen multitud de alternativas dependiendo del sistema operativo. Por ejemplo: •

•

Windows: colocando en la barra de direcciones del explorador de archivos la ruta “\\dirección_IP_Raspberry\nombre_recurso”, o haciendo uso del asistente gráfico de conexión con una unidad de red. GNU/Linux: ejecutando el comando “mount -t cifs”.

[root@cliente]$ mount –t cifs //dirección_IP_Raspberry/nombre_recurso /punto_montaje \ -o username=”nombre_usuario”,password=”pass_usuario”

8.3.- Configuración de la Raspberry como servidor SSHFS. Una de las opciones más atractivas que ofrece el servicio SSH es la posibilidad de crearnos una unidad de red remota donde todos los archivos viajan de manera segura (cifrados) entre el cliente y el servidor. Para ello, lo primero será instalar en el equipo cliente el software que permitirá hacer uso de este tipo de sistema de archivos: “sshfs” (ssh file system). [root@cliente]# apt-get install sshfs Ahora ya podríamos crear una unidad de red SSH donde los contenidos que contenga será los que haya en la Raspberry en el directorio indicado. Por ejemplo, si suponemos que el la Raspberry se ha creado previamente un usuario llamado “arturo”: [usuario@cliente]$ mkdir /home/usuario/docs-remotos [usuario@cliente]$ sshfs arturo@IP_Raspberry:/home/arturo/Documentos ~/docs-remotos Al intentar establecer la conexión, nos pedirá o no la contraseña del usuario remoto “arturo” en función de si el usuario que trata de acceder es de confianza o no. Para que el usuario sea un usuario de confianza tan sólo habrá que ejecutar los siguientes comandos: [usuario@cliente]$ ssh-keygen [usuario@cliente]$ ssh-copy-id -i ~/.ssh/id_rsa.pub arturo@IP_Raspberry (si no existe el subdirectorio “.ssh” dentro del HOME del usuario de la Raspberry “arturo”, y dentro de él, el archivo “authorized_keys”, el comando “ssh-copy-id -i” lo hará automáticamente) A partir de este momento dispondremos de una unidad de red, carpeta “docs-remotos”, donde todo lo que hagamos en ella viaja entre el equipo cliente y nuestra Raspberry de manera segura.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 38

En el caso de querer desmontar la unidad de red ejecutaremos el siguiente comando: [usuario@cliente]$ fusermount -u ~/docs-remotos ¡¡Aclaración!! Para saber más sobre el servicio SSH, o querer que el montaje se realice de manera automática tras iniciar sesión en el equipo cliente consultar el apéndice correspondiente a SSH.

8.4.- Configuración de la Raspberry como servidor NFS. El sistema de archivos “NFS” (“Network File System”, Sistema de Ficheros en Red) es la solución clásica adoptada por los sistemas operativos UNIX/GNU Linux para compartir archivos en redes TCP/IP. Su historia se remonta a 1984, año en que la empresa SUN Mycrosystems implementa esta tecnología para compartir información dentro de la red. Además, gracias a que SUN lo implemento bajo licencia gratuita para la industria, provoco que se consolidará como un estándar a la hora de compartir archivos en red.

Por tanto, “NFS” es un sistema de archivos virtual que permite que en una red bajo UNIX/GNU Linux podamos compartir la información entre todos los equipos que la forman. Se denomina virtual, porque una vez que hemos “montado” o conectado a la unidad de red remota, el usuario del equipo cliente, tiene la impresión de que la unidad con todos sus archivos es propia del equipo. El gran inconveniente que presenta este sistema de archivos es que el permiso de acceso a los recursos compartidos se hace por dirección IP, sin necesidad de autenticarse (login/password) o de mostrar credenciales (certificado del cliente que asegure que es quien dice ser). Para evitar confusiones, sería importante recalcar que aunque en la figura anterior de la impresión de que la estructura de la red sea del tipo cliente-servidor, no es cierto, ya que está estrategia en realidad es de tipo “peer-to-peer”, donde todo equipo de la red puede ser cliente y servidor al mismo tiempo. Es decir, se trata de una estrategia deslocalizada o descentralizada de la información. Para convertir nuestra Raspberry en un servidor NFS deberemos instalar el software siguiente: [root@raspberry]# apt-get install nfs-kernel-server ¡¡Aclaración!! Se puede comprobar que antes de instalar el software anterior, nuestro equipo servidor no soporta sistema de archivos NFS, y por tanto, no esta preparado para dar dicho servicio: Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 39

[root@raspberry]# more /proc/filesystems | grep nfs Una vez instalado, veremos que el resultado de la ejecución del comando anterior, ya no reporta algo: [root@raspberry]# apt-get install nfs-kernel-server [root@raspberry]# more /proc/filesystems | grep nfs nodev nfs nodev nfs4 nodev nfsd Una vez instalado el software servidor, pasaremos a configurar el servicio indicando que directorios queremos exportar o compartir a la red. Para ello editaremos el fichero “/etc/exports” para que cumpla las especificaciones de compartición indicadas en la siguiente tabla: Path Recurso Compartido

Equipos Permitidos

Permisos

/home/arturo/datos

192.168.1.1 192.168.1.2 192.168.2.0/24

192.168.1.1 => rw (read/write) 192.168.1.2 => ro (read only) 192.168.2.0/24 => (read/write)

/mnt/disco2

Todos

ro (read only)

[root@raspberry]# nano /etc/exports # () /home/arturo/datos 192.168.1.1(rw,no_root_squash) 192.168.1.2(ro,no_root_squash) /home/arturo/datos 192.168.2.0/24(rw) /mnt/disco2 (ro) Para que los cambios realizados en el fichero de configuración surtan efecto deberemos reiniciar el servicio o ejecutar alguno de los siguientes comandos: [root@raspberry]# /etc/init.d/nfs-kernel-server restart [root@raspberry]# exportfs -a # Exporta todos (all) los directorios indicados en /etc/exports [root@raspberry]# exportfs -r # ReExporta los directorios de /etc/exports y los sincroniza Por último, el equipo cliente deberá montar la unidad de red exportada por el servidor, mediante la ejecución del comando “mount” o de manera automática mediante “/etc/fstab”. Antes deberá instalar el software “nfs-common” para poder reconocer el sistema de archivos NFS: •

Desde una terminal:

[root@cliente]# apt-get install nfs-common [root@cliente]# cd [root@cliente]# mkdir /mnt/datos-remotos [root@cliente]# mount -t nfs dir_IP_Raspberry:/home/arturo/datos /mnt/datos-remotos •

Mediante el “/etc/fstab”:

[root@cliente]# apt-get install nfs-common Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 40

[root@cliente]# nano /etc/fstab # Línea a añadir en el fstab: dir_IP_Raspberry:/home/arturo/datos /mnt/datos-remotos nfs auto,user,rw ¡¡Aclaración!! Para saber más sobre el servicio NFS mirar el apéndice correspondiente.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 41

Práctica nº9.- Configuración HTTP/HTTPS.

de

la

Raspberry

como

servidor

A continuación veremos como configurar nuestra Raspberry como servidor Web mediante la ayuda del software más afamado en este sentido: “Apache”. Concretamente la configuraremos para dar un servicio en modo seguro, HTTPS. Posteriormente haremos uso de él en la última parte de las prácticas correspondiente al control domótico vía Web. [pi@raspberry]# sudo su [root@raspberry]# apt-get install apache2 Además para garantizar un servicio seguro confiable por el usuario final, crearemos en primer lugar una entidad certificadora que se encargará a posterior de certificar que el servicio HTTPS lo ofrece quien dice ser que lo hace.

9.1.- Creación de la Entidad Certificadora (CA). Para crear una CA tan sólo necesitaremos crear una pareja de claves asimétricas (clave pública y privada), y el certificado auto firmado por la propia entidad CA con todos sus datos. Antes deberemos instalar el software “openssl”: [pi@raspberry]# sudo su [root@raspberry]# apt-get install openssl Después crearemos un directorio donde almacenaremos las claves y el certificado auto firmado, el cual deberemos importar desde el navegador web para poder confiar en todos los servicios que sean certificados por ella: [root@raspberry]# mkdir /etc/apache2/ca [root@raspberry]# cd /etc/apache2/ca [root@raspberry]# openssl genrsa -out ca.pem 2048 [root@raspberry]# openssl req -new -x509 -key ca.pem -out cacert.pem -days 1000

9.2.- Creación de las claves y certificados del servicio HTTPS. Con la finalidad de que los usuarios finales que acceden desde su navegador Web al servicio HTTPS confíen en el servicio, y se atrevan a introducir datos confidenciales (“login” y “password”, códigos, etc.) necesitaremos crear un par de claves asimétricas, y una solicitud de certificado con nuestros datos para que sea firmada por la CA: [root@raspberry]# mkdir /etc/apache2/server [root@raspberry]# cd /etc/apache2/server [root@raspberry]# openssl genrsa -out server.pem 2048 [root@raspberry]# openssl req -new -key server.pem -out servercert.p10 ¡¡Importante!! Entre los datos importantes introducidos al crear la solicitud de certificado del servidor Web, el más importante es el “Common Name”, el cual debe corresponderse con el nombre de dominio cualificado (FQDN) asociado al servicio web que se quiere dar. Por ejemplo, “www.miservicioweb.es”. Por ello, configuraremos el servicio DNS dando de alta la zona o Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 42

nombre de dominio deseado (p.e. “miservicio.es”), junto con el nombre del equipo correspondiente (p.e. “www.miservicio.es”). Por último, la CA firmará la solicitud anterior generando el correspondiente certificado: [root@raspberry]# openssl x509 -req -in servercert.p10 -out servercert.pem \ -CA ../ca/cacert.pem -CAkey ../ca/ca.pem -CAcreateserial -days 365

9.3.- Configuración de Apache para dar un servicio HTTPS. ¡¡Aclaración!! Para saber más sobre el servicio Apache y su configuración, consultar el apéndice asociado a este servicio. Antes de configurar Apache estableceremos las especificaciones que debe cumplir dicho servicio. Con la finalidad de aprender sobre Apache al mismo tiempo que se realiza la práctica se establecerán el mayor número de especificaciones posibles: 2 virtualhost, secciones anónimas y no anónimas (autenticación básica mediante una base de datos DB/SDBM o de tipo digest mediante un fichero plano), userdir (usuarios del sistema que pueden publicar contenidos desde su HOME), alias, etc. VirtualHost Direcciones IP Puertos

URL del Servicio Directorio Raíz del Servicio Página de Inicio

dir_IP_Raspberry 80 443

servicio1.miservidor.es /var/www/misite1 my-site1.html

dir_IP_Raspberry 443

servicio2.miservidor.es /var/www/misite2 my-site2.html

Acceso Usuarios Alias UserDir (~/myweb) Anónimo ususeguro1, ususeguro2, ususeguro3 Anónimo con secciones no anónimas (un directorio y un archivo) ususeguro1, ususeguro2

otrospdf /mnt/disco2/pdf otrospdf /mnt/disco2/pdf otrosdoc /mnt/disco2/doc

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 43

Con la finalidad de cumplir las especificaciones anteriores, seguiremos los siguientes pasos para su correcta configuración: 1) Crearemos un fichero de configuración auxiliar en “sites-available” (p.e. ejemplo1.conf), 2) habilitaremos el fichero de configuración anterior, 3) habilitaremos los módulos que no estén precargados en la instalación y que sean necesarios para su correcto funcionamiento funcionamiento, 4) editaremos el fichero “ports.conf” para verificar que Apache escucha por los puertos deseados, dando servicio a más de un sitio Web bajo la misma IP, 5) crearemos la base de datos para la autenticación básica de usuarios Apache, 6) crearemos el fichero de usuarios de apache para la autenticación digest y 7) reiniciaremos el servicio para que surtan efecto todos los cambios. Se da por hecho que la estructura del sitio Web ya ha sido realizada a parte. 1) Creación del fichero de configuración asociado al servicio que queremos dar: [root@raspberry]# nano /etc/apache2/sites-available/ejemplo1.conf # Especificación del primer virtualhost ServerName servicio1.miservidor.es DocumentRoot /var/www/misite1 DirectoryIndex my-site1.html Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 44

Userdir /home/*/myweb Userdir enabled ususeguro1 ususeguro2 ususeguro3 Userdir disabled Allow from all SSLEngine on SSLCipherSuite RSA:+HIGH:+MEDIUM SSLProtocol all -SSLv2 SSLCertificateFile /etc/apache2/server/servercert.pem SSLCertificateKeyFile /etc/apache2/server/server.pem SSLCACertificateFile /etc/apache2/ca/cacert.pem Allow from all Alias /otrospdf /mnt/disco2/pdf # Especificación del segundo virtualhost ServerName servicio2.miservidor.es DocumentRoot /var/www/misite2 DirectoryIndex my-site2.html Userdir /home/*/myweb Userdir enabled ususeguro1 ususeguro2 Userdir disabled Allow from all SSLEngine on SSLCipherSuite RSA:+HIGH:+MEDIUM SSLProtocol all -SSLv2 SSLCertificateFile /etc/apache2/server/servercert.pem SSLCertificateKeyFile /etc/apache2/server/server.pem SSLCACertificateFile /etc/apache2/ca/cacert.pem Allow from all Alias /otrospdf /mnt/disco2/pdf Alias /otrosdoc /mnt/disco2/doc AuthType Basic AuthName “No Anónima 1” AuthDBMType SDBM AuthDigestProvider dbm AuthDBMUserFile /etc/apache2/control/access.db Require user access1 access3 AuthType Digest AuthName “No Anónima 2” Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 45

AuthDigestProvider file AuthUserFile /etc/apache2/control/access.dat Require valid-user 2) Habilitaremos el fichero de configuración anterior para que sea tenido en cuenta en el próximo reinicio del servicio: [root@raspberry]# a2ensite ejemplo1.conf 3) Habilitaremos los módulos de Apache necesarios para poder ofrecer un servicio seguro (módulo ssl) y para permitir que determinados usuarios puedan publicar contenidos Web desde su HOME (módulo userdir). [root@raspberry]# a2enmod ssl [root@raspberry]# a2enmod userdir 4) Editaremos el archivo “ports.conf” e incluiremos la directiva “NameVirtualHost”, al hacer uso de la misma dirección IP de la Raspberry y puerto (80/443) en más de un sitio Web habilitado en Apache: [root@raspberry]# nano /etc/apache2/ports.conf … NameVirtualHost dir_IP_Raspberry:80 NameVirtualHost dir_IP_Raspberry:443 … 5) Crearemos la base de datos con los usuarios con permiso para acceder a la sección no anónima “No Anónima 1”. Para ello haremos uso del comando “htdbm” el cual nos pedirá la password del usuario que deseamos crear (la opción “-c” crea la base de datos, luego hay que quitarla para añadir nuevos usuarios): [root@raspberry]# htdbm -TSDBM -c /etc/apache2/control/access.db access1 [root@raspberry]# htdbm -TSDBM /etc/apache2/control/access.db access2 [root@raspberry]# htdbm -TSDBM /etc/apache2/control/access.db access3 6) Crearemos el fichero de usuarios con permiso para acceder a la sección no anónima “No Anónima 2” tipo digest. Para ello haremos uso del comando “htdbm”: [root@raspberry]# htdigest -c /etc/apache2/control/access.dat “No Anónima 2” access4 [root@raspberry]# htdigest /etc/apache2/control/access.dat “No Anónima 2” access5 [root@raspberry]# htdigest /etc/apache2/control/access.dat “No Anónima 2” access6 7) Por último reiniciaremos el servicio: [root@raspberry]# /etc/init.d/apache2 restart

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 46

Práctica nº10.- Configuración de la Raspberry como Proxy HTTP. En esta práctica configuraremos nuestra Raspberry como servidor proxy HTTP caché. Al igual que cuando la configuramos como servidor DNS caché, los beneficios ahora son claros. En el caso del servidor DNS Caché, nuestra Raspberry almacenaba en memoria las resoluciones DNS directas o inversas (Nombre DNS FQDN con su correspondiente dirección IP) durante el “Time To Live” (TTL) indicado en la definición de la correspondiente zona maestra del dominio solicitado, evitando de esta forma tener que salir a Internet a buscar la correspondiente resolución del nombre a IP cada vez que un cliente lo requiere, optimizando de esta manera el ancho de banda consumido.

Al igual que el servidor DNS Caché, el proxy HTTP Caché almacenará en memoria las distintas páginas Web solicitadas por los clientes, evitando de esta forma tener que salir a Internet a buscar los documentos Web en el caso de que los tenga cacheados debido a solicitud previa equivalente. Además el servidor proxy, al mismo tiempo que ofrece el servicio anterior, nos va a permitir: Controlar tanto desde que equipos clientes se permite el acceso a Internet, como a que equipos servidores web esta permitida la conexión, como si se tratara de un firewall. 2. Controlar la franja horaria en la que esta permitida el acceso al servicio web. 3. Obligar a los usuarios que hacen uso del servicio a una autenticación previa. 4. Filtrar URLs y contenidos evitando que los usuarios puedan conectarse a determinados sitios Web. 1.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 47

5.

Informar mediante ficheros de auditoría tanto de los accesos realizados desde los clientes, como de los contenidos solicitados.

Para ello el proxy será necesario definir listas de control de acceso (ACLs) mediante la directiva “acl”, y posteriormente tomar la decisión de permitir o denegar mediante la directiva “http_access”. De manera resumida, destacaríamos los siguientes tipos de ACL: Sintaxis directiva “acl”: acl nombre-acl tipo-acl descripción|fichero-descripciones Sintaxis directiva “http_access”: http_access allow|deny nombre-acl Tipo ACL src

Significado

Ejemplo de ACL

Source. Permite hacer referencia a un acl intranet src 192.168.1.0/24 conjunto de equipos clientes http_access allow intranet

Source Domain. Hace alusión a un equipo cliente basándonos en su nombre acl eq1 srcdomain equipo1.intranet.es srcdomain de dominio. Para la comprobación se http_access deny eq1 requiere resolución inversa dst

Destination. Hace alusión a un equipo acl server dst 192.168.1.200 destino http_access deny server

dstdomain Destination Domain

time

acl google dst www.google.com

Permite especificar una franja horaria. La sintaxis es: acl nombre-acl [días] [h1:m1-h2-m2] acl horario1 M T W H F 9:00-18:00 Los días se especifican con la abreviatura acl finde A S 9:00-13:00 del día en inglés: M (monday), T http_access allow horario1 finde (tuesday), W (wednesday), H (thursday), F (friday), A (saturday) y S (sunday).

Permite utilizar expresiones regulares para hacer alusión a URL completas. Para repasar las expresiones regulares os acl multimedia url_regex -i mp3$ mp4$ remito a url_regex acl videos url_regex youtube “http://es.wikipedia.org/wiki/Expresi http_access deny multimedia videos %C3%B3n_regular”. La opción “-i” le indica que no distinga entre mayúsculas y minúsculas

10.1.- Configuración previa del Entorno de Red Antes de empezar ya con la práctica, si observamos el esquema anterior, podremos advertir que la Raspbery hace las veces de puerta de enlace o gateway de las Intranet cableada e inalámbrica hacía la Internet, hace de servidor DNS caché para los equipos de las Intranet, hace servidor DCHP y hace de proxy HTTP. Además, con la finalidad de hacer una división lógica (que no física) entre la Intranet cableada, y el segmento de red correspondiente al router ISP, se asignará a la Raspberry una interfaz de red virtual con una dirección de red del rango 192.168.2.0/24. Para todo ello recordamos que habrá que hacer lo siguiente, a excepción de la configuración como proxy HTTP que la veremos a continuación: a) Para que haga de gateway, activaremos el “ip_forward” para que puedan reenviarse paquetes Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 48

TCP/IP entre las diferentes interfaces de red, y habilitaremos la NAT POSTROUTING para que todos los paquetes que atraviesen a la Raspberry hacia el exterior lo hagan con la dirección de origen cambiada por la de su interfaz eth0 192.168.1.1. Todo ello puede programarse en el “/etc/rc.local” que se ejecuta al arrancar la Raspberry: [root@raspberry]# nano /etc/rc.local ... #Añadimos la siguientes líneas: echo “1” > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE exit b) Para que haga de servidor DNS caché simplemnente haremos lo indicado en la práctica Nº5 del siguiente documento, que básicamente se reduce a dos pasos: instalar “bind” en la Raspberry, y configurar en los clientes a la Raspberry como servidor DNS predeterminado. [root@raspberry]# apt-get install bind9 [root@cliente]# echo “nameserver dir_IP_Raspberry” > /etc/resolv.conf c) Para convertir la Raspberry en un servidor DHCP tan sólo tendremos que seguir las explicaciones de la práctica Nº4 del presente documento. Importante advertir, que para poder asignar direcciones IP vía DHCP dentro de un rango de IPs, debemos haber asignado previamente una de dicho rango a la propia Raspberry. d) Para asignar una interfaz de red virtual a la Raspberry a se puede hacer simplemente ejecutando el correspondiente comando “ifconfig eth0:redprivada 192.168.2.1” con el inconveniente que ser pierde dicha configuración al reiniciar el equipo, o modificar el archivo de configuración “/etc/network/interfaces” y reiniciar el servicio “networking” para que surtan efecto los cambios: [root@raspberry]# ifconfig eth0:redprivada 192.168.2.1 [root@raspberry]# nano /etc/network/interfaces auto lo iface lo inet loopback auto eth0 iface eth0 inet static address 192.168.1.1 netmask 255.255.255.0 gateway 192.168.1.254 auto eth0:red1 iface eth0:redprivada inet static address 192.168.2.1 netmask 255.255.255.0 [root@raspberry]# /etc/init.d/networking restart ¡¡Aclaración!! El nombre de la interfaz virtual “eth0:nombre” puede ser el que uno desee.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 49

10.2.- Instalación del software servidor. Para configurar nuestra Raspberry como servidor proxy HTTP instalaremos el software más afamado en ello, “squid”: [pi@raspberry]# sudo su [root@raspberry]# apt-get install squid3

10.3.- Configuración de la Raspberry como proxy no transparente. La primera configuración proxy que haremos será la de proxy no transparente. Esto significa que el usuario final o cliente web debe saber que para poder navegar a través de Internet necesita atravesar un equipo en la red que hace de intermediario entre él y el servidor al que trata de acceder llamado proxy, y que este controla en todo momento que es posible hacer. En concreto, el cliente requerirá configurar su navegador para informarle de la dirección IP del proxy y de su puerto de servicio a su navegador. A modo de ejemplo, el proxy caché HTTP a implementar cumplirá las siguientes características: Directorio Caché Puertos de Servicio Cantidad Memoria RAM

Autenticación

Tamaño Caché Webs no permitidas Nº Directorios y Subdirectorios

Auditoria Caché

Tamaño máximo de archivo a cachear /var/spool/squid3 3128 y 8088

1GB

32 MB

16/256 128MB

Usuarios permitidos Equipos permitidos y no permitidos Auditoria acceso

www.marca.com www.sport.es www.as.com *youtube* *porn* *sex* cache_log /var/log/squid3/cache.log

Sí usuproxy1, usuproxy2 y usuproxy3 192.168.2.0/24 a excepción del 192.168.2.100 access_log /var/log/squid3/access.log

Para ello, modificaremos el archivo de configuración del servicio “squid.conf” (podemos editarlo de cero): [root@raspberry]# cd /etc/squid [root@raspberry]# mv squid.conf squid-anterior.conf [root@raspberry]# nano squid.conf # Directivas globales # Nombre del servidor proxy visible en los mensajes informativos enviados al cliente Web: visible_hostname rasproxy # Puertos de servicio del proxy. Podemos hacer que escuche por más de un puerto simultánemente: Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 50

http_port 3128 http_port 8088 # Datos de la Cache: ## Ruta absoluta del directorio donde se cachearán los sitios Web visitados, su tamaño 1000MB, y el número de directorios (16) y subdirectorios (256) cache_dir ufs /var/spool/squid3 1000 16 256 ## Cantidad de memoria RAM que reservamos para este servicio proxy HTTP (p.e.): 32 MB cache_mem 32 MB # Cuidado, debe haber un espacio entre el “32” y el “MB”!!! ## Máximo tamaño del archivo que una vez descargado será cacheado (p.e.): 128 MB maximum_object_size_in_memory 128 MB # Archivos de auditoría en relación con los accesos y contenidos visitados: access_log /var/log/squid3/access.log cache_log /var/log/squid3/cache.log # Autenticación de usuarios: ## Método de autenticación: ncsa_auth, y archivo de usuarios y contraseñas: claves.dat auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/claves.dat ## Cantidad de procesos involucrados en la autenticación auth_param basic children 5 ## Nombre realm identificativo auth_param basic realm "Raspberry HTTP Proxy - Arturo" ## Periodo de validez de la autenticación. Trascurrido ese tiempo se requerirá de nuevo auth_param basic credentialsttl 2 hours # Definición de Listas de Control de Acceso, ACLs ## Definición de ACL para asegurar la autenticación declarada anteriormente acl passwd proxy_auth REQUIRED ## Definición de ACLs para controlar el acceso a máquinas acl todos src all acl maquina1 src 192.168.2.100 #acl acceso src 192.168.100.0/24 ## Definición de ACLs para filtrar URLs de determinados sitios Web por nombre de dominio: acl websnopermitidas dstdomain "/etc/squid3/websprohibidas1.dat" ## Definción de ACLs para filtrar URLs Web según expresiones regulares: acl contenidosnopermitidos url_regex "/etc/squid3/websprohibidas2.dat" # Filtrado en base a las ACLs definidas anteriormente: http_access deny websprohibidas1 http_access deny websprohibidas2 http_access deny maquina1 http_access allow todos passwd Una vez configurado el servicio proxy, antes de reiniciar el servicio para que surtan efecto los cambios, editaremos los ficheros indicados en la configuración anterior: “claves.dat”, “websprohibidas1.dat” y “websprohibidas2.dat”. Respecto al fichero de autenticación de usuarios “claves.dat”, haremos uso de la herramienta software “htpasswd”, tal como utilizábamos para la autenticación de zonas no anónimas en Apache. A modo de ejemplo, crearemos a continuación un fichero que contendrá tres usuarios válidos (login/password) llamado “usuproxy1”, “usuproxy2” y “usuproxy3” (la opción “-c” crea el fichero de usuarios, y por tanto, sólo se incluye al crear el fichero para el primer usuario):

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 51

[root@raspberry]# htpasswd -c /etc/squid3/claves.dat usuproxy1 [root@raspberry]# htpasswd /etc/squid3/claves.dat usuproxy2 [root@raspberry]# htpasswd /etc/squid3/claves.dat usuproxy3 En relación a los ficheros donde le indicaremos las URLs no permitidas y contenidos que serán filtrados: [root@raspberry]# nano /etc/squid3/websprohibidas1.dat # Para evitar visualizar videos de Youtube www.marca.com www.sport.es www.as.com ¡¡Aclaración!! Es importante resaltar que el filtrado de las Web a través de sus URLs también lo podríamos haber obtenido mediante el firewall “iptables”. Por ejemplo: [root@raspberry]# iptables -t filter -A FORWARD -s 192.168.2.0/24 -d www.youtube.es \ -j DROP [root@raspberry]# nano /etc/squid3/websprohibidas2.dat # Se denegará el acceso a aquellas URLs que contengan una de las siguientes palabras: youtube porn sex ... Después de todo lo anterior tan sólo nos quedará reiniciar el servicio para que surtan efecto los cambios en la configuración: [root@raspberry]# /etc/init.d/squid3 restart Una vez configurada nuestra Raspberry como servidor proxy, al tratarse de un proxy no transparente deberemos configurar a los equipos clientes para advertirles de ello. En concreto, deberemos configurar el navegador predeterminado de cada uno de los clientes indicando la dirección IP y puerto de escucha del proxy. Por ejemplo, en el caso de estar utilizando Mozilla como navegador deberíamos ir a “Preferencias”, y en “Avanzado”, en su pestaña “Red” pulsaríamos sobre el botón “Configuración …”, y allí ya podremos indicar todo lo relativo al proxy:

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 52

Una vez establecida la conexión podremos comprobar tanto la necesidad de autenticación como el filtrado de contenidos:

10.4.- Configuración de la Raspberry como proxy transparente. A continuación, realizaremos una configuración similar a la anterior, pero evitando que el usuario tenga que configurar su cliente Web para poder navegar a través del proxy. Es decir, desde punto de vista del usuario final, navegar por Internet a través del proxy le es totalmente transparente, no debe configurar nada en el cliente. Para ello, en la configuración del servicio lo indicaremos explícitamente al indicar el puerto de servicio añadiendo “transparent”, “http_port 3128 transparent”, además de tener que redirigir mediante “iptables” los paquetes recibidos por los clientes que vayan destinados a la navegación por Internet (p.e. HTTP/80), al puerto configurado en el proxy (p.e. Proxy HTTP/3128). A modo de ejemplo, basándonos en la configuración anterior del proxy no transparente, en la siguiente tabla se resumen las características Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 53

del proxy a configurar: Directorio Caché Puertos de Servicio Cantidad Memoria RAM

Autenticación

Tamaño Caché Webs no permitidas Nº Directorios y Subdirectorios

Auditoria Caché

Tamaño máximo de archivo a cachear /var/spool/squid3 3128 transparent 32 MB

1GB 16/256 128MB

Usuarios permitidos Equipos permitidos y no permitidos Auditoria acceso No

www.marca.com www.sport.es www.as.com

Todos (acceso anónimo) Todos (192.168.2.0/24)

cache_log /var/log/squid3/cache.log

access_log /var/log/squid3/access.log

[root@raspberry]# nano squid.conf # Directivas globales # Nombre del servidor proxy visible en los mensajes informativos enviados al cliente Web: visible_hostname rasproxy # Puertos de servicio del proxy. Indicamos explícitamente que queremos que se comporte de manera transparente http_port 3128 transparent # Datos de la Cache: ## Ruta absoluta del directorio donde se cachearán los sitios Web visitados, su tamaño 1000MB, y el número de directorios (16) y subdirectorios (256) cache_dir ufs /var/spool/squid3 1000 16 256 ## Cantidad de memoria RAM que reservamos para este servicio proxy HTTP (p.e.): 32 MB cache_mem 32 MB # Las unidades no pueden estar juntas a la cantidad 256MB!!! ## Máximo tamaño del archivo que una vez descargado será cacheado (p.e.): 128 MB maximum_object_size_in_memory 128 MB # Archivos de auditoría en relación con los accesos y contenidos visitados: access_log /var/log/squid3/access.log cache_log /var/log/squid3/cache.log ## Definición de ACLs para controlar el acceso a máquinas acl todos src all #acl acceso src 192.168.100.0/24 ## Definición de ACLs para filtrar URLs de determinados sitios Web: acl websprohibidas1 dstdomain "/etc/squid3/websprohibidas1.dat" # Filtrado en base a las ACLs definidas anteriormente: http_access deny websprohibidas1 http_access allow todos Por último, tan sólo tendremos que reiniciar el servicio proxy para que surtan efecto los cambios anteriores realizados en la configuración y redigirigir (NAT PREROUTING) al puerto del Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 54

servicio proxy 3128 todos aquellos paquetes TCP/IP que reciba la Raspberry (es el gateway de la Intranet) y que vayan dirigidos al puerto 80 (-p tcp/udp --dport 80). Después tan sólo nos quedará comprobar que desde el cliente se puede navegar sin necesidad de una configuración previa: [root@raspberry]# iptables -t nat -A PREROUTING -s 192.168.2.0/24 -p tcp --dport 80 \ -j REDIRECT --to-port 3128 [root@raspberry]# iptables -t nat -A PREROUTING -s 192.168.2.0/24 -p udp --dport 80 \ -j REDIRECT --to-port 3128 [root@raspberry]# /etc/init.d/squid3 restart

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 55

Práctica nº11.- Configuración de la Raspberry como servidor VPN. Uno de los servicios actuales cuyo uso se esta incrementando considerablemente, es el uso de redes privadas virtuales o VPNs, al posibilitar el teletrabajo ya que esta nos va a permitir acceder desde una ubicación remota a los diferentes equipos que forman parte de la red del trabajo.

En la presente práctica se mostrará como configurar un conexión VPN (Red Privada Virtual) entre nuestro equipo servidor de una Intranet (Raspberry) con un cliente de la Internet. Esto permitirá al cliente externo acceder a cualquier recurso de la Intranet, siempre y cuando no haya algún firewall que lo evite, y además de una manera segura. Antes de que existieran las VPN, la forma más habitual de acceder a un recurso localizado en el interior de una Intranet era instalando un software servidor en el equipo al que se deseaba acceder, y posteriormente configurar en el router de nuestro proveedor de servicios de Internet (ISP) la correspondiente NAT PREROUTING (redireccionamiento de puertos). Esto ya no es necesario al configurar una VPN, ya que el cliente externo va a creer que se encuentra dentro de la propia Intranet, tal como mostraremos al final a través de su tabla de enrutamiento. La red privada virtual, se denomina así, ya que hará creer tanto al servidor VPN, como a los clientes VPN, que se encuentran en una nueva Intranet con su propio rango de direcciones IP privadas (p.e. 172.30.1.0/24), como si estuvieran conectados directamente entre sí a través de un dispositivo de interconexión (hub, switch, punto de acceso, etc.), cuando en realidad, la conexión entre todos ellos se realiza a través de la Internet con multitud de dispositivos de enrutamiento entre ellos. Para ello, el software OpenVPN que usaremos en la presente práctica para formar la VPN creará en los equipos que la forman (servidor y clientes) un nuevo dispositivo de red virtual (tun/tap) que recibirá una dirección IP dentro de la red privada reservada para ello, y permitirán que se puedan interconectar entre sí a través de un supuesto dispositivo de interconexión virtual. En Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 56

concreto, dependiendo del ambito de la VPN, la interfaz de red virtual deberá ser “tun” (interfaz network tunel) en el caso de necesitar manejar paquetes con cabeceras del nivel 3 o de la capa red del modelo TCP/IP, o “tap” (interfaz network tap) si tan sólo necesitamos manejar paquetes de nivel 2 o de capa de enlace. Según lo anterior, si la VPN va a establecerse a través de Internet o una Intranet con direccionamiento IP haremos uso de un dispositivo “tun”, en cambio, si la VPN va a establecerse sin necesidad de direccionamiento IP, en la configuración del servicio escogeremos “tap”. En concreto, para la práctica que aquí se plantea, se ha escogido la dirección de red/subred privada “172.30.1.0/24”, y dispositivos de red de tipo “tun”. A la hora de escoger dicha dirección de red en la práctica, debemos tener cuidado con no entrar en conflicto con ninguna otra dirección de red privada o intranet correspondientes a las redes privadas asociadas a los propios equipos que forman parte de la VPN. Por ejemplo, si observamos el esquema de la figura que se presenta al principio, las direcciones de red 192.168.1.0/24, 192.168.2.0/24 y 192.168.123.0/24 están siendo utilizadas para direccionar los equipos que forman las distintas redes privadas reales del esquema. Por ello, si queremos evitar conflictos con la VPN, la red privada virtual que deseamos crear no debe volver a usar ninguno de los rangos anteriores. Respecto a la dirección de red o subred a utilizar para la VPN advertir que la IANA (Internet Assigned Numbers Authriy) tiene reservados varios rangos de direcciones de red para asignarlos a redes privadas (el resto de redes de clase A, B o C son de asignación pública, con validez en Internet). En concreto son las siguientes: Clase y Máscara de red

Rango de direcciones de Red disponibles para asignación privada

A (255.0.0.0)

10.0.0.0 – 10.255.255.255

B (255.255.0.0)

172.16.0.0 – 172.31.255.255

C (255.255.255.0)

192.168.0.0 – 192.168.255.255

11.1.- Configuración del Router ISP Antes de empezar con la práctica deberemos configurar el router ISP (Proveedor de Servicios de Internet) o equipo que haga que haga de puerta de acceso hacia el exterior. Es decir, desde el exterior, Internet, el único equipo accesible de nuestra red, es el router ISP, ya que es el único que tiene una dirección IP pública univoca y reconocida desde Internet. Por ello, cuando queramos hacer una solicitud de conexión al servicio VPN, se la tendremos que hacer a él, y este programarlo para que la redireccione (NAT Prerouting) hacía el equipo servidor de la Intranet que ofrece ese servicio. Es decir, debemos decirle al router ISP que cuando reciba una solicitud de conexión vía protocolo TCP/1194 o UDP/1194 (el 1194 es el puerto por defecto del servicio VPN) se redireccione dicha solicitud al servidor VPN interno (Raspberry). Si nos centramos en el caso concreto de la presente práctica, por facilidad emularemos el router ISP mediante una máquina virtual funcionando bajo GNU/Linux Ubuntu tal como se puede ver en el esquema o figura del comienzo. Para que haga la función equivalente del router ISP programaremos los siguientes comandos, tal como vimos en el capítulo del diseño e implementación de firewalls: [root@routerisp]# echo “1” > /proc/sys/net/ipv4/ip_forward [root@routerisp]# iptables -t nat -A POSTROUTING -j MASQUERADE [root@routerisp]# iptables -t nat -A PREROUTING -p tcp --dport 1194 -j DNAT \ --to 192.168.1.1 Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 57

[root@routerisp]# iptables -t nat -A PREROUTING -p udp --dport 1194 -j DNAT \ --to 192.168.1.1 Y para no tener que ejecutar los anteriores comandos cada vez que iniciamos sesión, lo más idóneo sería crear un script que se ejecute al iniciarse el equipo, o incluirlas al final del script “/etc/rc.local”: ## Líneas añadidas al final de rc.local: … echo “1” > /proc/sys/net/ipv4/ip_forward iptables -t nat -A POSTROUTING -j MASQUERADE iptables -t nat -A PREROUTING -p tcp --dport 1194 -j DNAT --to 192.168.1.1 iptables -t nat -A PREROUTING -p udp --dport 1194 -j DNAT --to 192.168.1.1

11.2.- Instalación del Software OpenVPN OpenVPN será el software que tendremos que instalar tanto en el servidor como en los equipos clientes para poder establecer la red privada virtual: [root@servidorvpn|clientesvpn]# apt-get install openvpn

11.3.- Instalación de OpenSSL. Creación de la Autoridad de Certificación (CA), y las Claves y Certificados del Servidor y de los Clientes. Al igual que vimos en el capítulo del servicio HTTPS (repasar lo visto en dicho capítulo), para garantizar una comunicación segura, será necesario disponer de una autoridad certificadora (CA) para que suministre los correspondientes certificados a los equipos servidor y clientes. Para todo ello necesitaremos tener instalado “openssl”: [root@servidorvpn]# apt-get install openssl Para automatizar todo, podemos copiar las líneas siguientes en un archivo y ejecutarlo como si se tratase de un script: # Comenzaremos creando la CA (claves y certificado) echo "Creamos la CA. En primer lugar su clave, y luego el certificado con extensión crt" read -p “Pulsa Intro para continuar ...” mkdir /etc/openvpn/ca cd /etc/openvpn/ca openssl genrsa -out ca.key 2048 openssl req -new -x509 -key ca.key -out cacert.crt -days 1000 # Generamos los certificados para el servidor con extensión crt, en lugar de pem echo "Creamos las claves y certificado para el servidor" read -p “Pulsa Intro para continuar ...” mkdir /etc/openvpn/server cd /etc/openvpn/server Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 58

openssl genrsa -out server.key 2048 openssl req -new -key server.key -out servercert.p10 openssl x509 -req -in servercert.p10 -out servercert.crt -CA ../ca/cacert.crt \ -CAkey ../ca/ca.key -CAcreateserial -days 365 # Generamos la Diffie-Hellman key exchange echo "Generamos la Diffie-Hellman key..." read -p “Pulsa Intro para continuar ...” cd /etc/openvpn/ca openssl dhparam -check -text -5 1024 -out dh1024.pem # Generamos los certificados para el cliente1 con extensión crt echo "Creamos las claves y certificado para el cliente1" read -p “Pulsa Intro para continuar ...” mkdir /etc/openvpn/cliente1 cd /etc/openvpn/cliente1 openssl genrsa -out cliente1.key 2048 openssl req -new -key cliente1.key -out cliente1cert.p10 openssl x509 -req -in cliente1cert.p10 -out cliente1cert.crt -CA ../ca/cacert.crt \ -CAkey ../ca/ca.key -CAcreateserial -days 365

11.4.- Configuración del Servidor VPN En este paso configuraremos el equipo servidor encargado de atender las solicitudes de conexión realizas por los clientes remotos de la VPN. Para ello editaremos el archivo de configuración “/etc/openvpn/server.conf”. En concreto, estableceremos la siguiente configuración, congruente con el esquema de red mostrado al comienzo: •

•

•

•

Se asignará a la VPN la dirección de subred “172.30.1.0/24”. El servidor VPN se asignará a si mismo de manera automática la dirección IP más baja, “172.30.1.1”, y el resto de las direcciones IP de la subred las irá asignando a los clientes de la VPN a medida que vaya recibiendo solicitudes de conexión. Habilitaremos un dispositivo de red virtual de tipo “tun” (tunel), “tun0”, al cual asignaremos la dirección IP privada anterior, “172.30.1.1”. Mediante esta interfaz el servidor se comunicará con la interfaz “tun” de los clientes. Indicaremos al servidor VPN que tras aceptar la solicitud de conexión de un cliente VPN, altere la tabla de enrutamiento del equipo cliente, para que sepa que redes internas o Intranet pueden ser alcanzadas desde los clientes externos VPN a través del servidor VPN haciendo este de gateway o puerta de enlace. Según el esquema planteado al comienzo de la práctica, el servidor VPN hará de gateway para alcanzar cualquiera de los equipos que forman parte de las red privadas a las que tiene acceso “192.168.1.0/24” y “192.168.2.0/24”. El servicio VPN puede ofrecerse a través de los protocolos de la capa de transporte “tcp” o “udp”. Para este caso práctico se ha seleccionado “udp” (no orientado a conexión), puede elegirse “tcp”, y advertir cual podría dar un mejor servicio (dependerá del tráfico de red, de la cantidad de servicios que ya se estén dando en el servidor, etc.). Además se ha respetado el puerto por defecto del servicio “1194”, aunque puede igualmente modificarse en el caso en que queramos dar servicio a múltiples VPNs simultáneamente.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 59

A continuación se muestra una configuración ya probada previamente de manera exitosa en un servidor VPN, con la explicación de las directivas utilizadas: # Contenido de “/etc/openvpn/server.conf” ## Comenzaremos indicando el puerto (por defecto, 1194), el protocolo (tcp/udp) y la topología port 1194 proto udp topology subnet ## Indicamos la ubicación de los certificados y claves creados anteriormente: ## Clave asimétrica del servidor, certificados de la CA y del servidor, y la clave Diffie-Hellman ca /etc/openvpn/ca/cacert.crt cert /etc/openvpn/server/servercert.crt key /etc/openvpn/server/server.key dh /etc/openvpn/ca/dh1024.pem ## En el caso de desear que todos los clientes puedan usar el mismo certificado, ## descomentaremos la siguente línea: ;duplicate-cn ## Definimos las características del tunel seguro que se va a generar: ## Tipo de dispositivo que creará el tunel (tun/tap), y características de la conexión dev tun persist-tun persist-key keepalive 10 120 comp-lzo ## Especificamos el rango de direcciones que se asignarán a los equipos de la VPN ## Debe tratarse de una dirección de red o subred no utilizada por ninguna de las Intranet ## en la que se encuentran los equipos servidor o clientes. ## En caso contrario, habrá ambigüedad y confusión en las tablas de enrutamiento de los clientes. ## Por ejemplo, usaremos la dirección de subred 172.30.1.0/24. ## El servidor recibirá automáticamente la dirección IP más baja del rango: “172.30.1.1” server 172.30.1.0 255.255.255.0 ## Para registrar la asignación de direcciones IP realizada por el servidor: ifconfig-pool-persist ipp.txt ## Indicamos las redes internas que serán accesibles desde el exterior a través del servidor VPN. ## Si miramos el esquema del comienzo, las Intranet privadas son 192.168.1.0/24 y 192.168.2.0/24 ## Esto modificará la tabla de enrutamiento de los clientes VPN en consecuencia ## ¡¡Importante!! Esas redes no deben aparecer previamente en la tabla de enrutamiento del ## cliente ya que sino se producirá confusión en el cliente a la hora de saber como alcanzarlas push "route 192.168.1.0 255.255.255.0" push "route 192.168.2.0 255.255.255.0" ## Si queremos modificar la tabla de enrutamiento de los clientes VPN para que todo el ## tráfico hacia Internet se envía a través del servidor VPN, descomentaremos la siguiente línea: ;push "redirect-gateway" ## Si deseamos configurar el DNS y WINS de los clientes: ;push "dhcp-option DNS 10.8.0.1" ;push "dhcp-option WINS 10.8.0.1" Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 60

## Para permitir que los clientes VPN se vean entre sí: client-to-client ## Usuario suplantado por el servicio para restringir los privilegios user nobody group nogroup ## Para limitar el número de conexiones: ;max-clients 100 ## Para auditar el estado de la VPN, y el nivel de auditoría o verbosidad: status openvpn-status.log log-append /var/log/openvpn.log verb 4 Una vez creado el fichero de configuración del servidor VPN, iniciaremos el servicio. Para ello deberemos ejecutar el siguiente comando: [root@servidorvpn]# openvpn --config /etc/openvpn/server.conf Y por último, para que el servidor VPN pueda hacer de puerta de enlace o gateway para los clientes VPN externos hacia los equipos internos de la Intranet o Intranets a las que da acceso, será necesario activar el “ip_forwarding” (reenvío de paquetes entre sus diferentes interfaces de red) y configurar la NAT postrouting: [root@servidorvpn]# echo “1” > /proc/sys/net/ipv4/ip_forward (equivalente a descomentar la línea “net.ipv4.ip_forward=1” en el archivo de configuración /etc/sysctl.conf) [root@servidorvpn]# iptables -t nat -A POSTROUTING -j MASQUERADE Estos últimos comandos sería conveniente añadirlos en el script “/etc/rc.local” para que se ejecuten al iniciar el sistema, o crear nuestro propio script de configuración de arranque dentro de “/etc/init.d” y posteriormente crear el correspondiente enlace a dicho script desde el directorio “/etc/rcX.d” en función del nivel de arranque de nuestro servidor, el cual se puede conocer ejecutando “runlevel” (“X”, se corresponderá con el nivel de arranque).

11.5.- Configuración de los clientes VPN Tras configurar el servidor, tan sólo tendremos que configurar el cliente VPN. Para ello, en primer lugar habrá que hacer llegar a los clientes, por ejemplo, mediante “scp” (suponemos que el cliente o el servidor tiene instalado “openssh-server”), las claves generadas en el paso Nº2, el certificado de cliente firmado por la CA, y el certificado de la CA. En el caso de que sea el equipo cliente de la VPN quien tenga instalado “openssh-server”, desde el servidor se ejecutarían los siguientes comandos (el usuario “usucliente” debe tener configuradas las ACL para tener permiso de escritura sobre el directorio /etc/openvpn): [root@servidorvpn]# scp /etc/openvpn/ca/cacert.crt usucliente@Ip_cliente:/etc/openvpn [root@servidorvpn]# scp /etc/openvpn/cliente1/cliente1.key usucliente@Ip_cliente:/etc/openvpn [root@servidorvpn]# scp /etc/openvpn/cliente1/cliente1cert.crt \ usucliente@Ip_cliente:/etc/openvpn En el caso de que sea al revés, que sea el propio servidor VPN el que tenga instalado el Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 61

“openssh-server”, será desde el propio cliente quien ejecutará el “scp” (el usuario “ususervidor” debe tener permiso de lectura sobre el contenido de “/etc/openvpn”): [root@cliente1vpn]# scp ususervidor@IP_servidor:/etc/openvpn/ca/cacert.crt /etc/openvpn [root@cliente1vpn]# scp ususervidor@IP_servidor:/etc/openvpn/cliente1/cliente1.key \ /etc/openvpn [root@cliente1vpn]# scp ususervidor@IP_servidor:/etc/openvpn/cliente1/cliente1cert.crt \ /etc/openvpn Por último, crearemos el archivo de configuración del equipo cliente VPN “/etc/openvpn/cliente1.conf”. End dicha configuración deberemos tener en cuenta lo siguiente: • • •

El servidor da el servicio vía protocolo “udp”, por el puerto 1194, tal como tiene configurado en su archivo de configuración. El tipo de dispositivo virtual necesario para comunicarse con el servidor será “tun”, tal como justificamos en la configuración del servidor VPN. La solicitud de conexión desde el cliente no se realiza directamente sobre el servidor VPN, ya que este se encuentra en el interior de una Intranet que es inaccesible de manera directa. Es decir, la solicitud se realizará sobre la dirección IP pública que tenga asignada nuestro router ISP (proporcionado por nuestro Proveedor de Servicios de Internet), que en el ejemplo propuesto en este caso práctico es “192.168.123.170”. Por tanto será necesario configurar una NAT prerouting en el router ISP para que redireccione las solicitudes de conexión recibidas por udp/1194 hacía el equipo de la Intranet que hace de servidor VPN (en el esquema 192.168.1.X+50). Dicha configuración se ha realizado al comienzo de la práctica.

## Contenido del archivo de configuración “/etc/openvpn/cliente1.conf” client dev tun proto udp topology subnet persist-key persist-tun resolv-retry infinite nobind ## Indicamos la dirección IP pública del router ISP al que se hará la solicitud de conexión. ## Se podría poner más de uno para balancear carga. remote 192.168.123.170 1194 ## En el caso de querer desviar todo el trafico de Internet generado por el cliente ## a través del servidor VPN descomentaremos la siguiente línea: ;redirect-gateway def1 ## Indicamos la ubicación de las claves del cliente y certficados ca /etc/openvpn/cacert.crt cert /etc/openvpn/cliente1cert.crt key /etc/openvpn/cliente1.key ## Usuario suplantado por la VPN con privilegios restringidos Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 62

user nobody group nogroup ## Indicamos que los datos de la comunicación entre cliente y servidor VPN viajarán comprimidos comp-lzo ## Nivel de verbosidad: cantidad y tipo de mensajes de información que aparecerán por pantalla verb 4 Por último, haremos la solicitud de conexión mediante la ayuda del archivo de configuración creado: [root@cliente1vpn]# openvpn --config /etc/openvpn/cliente1.conf Para comprobar el correcto funcionamiento de la VPN, deberemos advertir cambios producidos en la tabla de enrutamiento del equipo cliente de la VPN, ya que deben aparecer nuevas reglas de enrutamiento necesarias para que el equipo cliente sepa como alcanzar las Intranet privadas reales a través del servidor VPN. A continuación se muestran las tablas antes y después de establecer la conexión con la VPN: [root@cliente1vpn]# route -n (antes de iniciar la conexión VPN) Destino Gateway Máscara Flag 192.168.100.0 0.0.0.0 255.255.255.0 U 0.0.0.0 192.168.100.110 0.0.0.0 UG

Métrica 0 0

Interfaz eth0 eth0

[root@cliente1vpn]# route -n (después de iniciar la conexión VPN) Destino Gateway Máscara Flag 172.30.1.0 0.0.0.0 255.255.255.0 U 192.168.1.0 172.30.1.1 255.255.255.0 UG 192.168.2.0 172.30.1.1 255.255.255.0 UG 192.168.100.0 0.0.0.0 255.255.255.0 U 0.0.0.0 192.168.100.110 0.0.0.0 UG

Métrica 0 0 0 0 0

Interfaz tun0 tun0 tun0 eth0 eth0

Si habilitáramos la directiva “redirect-gateway def1” en los archivos de configuración, además de las reglas anteriores, también aparecerían nuevas reglas que enrutarían todo el trafico de Internet generado por el cliente de la VPN, hacía el gateway del servidor de la VPN ( puede tener interés para control los accesos a Internet realizados por el equipo cliente): [root@cliente1vpn]# route -n (incluyendo “redirect-gateway def1”) Destino Gateway Máscara Flag 172.30.1.0 0.0.0.0 255.255.255.0 U 192.168.1.0 172.30.1.1 255.255.255.0 UG 192.168.2.0 172.30.1.1 255.255.255.0 UG 192.168.100.0 0.0.0.0 255.255.255.0 U 0.0.0.0 172.30.1.1 0.0.0.0 UG 0.0.0.0 192.168.100.110 0.0.0.0 UG

Métrica 0 0 0 0 1000 0

Interfaz tun0 tun0 tun0 eth0 tun0 eth0

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 63

Práctica nº12.- Raspberry como controlador de dominio primario (PDC) En la práctica 8.2 se mostró como formar un grupo de trabajo híbrido entre equipos GNU/Linux y Windows, con la finalidad de compartir recursos (directorios e impresoras) entre los equipos. Este tipo de configuración en red se denomina habitualmente red P2P (Peer To Peer), entorno en la cual todo equipo perteneciente al grupo de trabajo hace simultáneamente de cliente y de servidor.

En cambio, en la presente práctica se mostrará como implementar una red jerárquica cliente-servidor basada en el uso de dominios. En este tipo de estructura en red debe existir un servidor central (controlador de dominio principal, PDC) que se encargará básicamente de las dos siguientes características: - Controlar la autenticación de los usuarios en las máquinas clientes. Es decir, cuando un usuario trate de iniciar sesión en un equipo cliente requerirá introducir un “login” y una “password”, los cuales serán validados por el PDC. - Gestionar los perfiles de los usuarios (perfiles móviles). Es decir, una vez autentificado el usuario e iniciada la sesión, el usuario dispone de una estructura de directorios y archivos (Escritorio, Mis Documentos, etc.) que conforman el perfil del usuario. En una red basada en dominio, en el momento en que el usuario cierra la sesión, el perfil completo del usuario se transfiere del equipo cliente al equipo servidor PDC, quedando de esta forma centralizados todos los perfiles. Esto garantiza que el usuario pueda sentarse indistintamente en cualquiera de los equipos clientes dependientes del PDC cargándose el perfil con el que estuvo trabajando la última vez que inicio sesión en el dominio. A esta característica se le denomina perfil móvil. Según lo anterior, uno de los servicios más útiles que podemos implementar con nuestra Raspberry es el de controlador de dominio principal (PDC) supliendo de esta forma al clásico Windows Server 2000/2003/2008 en sus funciones más básicas, evitando de esta forma el pago de la correspondiente licencia, sus tediosos arranques y sus molestas actualizaciones. Con la Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 64

configuración que se va a presentar a continuación, los clientes del dominio, Windows o GNU/Linux, podrán autenticarse y almacenar su perfil en la Raspberry PDC, siendo para ellos totalmente transparente si quien ofrece el servicio es un Windows Server o un Samba Server sobre la Raspberry.

12.1.- Registro de los nombres de dominio en el servidor DNS Bind Dentro de un dominio cada uno de los equipos que lo componen deben tener un nombre de dominio cualificado (FQDN), que lo identifique y le permita estar localizable. Por ejemplo, cuando queremos agregar a un equipo cliente dentro del dominio, le tenemos que indicar cual es nombre del dominio cualificado, de tal forma, que el cliente solicitará a su servidor DNS la correspondiente resolución de nombre a dirección IP, y así poder localizar al PDC e intentar agregarse. Para registrar al nombre de dominio, el equipo servidor PDC y los equipos clientes, configuraremos en la Raspberry una nueva zona maestra, a través de la cual daremos de alta el nombre do dominio deseado, tal como se mostró en la práctica 5.2. En el ejemplo que se muestra a continuación, y siendo congruentes con la imagen anterior, registraremos un nuevo dominio llamado “intranet.es”: [pi@raspberry]# sudo su [root@raspberry]# nano /etc/bind/named.conf … # Anañadimos la siguiente línea y Bind9 incluirá en su configuración el archivo miszonas.conf include "/etc/bind/miszonas.conf"; [root@raspberry]# nano /etc/bind/miszonas.conf root@raspberrypi:/etc/bind# more miszonas.conf # Damos de alta el dominio “intranet.es” zone "intranet.es" in { type master; file "/etc/bind/maestras/maestra.intranet.es"; }; Comprobamos la configuración anterior y editamos el archivo de zona: [root@raspberry]# named-checkconf [root@raspberry]# mkdir /etc/bind/maestras [root@raspberry]# nano /etc/bind/maestras/maestra.intranet.es ; Contenido de ejemplo del archivo de zona asociado a la zona o dominio “intranet.es” $TTL 604800 @ IN SOA localhost. root.localhost. ( 2013030801 ; Número de Serie o versión de zona 604800 ; Tiempo de Refresco para DNS esclavos 86400 ; Tiempo de Reintento para DNS esclavos 2419200 ; Tiempo de Expiración para DNS esclavos 604800 ) ; Time To Live, tiempo de vida en caché ; @ IN NS ns ; Indicamos el nombre de la máquina Servidora de Nombres (NS) ns IN A 192.168.1.102 ; Indicamos la dirección IP de la máquina ns.intranet.es @ IN A 192.168.1.102 ; Indicamos una dirección IP para el dominio intranet.es server IN A 192.168.1.102 ; Indicamos una dirección IP para el equipo server.intranet.es Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 65

cliente1

IN

A

192.168.1.105 ; Indicamos una dirección IP cliente1.intranet.es

Por último chequeamos el archivo de zona y comprobamos su correcta resolución con el comando “dig” o “nslookup” tras reiniciar el servicio para que surtan efecto los cambios: ¡¡Importante!! El comando “dig” y “dnslookup” son unas utilidades cliente DNS proporcionadas por “bind9” que nos permite comprobar el correcto funcionamiento del servicio ofrecido por “bind9”. Para poder hacer uso de estas y otras utilidades habrá que instalar el paquete “dnsutils”: [root@clientedns|servidordns]# apt-get install dnsutils [root@raspberry]# named-checkzone intranet.es /etc/bind/maestras/maestra.intranet.es [root@raspberry]# /etc/init.d/bind9 restart [root@raspberry]# echo “nameserver 127.0.0.1” > /etc/resolv.conf [root@raspberry]# dig intranet.es [root@raspberry]# dig server.intranet.es

12.2.- Instalación del software servidor PDC: Samba En primer lugar instalaremos el programa que convertirá a nuestra Raspberry en un equipo Windows desde el punto de vista del resto de equipos de la red: [pi@raspberry]# sudo su [root@raspberry]# aptitude search samba # Para conocer paquetes relacionados con samba [root@raspberry]# apt-get install samba samba-common samba-common-bin

12.3.- Configuración de Samba como PDC Para configurar el servidor deberemos editar el fichero de configuración de Samba que encontraremos en “/etc/samba/smb.conf”. Según vimos en la práctica 8.2, este archivo esta dividido en diferentes secciones encabezadas por el nombre de dicha sección encerrada entre corchetes. Estas secciones se suelen corresponder con los diferentes recursos que comparte la máquina, [homes], [printers] o [clases]. Pero hay una sección que no un recurso compartido propiamente dicho, sino una sección donde se localizan las directivas generales de configuración que configuran el servicio. Esta sección es la primera que nos encontraremos, [global]. En concreto, entre las muchas directivas que pueden usarse en la sección [global], nosotros haremos uso de las siguientes directivas de configuración a la hora de configurar un servidor PDC: • •

• • • • •

workgroup: Nombre del grupo de trabajo o nombre de dominio cualificado, dependiendo del tipo de red deseado. netbios name: Nombre NetBIOS identificativo de la máquina. Tiene limitaciones importantes en cuanto a longitud del nombre y tipo de caracteres permisibles. Por ejemplo, no permite utilizar “.” muy habituales en nombres de dominio. server string: Descripción del equipo. wins support: Permite convertir a nuestro Samba en un servidor Windows WINS encargado de resolver nombres NetBIOS en una red Windows a su correspondiente dirección IP. dns proxy: Permite redireccionar la resolución de nombres NetBIOS al servicio DNS (Bind). name resolve order: Secuencia seguida por nuestro equipo servidor a la hora de resolver un nombre de dominio cualificado o un nombre NetBIOS. security: Permite decidir el modo de autenticación. En nuestro caso elegiremos un modo Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 66

• • • • • •

•

• • •

bajo el cual cuando un usuario trata de iniciar sesión desde un equipo cliente dentro dominio, el login y password introducidos se deberán corresponder con el nombre de usuario y contraseña de una cuenta del sistema GNU/Linux Raspbian que se habrá tenido que haber creado previamente. domain logons: Habilita a nuestro equipo como servidor de autenticación del dominio. local master: Configura a nuestro equipo servidor. domain master: Configura a nuestro equipo servidor como controlador del dominio. preferred master: Configura al servidor como preferente. os level: Nivel de control de acceso. logon path: Ruta de red donde se almacenarán los perfiles de los usuarios del dominio. Cuando un usuario se autentifica se cargará en el equipo cliente el perfil que tenga almacenado en esta ubicación. De igual forma, cuando un usuario cierra sesión, todas las modificaciones producidas en su perfil se almacenarán en la ruta indicada. logon drive: Letra de la unidad de red que se auto configurará en los equipos clientes una vez autentificados los usuarios. A través de dicha unidad los usuarios accederán, por ejemplo, a su HOME dentro servidor GNU/Linux Raspbian. logon home: Ruta de la unidad de red especificada en la directiva “logon drive”. logon script: Nombre del script que deberá encontrarse dentro del recurso NETLOGON, y que será ejecutado cuando los usuarios inicien sesión. add machine script: Script de creación de máquinas dentro del dominio.

Haciendo uso de las directivas de configuración anteriores, la sección [global] debería tener al menos las siguientes directivas configuradas adecuadamente, para lo cual habrá que añadir aquellas directivas que no aparezcan, descomentar aquellas que lo estén (quintando la # que le precede) o modificar el valor que tengan asignado: [root@raspberry]# nano /etc/samba/smb.conf [global] workgroup = intranet.es netbios name = server-intranet server string = Raspberry PDC wins support = yes dns proxy = yes name resolve order = wins host lmhosts bcast security = user domain logons = yes os level = 64 local master = yes domain master = yes preferred master = yes logon path = \\%N\%U\profile logon drive = H: logon home = \\%N\%U logon script = logon.bat # Habrá que generarlo dentro del recurso compartido [netlogon] add machine = /usr/sbin/useradd -g machines -c "%u machine account" -d /var/lib/samba -s /bin/false %u … # Resto de directivas de la sección [global] Por otro, para que surta efecto todo lo anterior, habrá que habilitar el los siguientes recursos Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 67

compartidos descomentando las líneas correspondientes: •

“\\%N\%U”: La variable de Samba “%N” hace referencia al recurso compartido de Samba [homes] correspondiente al directorio “/home” del sistema donde se almacenan los perfiles de los usuarios. La variable “%U” hace referencia al nombre del usuario que se autentifica. Por ello, habilitaremos la sección [homes] que ya viene preconfigurada en archivo “smb.conf”:

[root@raspberry]# nano /etc/samba/smb.conf [homes] comment = Home Directories browseable = no writable = yes # read only = no create mask = 0700 directory mask = 0700 valid users = %S •

Además habrá que habilitar la sección [netlogon] que igualmente viene preconfigurada correspondiente al recurso compartido donde se almacenará todo aquello que queramos que afecte a los usuarios que se autentifican sobre el dominio:

[root@raspberry]# nano /etc/samba/smb.conf [netlogon] comment = Network Logon Service path = /home/samba/netlogon guest ok = yes read only = yes share modes = no Tras todo lo anterior, sería conveniente testear la sintaxis del fichero “smb.conf” mediante el comando “testparm” por si hubiéramos cometido algún error sintáctico al hacer uso de las directivas de configuración, y posteriormente reiniciar el servicio: [root@raspberry]# testparm [root@raspberry]# /etc/init.d/samba restart A continuación, antes de agregar un equipo cliente al dominio, será necesario crear al menos una cuenta de usuario para poder autenticarse sobre el dominio, y dar de alta la máquina cliente que posteriormente se agregará.

12.4.- Creación de Cuentas de Usuario del Dominio En primer lugar recordar, tal como se indicó en la práctica 8.2, que una cuenta de usuario del sistema, no es una cuenta de usuario Samba. Para crear cuentas de usuario Samba deberemos hacer uso de la aplicación “smbpasswd”. En concreto, la primera cuenta Samba que hay que crear es la del administrador del sistema “root”, ya que esta será necesaria y solicitada en el momento de agregar un equipo cliente al dominio. Para ello ejecutaremos el comando “smbpasswd” con la opción “-a” (añadir usuario): [root@raspberry]# smbpasswd -a root

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 68

Después crearemos una cuenta de usuario que pueda utilizarse para autenticarse al iniciar sesión desde un equipo cliente del dominio. Para ello, primero crearemos la cuenta de usuario en el sistema para que tenga su propio directorio [home], y luego la daremos de alta en Samba (le asignaremos una shell falsa, “-s /bin/false” en el caso de que deseemos evitar su acceso vía SSH). Por ejemplo, para una cuenta de usuario llamada “usudominio1”: [root@raspberry]# useradd -m -d /home/usudominio1 [-s /bin/false] usudominio1 [root@raspberry]# passwd -l usudominio1 [root@raspberry]# smbpasswd -a usudominio1

12.5.- Creación de Cuentas de Máquinas Clientes del Dominio Para dar de alta una máquina cliente que posteriormente será agregada al dominio, haremos uso del siguiente comando. Por ejemplo, para una máquina que recibirá el nombre de “cliwin”: [root@raspberry]# groupadd machines [root@raspberry]# useradd –g machines –d /dev/null –s /bin/false cliwin$ [root@raspberry]# passwd -l cliwin$ [root@raspberry]# smbpasswd -a -m cliwin

12.6.- Configuración del Cliente para agregarlo al Dominio Una vez configurada la Raspberry, tan sólo tendremos que configurar un cliente Windows o GNU/Linux para agregarlo al dominio. En el caso de Windows, será tan sencillo como pinchar con el botón derecho del ratón sobre “Mi PC” y editar los parámetros de la pestaña “nombre de equipo”. En el caso de que el cliente sea un GNU/Linux deberemos instalar “likewise”.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 69

Práctica nº13.- Configuración de la Raspberry como servidor Webmail En la presente práctica se mostrará como configurar un entorno de red donde coexistan dos servidores de correo asociados a dos dominios diferentes (por ejemplo, “servidormail1.es” y “servidormail2.es”), de tal forma que puedan enviarse emails entre los diferentes clientes de correo pertenecientes a cualquiera de los dominios, haciendo uso de un simple cliente Web/HTTP: Servicio WebMail. Para ello, con la finalidad de involucrar el menor número de equipos posibles en la práctica, se hará uso únicamente de dos equipos para el diseño del esquema que se muestra en la siguiente figura: puede implementarse mediante dos Raspberrys, una Raspberry y una máquina virtual, etc. En concreto la Raspberry hará servidor DNS del conjunto y de servidor de correo Webmail para el primer dominio (p.e. “servidormail1.es”).

En el mundo real, la práctica se correspondería con una situación donde se verían involucrados al menos 5 equipos: 2 equipos clientes, 2 equipos para cada uno de los servidor de correo asociados a cada uno de los dominios, más un último equipo que se correspondería con el servidor DNS donde están registrados los nombres de dominios cualificados (FQDN) asociados a cada uno de los dos dominios. Aquí, como ya se ha recalcado antes, con la finalidad de optimizar los recursos, lo implementaremos todo con únicamente dos máquinas virtuales. A continuación se detallarán los diferentes pasos que vamos a seguir para su correcta implementación: 1.- Instalación del servicio DNS y configuración. El servidor DNS se encargará de informar a los equipos involucrados de quien es el servidor de correo (MX, Mail eXchange) asociado a cada uno de los dominios. Para ello, haremos uso del software “bind9”. 2.- Instalación de los servicios de transmisión de correo SMTP y su configuración. El protocolo SMTP será el utilizado en el envío/transporte de los correos desde el equipo servidor de correo asociado a la cuenta de email del emisor hasta el buzón dentro del equipo servidor asociado a la cuenta de usuario del receptor. Para ello, haremos uso del software “postfix”. 3.- Instalación de los servicios de recepción de correo IMAP y su configuración. El protocolo IMAP será el utilizado para recoger los emails depositados en el buzón del usuario. El software utilizado será “dovecot-imapd”. 4.- Instalación y personalización del sitio Web PHP “SquirrelMail” bajo Apache. Mediante esta aplicación WebMail los usuarios podrán tanto enviar, como recibir emails.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 70

13.1.- Configuración del servicio DNS Bind. En este paso de la práctica, daremos por supuesto que se ha realizado exitosamente la práctica Nº5 correspondiente a la configuración del servicio DNS. 1) Editamos el fichero principal de configuración del servicio Bind9, “named.conf”, e incluimos en la configuración del bind9 el archivo de configuración “miszonas.conf” donde se definirán la zonas o dominios utilizados en la presente práctica “servidormail1.es” y “servidormail2.es”: [pi@servidordns]$ sudo su [root@servidordns]# nano /etc/bind/named.conf ... include "/etc/bind/miszonas.conf"; 2) Damos de alta las zonas o dominios “servidormail1.es” y “servidormail2.es” en el archivo “miszonas.conf”: [root@servidordns]# nano /etc/bind/miszonas.conf zone “servidormail1.es” in { type master; file "/etc/bind/maestras/maestra.servidormail1.es"; }; zone “servidormail2.es” in { type master; file "/etc/bind/maestras/maestra.servidormail2.es"; }; 3) Editamos los archivos de zona asociados a las zonas o dominios anteriores: “maestra.servidormail1.es” y “maestra.servidormail2.es”. Entre los diferentes registros utilizados para configurar los archivos de zona, A, CNAME o SOA, cabría destacar al registro “MX” (Mail eXchange), ya que ese el encargado de informar al que lo solicite de cual es el nombre de la máquina dentro del dominio que hace de servidor de correo del dominio (p.e. mail.servidormail01.es). Posteriormente mediante un registro “A” (Address), indicaremos cual es la dirección IP de ese equipo servidor. [root@servidordns]# mkdir /etc/bind/maestras [root@servidordns]# nano /etc/bind/maestras/maestra.servidormail1.es $TTL 604800 @ IN SOA localhost. root.localhost. ( 2012100501 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns ns IN A 192.168.1.254 ;IP del equipo servidor DNS @ IN A 192.168.1.254 servidormail1.es. IN MX 10 mail ;FQDN del servidor de correo del dominio mail IN A 192.168.1.254 ;IP del servidor de correo del 1er dominio Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 71

webmail

IN

A

192.168.1.254 ;IP del servidor webmail 2º dominio

[root@servidordns]# nano /etc/bind/maestras/maestra.servidormail2.es $TTL 604800 @ IN SOA localhost. root.localhost. ( 2012100501 ; Serial 604800 ; Refresh 86400 ; Retry 2419200 ; Expire 604800 ) ; Negative Cache TTL ; @ IN NS ns ns IN A 192.168.1.254 ;IP del equipo servidor DNS @ IN A 192.168.1.254 servidormail2.es. IN MX 10 mail ;FQDN del servidor de correo del dominio mail IN A 192.168.1.253 ;IP del servidor de correo del 2º dominio webmail IN A 192.168.1.253 ;IP del servidor webmail 2º dominio ¡¡Importante!! El registro de configuración de zona más importante de todos es el MX (Mail eXchange). Cuando una cuenta de usuario de un dominio, p.e. [email protected], manda un email a un usuario de otro dominio, p.e. [email protected], dicha solicitud le llega vía SMTP al equipo servidor de correo de su dominio, mail.servidormail1.es. Este equipo servidor es el encargado de enviar el email al destinatario. Para ello, hace una consulta DNS preguntado a su servidor DNS cual es el equipo asociado al registro MX del dominio del destinatario, servidormail2.es, y su dirección IP asociada (registro A, Address). De esta forma, el servidor de origen ya dispone de la dirección IP 192.168.1.253 del servidor destinatario, al cual le envía el email. Este al recibirlo lo almacenará en el buzón asociado a dicho usuario. Posteriormente, la cuenta de usuario destinataria, haciendo uso del protocolo IMAP recogerá dicho correo. Por último, para que surta efecto toda la configuración DNS anterior, se chequearán tanto el archivo de configuración, como los archivos de zona. En caso de que no se den errores, pasaremos a reiniciar el servicio: [root@servidordns]# named-checkconf [root@servidordns]# named-checkzone servidormail1.es \ /etc/bind/maestras/maestra.servidormail1.es [root@servidordns]# named-checkzone servidormail2.es \ /etc/bind/maestras/maestra.servidormail2.es [root@servidordns]# /etc/init.d/bind9 restart Para comprobar el correcto funcionamiento del servicio, sería conveniente hacer solicitudes de resolución desde las máquinas involucradas en el esquema de red de la práctica. Para ello, deberemos indicar en el fichero de configuración “/etc/resolv.conf” de cada uno de ellos la dirección IP del equipo servidor DNS, y a continuación ejecutar un “dig” o un “nslookup”: ¡¡Importante!! El comando “dig” y “dnslookup” son unas utilidades cliente DNS proporcionadas por “bind9” que nos permite comprobar el correcto funcionamiento del servicio ofrecido por “bind9”. Para poder hacer uso de estas y otras utilidades habrá que instalar el paquete “dnsutils”: [root@clientedns|servidordns]# apt-get install dnsutils Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 72

[root@servidordns]# echo “nameserver 127.0.0.1” > /etc/resolv.conf #En el propio equipo servidor DNS, con dirección IP 192.168.1.254 (nuestra Raspberry) [root@clientedns]# echo “nameserver 192.168.1.254” > /etc/resolv.conf #En en el resto de equipos del esquema [root@clientedns|servidordns]# dig -t MX servidormail1.es [root@clientedns|servidordns]# dig -t MX servidormail2.es

13.2.- Instalación y Configuración del servidor SMTP PostFix. A continuación instalaremos y configuraremos el servicio encargado de transportar los correos desde el servidor de correo asociado al emisor, hasta el servidor de correo asociado al receptor del email, donde se encontrará su buzón (normalmente, una directorio de su HOME). Por tanto la instalación habrá que realizarla en los dos equipos servidores asociados a cada uno de los dos dominios, con direcciones IP 192.168.1.254 (equipo MX del dominio servidormail1.es), y 192.168.1.253 (equipo MX del dominio servidormail2.es), según el esquema indicado al principio de esta práctica. Para ello instalaremos el software “postfix”, el cual convertirá nuestro equipo en un servidor SMTP: [pi@servidorsmtp]$ sudo su [root@servidorsmtp]# apt-get install postfix Durante su instalación nos harán unas preguntas que pre-configurarán el servicio: •

Nos preguntarán que tipo de servicio SMTP que queremos ofrecer: servicio local/interno, servicio asociado a sitio de Internet o servicio de un sitio de Internet dependiente de otro servidor SMTP principal o smarthost. Contestaremos “Sitio de Internet”, ya que nuestro servidor SMTP va a dar un servicio de manera independiente, y con la posibilidad de ofrecerlo en Internet si el nombre de dominio es registrado de manera pública, configurado el MX y redireccionando el puerto 25/tcp del servicio SMTP de nuestro router ISP hacia el equipo servidor del dominio (en este caso nuestra Raspberry).

•

Después nos preguntará por el nombre del dominio cualificado (FQDN) al cual va dar el servicio SMTP. Indicaremos “servidormail1.es” o “servidormail2.es”, dependiendo si estamos configurando el primer servidor o el segundo.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 73

Tras la instalación de “postfix”, pasaremos a configurarlo editando el fichero “/etc/postfix/main.cf” (en ambos servidores). Entre todas las directivas de configuración cabría destacar las siguientes: • • • •

• • •

“mydomain”: nombre FQDN del dominio al que damos servicio. “myhostname”: nombre FQDN del equipo servidor SMTP del dominio. “myorigin”: ruta del archivo que contiene el nobre FQDN del dominio. “mydestination”: destinos de los emails que serán reconocidos como propios. Es decir, cuando el equipo servidor manipula un email, tiene dos alternativas: 1) reconocer que el email va destinado a un servidor externo, situación ante la cual hará una consulta DNS para saber cual es el equipo servidor MX asociado al dominio de destino y enviarle de esta forma el email correspondiente, o 2) reconocer que el email va destinado a una de las cuentas de usuario a las que él da servicio, situación ante la cual pasará a almacenarlo en el buzón del usuario correspondiente. En definitiva, esta directiva contiene los nombres de dominio y de equipos, que son entendidos por el propio servidor como de gestión propia, y que por tanto, los emails dirigidos a alguno de los nombres asociados a esta directiva, no serán enviados hacia el exterior. “mynetworks”: direcciones IP correspondientes a las redes dentro de las que ofrece el servicio. “mynetworks_style”: estructura de red dentro de la cual da el servicio. “inet_interfaces”: interfaces de red por las que ofrece el servicio.

Según lo anterior, el aspecto del archivo de configuración del “postfix” en su configuración más básica debería tener un aspecto como el siguiente (las directivas que no se indican pueden dejarse a su valor por defecto): [root@servidorsmtp]# nano /etc/postfix/main.cf # Directivas básicas de /etc/postfix/main.cf ... myhostname = mail.servidormail1.es mydomain = servidormail1.es myorigin = /etc/mailname mydestination = mail.servidormail1.es, servidormail1.es, localhost.localdomain, localhost mynetworks = 192.168.1.0 127.0.0.0/8 [::ffff:127.0.0.0]/104 [::1]/128 mynetworks_style = subnet inet_interfaces = all Por último, para que surtan efecto los cambios anteriores habrá que reiniciar el servicio: [root@servidorsmtp]# /etc/init.d/postfix restart Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 74

13.3.- Instalación y Configuración del servidor IMAP Dovecot Tras configurar el servicio SMTP, pasaremos a configurar el servicio IMAP en ambos equipos servidores, el cual se encargará de recoger y entregar los correos al correspondiente destinatario. Para ello instalaremos el software “dovecot-imapd”: [root@servidorimap]# apt-get install dovecot-imapd Para su configuración editaremos los ficheros de configuración de “dovecot” que encontraremos en “/etc/dovecot/” (el archivo principal de configuración es “/etc/dovecot/dovecot.conf”, pero por cuestión de organización, “dovecot”, ha dividido su configuración en varios archivos que encontraremos en el subdirectorio “/etc/dovecot/conf.d/”. En concreto, con la finalidad de obtener una configuración mínima del servicio descomentaremos y editaremos las directivas siguientes: •

“mail_location”, encargada de indicar donde se ubicará la bandeja de entrada (INBOX) de las cuentas de usuario del servicio de correo. Es decir, informaremos a “dovecot” de los directorios donde se guardarán los emails recibidos, enviados, los borradores, y los emails eliminados. Para ello editaremos el archivo “/etc/dovecot/conf.d/10-mail.conf”. Si queremos dejar su valor por defecto, nos encontraremos con el siguiente valor asignado, que nos informa de que los usuarios deberán tener en su directorio HOME (~) un subdirectorio llamado “~/mail” donde se almacenarán los emails enviados, borradores y aquellos que mandemos a la papelera, y un archivo con su nombre de usuario en “/var/mail/%u” donde se irán añadiendo los emails enviados:

[root@servidorimap]# more /etc/dovecot/conf.d/10-mail.conf | grep ^mail_location mail_location = mbox:~/mail:INBOX=/var/mail/%u • •

“protocols” y “protocol” informarán a “dovecot” de que el protocolo a utilizar será IMAP. Por defecto, ya se encuentra habilitado. “listen” le indicará las interfaces de red y direcciones IP del equipo bajo las cuales ofrecerá el servicio “imap”. Para ello editaremos el archivo principal de configuración, y descomentaremos o añadiremos la línea “listen = *”, la cual informará a “dovecot” que el servicio se ofrecerá por cualquiera de sus interfaces de red.

[root@servidorimap]# nano /etc/dovecot/dovecot.conf # Contenido del fichero de configuración dovecot.conf … listen = * ... Por último, antes de reiniciar el servicio “dovecot” para que surtan efecto los cambios en la configuración, según la configuración anterior cada uno de los usuarios que vayan a usar el servicio de correo deberá disponer del directorio y archivo indicados en la directiva “mail_location”. Por ejemplo, si en el equipo servidor del primer dominio, quisiéramos crear una cuenta de correo llamada “[email protected]” haríamos lo siguiente, dependiendo de si queremos que dicha cuenta de usuario tenga una shell válida para poder iniciar sesión, por ejemplo vía SSH, o con una shell falsa para evitar posibles problemas de seguridad: [root@servidorimap]# useradd -m -d /home/usuario1 -s /bin/bash usuario1 Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 75

[root@servidorimap]# passwd usuario1 [root@servidorimap]# touch /var/mail/usuario1 [root@servidorimap]# chown usuario1 /var/mail/usuario1 [root@servidorimap]# chmod 700 /var/mail/usuario1 [root@servidorimap]# su usuario1 [usuario1@servidorimap]$ mkdir /home/usuario1/mail [usuario1@servidorimap]$ exit [root@servidorimap]# useradd -m -d /home/usuario1 -s /bin/false usuario1 [root@servidorimap]# passwd usuario1 [root@servidorimap]# touch /var/mail/usuario1 [root@servidorimap]# chown usuario1 /var/mail/usuario1 [root@servidorimap]# chmod 700 /var/mail/usuario1 [root@servidorimap]# mkdir /home/usuario1/mail [root@servidorimap]# chown -R usuario1 /home/usuario1 [root@servidorimap]# /etc/init.d/dovecot restart

13.4.- Instalación y Configuración del servidor HTTP WebMail: Apache y Squirrelmail Para terminar, instalaremos en ambos equipos servidores la aplicación Web PHP que nos proporcionará la interfaz Web para la gestión WebMail (envio/recepción/gestión de emails vía Web/HTTP). Para ello, instalaremos la aplicación “squirrelmail” (en caso de no tener instalado Apache, o la librería necesaria para que interprete PHP, etc. al instalar squirrelmail también las instalará todas ellas por cuestiones de dependencias de software): [root@servidorwebmail]# apt-get install squirrelmail A continuación configuraremos “Apache” para que suministre un servicio WebMail a través de “squirrelmail”. Configurar “Apache” es muy sencillo, ya que tras la instalación de “squirrelmail”, se crea el directorio “/etc/squirrelmail”, y dentro de este, encontramos el fichero de configuración para “Apache” suministrado por los desarrolladores de “squirrelmail”, llamado “apache.conf”. [root@servidorwebmail]# ls /etc/squirrelmail/ apache.conf config.php filters_setup.php config_default.php conf.pl index.php config_local.php default_pref sqspell_config.php Por tanto para configurar “Apache” haremos lo siguiente, dependiendo de si queremos dar un servicio Webmail en modo no seguro mediante HTTP (2.1), o en modo seguro mediante HTTPS (2.2): 1) Copiaremos el fichero anterior de configuración suministrado por “squirrelmail” a “sites-avalilable” de “Apache” con el nombre que deseemos: [root@servidorwebmail]# cp /etc/squirrelmail/apache.conf \ /etc/apache2/sites-available/servicio-webmail.conf 2.1) Personalizamos el fichero de configuración anterior. Concretamente descomentaremos las Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 76

líneas relativas al “VirtualHost” que aparecen, indicando la dirección IP a través de la cual queremos dar el servicio, y el nombre FQDN reservado y preconfigurado en el servidor DNS. Tener en cuenta que de hacerlo así, el servicio Webmail que ofreceremos será en modo no seguro HTTP: [root@servidorwebmail]# nano /etc/apache2/sites-available/servicio-webmail.conf … NameVirtualHost 192.168.1.254:80 DocumentRoot /usr/share/squirrelmail ServerName webmail.servidormail1.es ... ¡¡Aclaración!! La directiva “NameVirtualHost tan sólo será necesaria si el servidor Web Apache ya esta sirviendo otro sitio Web bajo la misma dirección IP y el mismo puerto “192.168.1.254:80”. Es decir, esta directiva advierte a Apache, que en el caso de se hayan definido más de un “VirtualHost” con la misma dirección IP y el mismo puerto, debe fijarse en el “ServerName” de la URL solicitada para saber que sitio Web debe servir. Esta directiva sólo debe aparecer una vez por IP y puerto, independientemente del número de “VirtualHost” habilitados en la configuración que lo cumplan. Por ello, al tener que definirse una sola vez, por cuestión de organización, sería mejor colocar esa directiva en caso de ser necesaria en el fichero “/etc/apache2/ports.conf”. 2.2) En el caso de que queramos ofrecer este servicio de manera segura mediante el protocolo HTTPS a través del puerto 443, modificaremos el “VirtualHost” anterior, habiendo seguido previamente los pasos ya explicados a lo largo de la práctica Nº9. Según lo visto en esa práctica, lo primero será crear un certificado para el nuevo servicio que vamos a ofrecer (suponemos que la entidad certificadora ya fue creada en la práctica Nº9 correspondiente a HTTP/HTTPS): ¡¡Importante!! Repasar lo visto ya en la práctica Nº9 correspondiente a configurar la Raspberry como servidor HTTP/HTTPS. [root@servidorwebmail]# mkdir /etc/apache2/webmail [root@servidorwebmail]# cd /etc/apache2/webmail [root@servidorwebmail]# openssl genrsa -out webmail.pem 2048 [root@servidorwebmail]# openssl req -new -key webmail.pem -out webmailcert.p10 ¡¡Importante!! Entre los datos importantes introducidos al crear la solicitud de certificado del servicio Webmail, el más importante es el “Common Name”, el cual debe corresponderse con el nombre de dominio cualificado (FQDN) asociado al servicio web que se quiere dar. Es decir, deberá coincidir con el valor asignado a la directiva “ServerName” de configuración de “Apache”. En este caso, para el primer servidor de correo, “webmail.servidormail1.es” tal como ya se definió previamente en el servicio DNS. Ahora la CA firmará la solicitud anterior generando el correspondiente certificado: [root@servidorwebmail]# openssl x509 -req -in webmailcert.p10 -out webmailcert.pem \ -CA ../ca/cacert.pem -CAkey ../ca/ca.pem -CAcreateserial -days 365 [root@servidorwebmail]# nano /etc/apache2/sites-available/servicio-webmail.conf Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 77

… NameVirtualHost 192.168.1.254:443 # Solo se indicará si es necesaria DocumentRoot /usr/share/squirrelmail ServerName webmail.servidormail1.es SSLEngine on SSLCipherSuite RSA:+HIGH:+MEDIUM SSLProtocol all -SSLv2 SSLCertificateFile /etc/apache2/webmail/webmailcert.pem SSLCertificateKeyFile /etc/apache2/webmail/webmail.pem SSLCACertificateFile /etc/apache2/ca/cacert.pem Allow from all ¡¡Aclaración!! La directiva “NameVirtualHost tan sólo será necesaria si el servidor Web Apache ya esta sirviendo otro sitio Web bajo la misma dirección IP y el mismo puerto “192.168.1.254:443”. Es decir, esta directiva advierte a Apache, que en el caso de se hayan definido más de un “VirtualHost” con la misma dirección IP y el mismo puerto, debe fijarse en el “ServerName” de la URL solicitada para saber que sitio Web debe servir. Esta directiva sólo debe aparecer una vez por IP y puerto, independientemente del número de “VirtualHost” habilitados en la configuración que lo cumplan. Por ello, al tener que definirse una sola vez, por cuestión de organización, sería mejor colocar esa directiva en caso de ser necesaria en el fichero “/etc/apache2/ports.conf”. 3) Tras configurar el nuevo sitio Web seguro o no, asociado al servicio Webmail de “squirrelmail”, tan sólo nos quedará habilitar el sitio Web anterior, habilitar el módulo “ssl” en el caso de querer dar el servicio en modo seguro y reiniciar “Apache” para que surtan efecto los cambios en la configuración. [root@servidorwebmail]# a2ensite servicio-webmail.conf [root@servidorwebmail]# a2enmod ssl [root@servidorwebmail]# /etc/init.d/apache2 restart

Ahora ya deberíamos poder visualizar nuestro sitio web Webmail, si desde un equipo cliente iniciamos un navegador Web, que tenga configurado como servidor DNS la dirección IP del equipo Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 78

donde se ha configurado el servicio DNS al comienzo de la práctica, colocando en su barra de direcciones “http://webmail.servidormail1.es” si se quiere conectar al servicio Webmail del primer dominio, o “http://webmail.servidormail2.es” si lo quiere hacer en el segundo. Al conectarnos advertiremos que el sitio Webmail está sin personalizar: en inglés, con el logotipo y título de “squirrelmail”, etc. Por tanto, el último paso será configurar el “squirrelmail” y de esta forma personalizar la aplicación. Para ello ejecutaremos el script de configuración “/etc/squirrelmail/conf.pl”, desde el cual encontraremos opciones para personalizar prácticamente todo: [root@servidorwebmail]# /etc/squirrelmail/conf.pl

Tal como se podrá observar, con la opción “1” del menú principal configuraremos las preferencias, con la “2” los datos relativos al equipo servidor, y al propio servicio, y así con el resto de opciones. A continuación se detalla alguna de las opciones más importantes: •

Opción nº1 del menú principal: nos permite personalizar el nombre de la organización, el logo que se mostrará en la página de inicio del sitio Webmail (la imagen logo deberá estar en formato “png” en /usr/share/squirrelmail/images), las dimensiones del logo, etc.

•

Opción nº2 del menú principal: nos permite informar a “squirrelmail” sobre los servidores SMTP y IMAP. De este submenú elegiremos la opción “A” para configurar las opciones del protocolo IMAP. En concreto le informaremos de que el software que estamos utilizando como servidor IMAP es “dovecot”.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 79

•

Opción nº3 del menú principal: nos permite personalizar los nombres que se asignarán a los enlaces de la aplicación Web que nos permiten ver los mensajes enviados, borradores o enviados a la basura.

•

Opción nº10 del menú principal: nos permite personalizar el idioma de la aplicación Webmail. En el caso de que queramos que el idioma sea el español deberemos seleccionar el idioma “es_ES”, además de configurar el sistema mediante los comandos “dpkg-reconfigure locales” y “locale-gen es_ES”.

[root@linux]# dpkg-reconfigure locales # Deberemos seleccionar: “es_ES iso-8859-1” [root@linux]# locale-gen es_ES [root@linux]# /etc/init.d/apache restart Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 80

Por último, tas sólo será necesario comprobar que se pueden enviar perfectamente los correos entre usuarios de un dominio y otro tras iniciar sesión con el nombre de usuario correspondiente (p.e. “usuario1” y su correspondiente password del sistema).

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 81

Práctica nº14.- Configuración de la Raspberry para gestión Domótica En esta última parte de las prácticas planteadas para la Raspberry, se mostrará como utilizarla para controlar cualquiera de los dispositivos eléctricos que se nos ocurra. Para ello gestionaremos el puerto de entradas/salidas de propósito general GPIO (General Purpose Input Output) del que dispone nuestra Raspberry, y que nos permite interactuar con elementos externos.

En concreto disponemos de dos opciones: Opción Nº1) Controlar directamente los pines de entrada/salida del puerto GPIO mediante la ayuda de librerías existentes en entornos de programación en Python y Java. El problema que presenta esa opción es que la manipulación directa de dichos puertos no es aconsejable por usuarios inexpertos (electrónicamente hablando), ya que son pines sin ningún tipo de sistema de protección. Esto implica que si por un descuido cortocircuitáramos alguno de ellos, podríamos deteriorar la Raspberry. Opción Nº2) Controlarla mediante la ayuda de un “shield” que proteja a la Raspberry en su manejo. Entre los distintos “shields” que existen en el mercado, por sus características y versatilidad se ha elegido el “Arduino shield” diseñado y distribuido por la empresa Zaragozana “Cooking Hacks/Libelium”. Este nos ofrece las siguientes características: • • • •

Nos garantiza 100% de compatibilidad con todos los módulos ya existentes para Arduino. Esto nos permite desarrollar entornos muy versátiles. Nos permite poder trabajar con señales analógicas procedentes de cualquier sensor (temperatura, humedad, velocidad del viento, etc.) de que dispongamos. Nos permite reutilizar la infinidad de programas que ya hay desarrollados para sistemas Arduino. El lenguaje de programación utilizado para el desarrollo de aplicaciones es C, un lenguaje Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 82

•

muy sencillo e intuitivo. Protege al puerto de entradas salidas GPIO.

El único inconveniente que presenta de momento es el coste, ya que este “shield” cuesta actualmente más que la propia Raspberry.

14.1.- Control directo del GPIO de la Raspberry. En el caso de querer controlar elementos externos directamente desde los puertos de entrada y salida de propósito general GPIO (General Purpose Input Output) de la Raspberry será necesario conocer en primer lugar su patillaje:

Como puede observarse, el puerto GPIO esta compuesto por 26 patillas, de las cuales algunas de ellas no son configurables (patillas de alimentación y de referencia o masa, patillas de comunicación con elementos externos como UART o SPI, etc.) y otras que sí que lo son (las patillas de propósito general GPIO pueden configurarse como entrada o salida). A la hora de gestionar el GPIO existen numerosas alternativas: en lenguaje C, Java, Phyton, etc. Pero a mi parecer, la forma más sencilla de gestionarlo es mediante comandos específicos de la shell del sistema, ofreciéndonos la opción de poderse ejecutar directamente desde una consola o terminal del sistema o embeber en cualquiera de los lenguajes de programación que existen. En el ejemplo que se mostrará a continuación, se ha desarrollado una sencilla aplicación Web en PHP que permite ejecutar comandos del sistema de gestión del GPIO desde un cliente Web.

14.1.1.- Control directo del GPIO: Instalación de wiringPi.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 83

Antes de empezar a controlar elementos externos, habrá que instalar el programa o librería “wiringPi”, para lo que seguiremos los siguientes pasos: [pi@raspberry]# sudo su [root@raspberry]# apt-get update; apt-get upgrade [root@raspberry]# apt-get install git-core [root@raspberry]# exit #No requerimos ser el root para la gestión GPIO mediante wiringPi [pi@raspberry]# git clone git://git.drogon.net/wiringPi #Descargamos la librería necesaria [pi@raspberry]# cd wiringPi [pi@raspberry]# git pull origin #Comprobación de que esta actualizado [pi@raspberry]# ./build Para comprobar que se ha instalado correctamente podemos ejecutar los siguientes comandos, que nos dará información del estado de cada uno de los puertos GPIO: [pi@raspberry]# gpio readall Además, si queremos hacer algunas pruebas de gestión del GPIO, podríamos conectar alguna resistencia y diodo led entre cualesquiera de los puertos de propósito general del GPIO y masa o GND, configurar a continuación el correspondiente puerto como salida (out), y encender y apagar el diodo led en función de si la salida esta a “1” o “0” respectivamente. Por ejemplo, si suponemos que hemos colocado una resistencia de 330Ω en serie con un diodo emisor de luz (LED) entre el pin 22 (GPIO 25) y el pin 20 (GND/masa) y deseamos controlar su encendido mediante comandos de la shell: [pi@raspberry]# gpio -g mode 25 out #Definimos el pin 22, GPIO 25, como salida [pi@raspberry]# gpio -g write 25 1 #Ponemos en estado alto el GPIO 25, encendiendo el LED [pi@raspberry]# gpio -g write 25 0 #Ponemos en estado bajo el GPIO 25, apagando el LED ¡¡Importante!! Como puede advertirse de los ejemplos anteriores, para hacer referencia a un pin o puerto del GPIO no se hace uso de su número o posición (p.e. pin 22), sino a su identificador (p.e. GPIO 25).

14.1.2.- Gestión Domótica vía web en modo seguro HTTPS: Control directo del GPIO Ahora haremos uso de la gestión de puertos remotamente vía Web a través de un sitio que hallamos configurado en nuestro servidor Web (p.e. Apache). En cuanto a la configuración de Apache para dar un servicio en modo seguro HTTPS: 1) Para garantizar una comunicación segura, crearemos un nuevo sitio Web en Apache basado en un VirtualHost que escuche por el puerto 443 (p.e. ejemplo-domotico1.conf). Por ello, lo primero será crear un certificado para el nuevo servicio que vamos a ofrecer (suponemos que la entidad certificadora ya fue creada en la práctica Nº9 correspondiente a HTTP/HTTPS): ¡¡Importante!! Repasar lo visto ya en la práctica Nº9 correspondiente a configurar la Raspberry como servidor HTTP/HTTPS. [root@raspberry]# mkdir /etc/apache2/server2 [root@raspberry]# cd /etc/apache2/server2 Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 84

[root@raspberry]# openssl genrsa -out server2.pem 2048 [root@raspberry]# openssl req -new -key server2.pem -out server2cert.p10 ¡¡Importante!! Entre los datos importantes introducidos al crear la solicitud de certificado del servidor Web, el más importante es el “Common Name”, el cual debe corresponderse con el nombre de dominio cualificado (FQDN) asociado al servicio web que se quiere dar. Por ejemplo, “domotica.miservidor.es”. Por ello, configuraremos el servicio DNS dando de alta la zona o nombre de dominio deseado (p.e. “miservidor.es”), junto con el nombre del equipo correspondiente (p.e. “domotica.miservidor.es”). Ahora la CA firmará la solicitud anterior generando el correspondiente certificado: [root@raspberry]# openssl x509 -req -in server2cert.p10 -out server2cert.pem \ -CA ../ca/cacert.pem -CAkey ../ca/ca.pem -CAcreateserial -days 365 [root@raspberry]# nano /etc/apache2/sites-available/ejemplo-domotico1.conf ServerName domotica.miservidor.es DocumentRoot /var/www/domotica1 DirectoryIndex index.php SSLEngine on SSLCipherSuite RSA:+HIGH:+MEDIUM SSLProtocol all -SSLv2 SSLCertificateFile /etc/apache2/server2/server2cert.pem SSLCertificateKeyFile /etc/apache2/server2/server2.pem SSLCACertificateFile /etc/apache2/ca/cacert.pem Allow from all Tras configurar el nuevo sitio Web seguro, tan sólo tendremos que habilitarlo y reiniciar el servicio para que surtan efecto los cambios: [root@raspberry]# a2ensite ejemplo-domotico1.conf [root@raspberry]# /etc/init.d/apache2 restart 2) Para poder progamar nuestro sitio Web en PHP, deberemos previamente instalar la librería en Apache que le permite interpretar código PHP: [root@raspberry]# apt-get install libapache2-mod_php5 3) Para evitar que intrusos de manera malintencionada controlen los dispositivos externos que se desean controlar con la aplicación, será necesario autenticarse. Un ejemplo básico de código PHP para la página “index.php” sería el siguiente, donde mediante variables de sesión “$_SESSION” almacenamos la correcto autenticación del usuario y redireccionamiento hacia el resto de las páginas del sitio Web (p.e. “control1.php”): En cuanto al contenido de la página de inicio del sitio Web de gestión domótica (el “index.php” controla el acceso de usuarios a la página Web desde la cual se establece el control Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 85

domótico), y la subpágina Web (control1.php) encargada de interactuar con el usuario para permitir la gestión domótica podría ser el que se muestra a continuación: ¡¡Importante!! Mediante la ayuda de la función PHP “shell_exec()” ejecutaremos el comando del sistema “gpio” que controla el estado de los puertos de entrada y salida del GPIO de la Raspberry. En concreto, a modo de ejemplo se puede controlar el estado de un led que haya conectado en el puerto GPIO25, pero podría ser el estado de una bombilla a través de un relé o cualquier otro dispositivo eléctrico. [root@raspberry]# nano /var/www/web/index.php fieldset.f1 { width: 50%; margin-top: 100px; margin-left: auto; margin-right: auto; background-color: yellow; text-align: center; } fieldset.f2 { width: 50%; margin-left: auto; margin-right: auto; background-color: black; color: white; text-align: center; } Control de Acceso Nombre: Password: Respuesta ante la autenticacion Lo sentimos ... Tu login o password son falsos. [root@raspberry]# nano /var/www/web/control1.php fieldset.f3 { width: 100%; margin-top: 0px; margin-left: auto; margin-right: auto; background-color: lightblue; color: brown; text-align: right; } Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 86

fieldset.f4 { width: 80%; margin-top: 100px; margin-left: auto; margin-right: auto; background-color: orange; text-align: center; } fieldset.f5 { width: 50%; margin-top: 100px; margin-left: auto; margin-right: auto; background-color: black; color: white; text-align: center; } Bienvenido Sr. ( Cerrar Sesión ) Elije que quieres hacer Acción: --Elige una opcion-- Encender la bombilla Apagar la bombilla Problema de Seguridad No deberías tratar de acceder por aquí. Debes autenticarte primero. Gracias. VOLVER PAGINA INICIO

14.2.- Raspberry con Shield Arduino. Configuración previa Antes de poder empezar a programar aplicaciones de control domótico deberemos preparar a la Raspberry para que pueda trabajar con el “Arduino shield”. Los pasos a seguir son descritos por los propios desarrolladores del “shield” en su página Web: “http://www.cooking-hacks.com/index.php/documentation/tutorials/raspberry-pi-toarduino-shields-connection-bridge”.

1) Descargar desde la URL anterior la librería “arduPi”. 2) Editar los archivos de configuración “/boot/cmdline.txt” y “/etc/inittab”, y reiniciar para que surtan efecto los cambios: [pi@raspberry]# sudo su [root@raspberry]# cp /boot/cmdline.txt /boot/cmdline_backup.txt [root@raspberry]# vi /boot/cmdline.txt #dwc_otg.lpm_enable=0 console=ttyAMA0,115200 kgdboc=ttyAMA0,115200 console=tty1 $ # Eliminar todo lo referente a ttyAMA0 de la línea anterior dwc_otg.lpm_enable=0 console=tty1 $ [root@raspberry]# nano /etc/inittab # Comentar en inittab la línea siguiente: ## T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100 [root@raspberry]# reboot

14.2.1.- Ejemplos básicos de control de dispositivos externo mediante el Shield Arduino. A continuación se mostrarán tres ejemplos muy básicos de gestión de entradas y salidas a través del puerto GPIO. Antes de empezar a programar, en primer lugar compilaremos la librería “arduPi” que te habrás descargado en el apartado anterior, ya que será necesaria para la posterior compilación de cualquier otro programa que la requiera: [root@raspberry]# g++ -c arduPi.cpp -o arduPi.o Ahora, una vez realizado nuestro programa lo compilaremos apoyándonos en la librería anterior, ejecutando el siguiente comando: [root@raspberry]# g++ -lrt -lpthread mi_programa.cpp arduPi.o -o mi_programa

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 88

Ejemplo 1º) Encender/Apagar un led externo conectado en el Pin2 del “Arduino shield”. El siguiente código muestra la estructura que deberá tener todo programa que quiera gestionar los puertos del “Arduino shield” mediante la ayuda de la librería “arduPi”: // Incluimos la librería arduPi #include "arduPi.h" // Necesario para la comunicación serie SerialPi Serial; // Necesario para aceder a GPIO: pinMode, digitalWrite, digitalRead, i2C functions WirePi Wire; //Necesario para SPI SPIPi SPI; // Zona Declaración de funciones que se usarán en el programa principal // → Funciones que serán llamadas desde el código que se programe a continuación

// A continuación declararemos el código arduino // → Código // Estructura general de todo programa cíclico (loop): int main (){ setup(); while(1){ loop(); } return (0); }

En concreto si queremos encender/apagar un led externo conectado en el Pin2, haremos uso de la estrutura anterior, pero eliminado el bucle, al no tratarse de algo repetitivo: [root@raspberry]# nano ejemplo1.cpp // Incluimos la librería arduPi #include "arduPi.h" // Necesario para la comunicación serie SerialPi Serial; // Necesario para acceder a GPIO: pinMode, digitalWrite, digitalRead, i2C functions WirePi Wire; //Necesario para SPI SPIPi SPI; // Definimos el pin 2 como pin de salida: deberá haber una resistencia (p.e. 370Ω) y un led en serie int ledPin2rojo = 2; void setup() { pinMode(ledPin2rojo, OUTPUT); } // Programa principal int main (){ setup(); //Encendemos el led rojo que hay conectado en el pin2 del “Arduino shield” digitalWrite(ledPin2rojo, HIGH); //Lo mantenemos encendido 5 segundos delay(5000);

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 89

//Por último lo apagamos digitalWrite(ledPin2rojo, LOW); //Salimos del programa return (0); }

Y para probarlo: [root@raspberry]# g++ -lrt -lpthread ejemplo1.cpp arduPi.o -o ejemplo1 [root@raspberry]# ./ejemplo1 Ejemplo 2º) Encender/Apagar dos leds externos conectado en el Pin2 y Pin6 del “Arduino shield” periódicamente: cada ciclo será de 4 segundos de los cuales, la mitad del ciclo permanecerá encendido el primero y apagado el segundo, y la otra mitad se invertirá el estado de estos. [root@raspberry]# nano ejemplo2.cpp // Incluimos la librería arduPi #include "arduPi.h" // Necesario para la comunicación serie SerialPi Serial; // Necesario para aceder a GPIO: pinMode, digitalWrite, digitalRead, i2C functions WirePi Wire; //Necesario para SPI SPIPi SPI; // Definimos los pines 2 y 6 del Arduino shield como salidas int ledPin2rojo = 2; int ledPin6verde = 6; void setup() { pinMode(ledPin2rojo, OUTPUT); pinMode(ledPin6verde, OUTPUT); } // Programamos lo que ocurrirá en cada ciclo void loop() { digitalWrite(ledPin2rojo, HIGH); digitalWrite(ledPin6verde, LOW); delay(2000); digitalWrite(ledPin2rojo, LOW); digitalWrite(ledPin6verde, HIGH); delay(2000); } // Editamos el programa principal int main (){ setup(); while(1){ loop(); } return (0); }

Y para probarlo: Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 90

[root@raspberry]# g++ -lrt -lpthread ejemplo2.cpp arduPi.o -o ejemplo2 [root@raspberry]# ./ejemplo2 Ejemplo 3º) Encender/Apagar dos leds externos conectado en el Pin2 y Pin6 en función del estado de dos interruptores externos. Pulsar sobre el primero provocará encender el led que se encuentra conectado en el Pin2 y apagar el que esta en el Pin6, y pulsar sobre el segundo, provocaría lo contrario. Además a modo de ejmplo se mostrará como ejecutar comandos del sistema GNU/Linux Raspbian desde el programa en C, mediante el comando “system()”. Para ello será necesario incluir la librería “stdio.h” (#include "stdio.h") al comienzo del programa. En concreto, en un fichero externo llamado “auditoria.dat” guardaremos la secuencia de lo que estamos haciendo: [root@raspberry]# nano ejemplo2.cpp // Incluimos la librería arduPi #include "arduPi.h" // Necesario para la comunicación serie SerialPi Serial; // Necesario para aceder a GPIO: pinMode, digitalWrite, digitalRead, i2C functions WirePi Wire; //Necesario para SPI SPIPi SPI; // Definimos los pines 2 y 6 del Arduino shield como salidas int ledPin2rojo = 2; int ledPin3verde = 3; int interruptor1Pin4 = 4; int interruptor2Pin5 = 5; void setup() { pinMode(ledPin2rojo, OUTPUT); pinMode(ledPin3verde, OUTPUT); pinMode(interruptor1Pin4, INPUT); pinMode(interruptor2Pin5, INPUT); } // Programamos lo que ocurrirá en cada ciclo void loop() { valor1 = digitalREad(interruptor1Pin4); valor2 = digitalREad(interruptor2Pin5); if ( valor1 == HIGH && valor2 == LOW ) { digitalWrite(ledPin2rojo, LOW); digitalWrite(ledPin3verde, HIGH); system(“echo `date +%H:%M_%d/%m/%y` Led Verde ON >> auditoria.dat”);

} if ( valor2 == HIGH && valor1 == LOW ) { digitalWrite(ledPin2rojo, HIGH); digitalWrite(ledPin3verde, LOW); system(“echo `date +%H:%M_%d/%m/%y` Led Rojo ON >> auditoria.dat”);

}

} // Editamos el programa principal int main (){

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 91

setup(); while(1){ loop(); } return (0); }

Y para probarlo: [root@raspberry]# g++ -lrt -lpthread ejemplo3.cpp arduPi.o -o ejemplo3 [root@raspberry]# ./ejemplo3

14.2.2.- Gestión Domótica vía web en modo seguro HTTPS de dispositivos externos mediante Shield Arduino. A continuación se mostrará como de una manera muy sencilla podemos ejecutar los programas que hayamos programado para el control de dispositivos externos pero sin la necesidad de la acción directa del humano, sino remotamente a través de un navegador Web mediante nuestro smartphone, tablet u ordenador (portátil o de sobremesa). En concreto en el ejemplo que se muestra a continuación se tendrán en cuenta las siguientes características: 1) la comunicación será segura entre el navegador Web y la Raspberry mediante el protocolo HTTPS, 2) el acceso será restringido mediante login y password, 3) los diálogos de comunicación entre el cliente y servidor se basarán en formularios HTML, 4) el lenguaje de programación utilizado en el lado del servidor (Raspberry) encargado de atender las ordenes enviadas desde el cliente Web será PHP y 5) el dispositivo a controlar en este caso a modo de ejemplo será una bombilla conectada a la red eléctrica (230v/50Hz) mediante un triac optoacoplado o relé de estado sólido (p.e. S108T02), a través del pin nº2 del puerto de I/O del “Arduino shield” (a modo de práctica se puede hacer simplemente conectando un led en el pin nº2 y probar a encenderlo y apagarlo). RLED

Triac Optoacoplado Relé de estado sólido

VRED 230V/50Hz

1) Para garantizar una comunicación segura, crearemos un nuevo sitio Web en Apache basado en un VirtualHost que escuche por el puerto 443 (p.e. ejemplo-domotico1.conf). Por ello, lo primero será crear un certificado para el nuevo servicio que vamos a ofrecer (suponemos que la entidad certificadora ya fue creada en la práctica Nº9 correspondiente a HTTP/HTTPS): ¡¡Importante!! Repasar lo visto ya en la práctica Nº9 correspondiente a configurar la Raspberry como servidor HTTP/HTTPS. [root@raspberry]# mkdir /etc/apache2/server2 Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 92

[root@raspberry]# cd /etc/apache2/server2 [root@raspberry]# openssl genrsa -out server2.pem 2048 [root@raspberry]# openssl req -new -key server2.pem -out server2cert.p10 ¡¡Importante!! Entre los datos importantes introducidos al crear la solicitud de certificado del servidor Web, el más importante es el “Common Name”, el cual debe corresponderse con el nombre de dominio cualificado (FQDN) asociado al servicio web que se quiere dar. Por ejemplo, “domotica.miservidor.es”. Por ello, configuraremos el servicio DNS dando de alta la zona o nombre de dominio deseado (p.e. “miservidor.es”), junto con el nombre del equipo correspondiente (p.e. “domotica.miservidor.es”). Ahora la CA firmará la solicitud anterior generando el correspondiente certificado: [root@raspberry]# openssl x509 -req -in server2cert.p10 -out server2cert.pem \ -CA ../ca/cacert.pem -CAkey ../ca/ca.pem -CAcreateserial -days 365 [root@raspberry]# nano /etc/apache2/sites-available/ejemplo-domotico1.conf ServerName domotica.miservidor.es DocumentRoot /var/www/domotica1 DirectoryIndex index.php SSLEngine on SSLCipherSuite RSA:+HIGH:+MEDIUM SSLProtocol all -SSLv2 SSLCertificateFile /etc/apache2/server2/server2cert.pem SSLCertificateKeyFile /etc/apache2/server2/server2.pem SSLCACertificateFile /etc/apache2/ca/cacert.pem Allow from all Tras configurar el nuevo sitio Web seguro, tan sólo tendremos que habilitarlo y reiniciar el servicio para que surtan efecto los cambios: [root@raspberry]# a2ensite ejemplo-domotico1.conf [root@raspberry]# /etc/init.d/apache2 restart 2) Para poder progamar nuestro sitio Web en PHP, deberemos previamente instalar la librería en Apache que le permite interpretar código PHP: [root@raspberry]# apt-get install libapache2-mod_php5 3) Para evitar que intrusos de manera malintencionada controlen los dispositivos externos que se desean controlar con la aplicación, será necesario autenticarse. Un ejemplo básico de código PHP para la página “index.php” sería el siguiente, donde mediante variables de sesión “$_SESSION” almacenamos la correcto autenticación del usuario y redireccionamiento hacia el resto de las páginas del sitio Web (p.e. “control1.php”): [root@raspberry]# nano /var/www/domotica1/index.php Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 93

fieldset.f1 { width: 50%; margin-top: 100px; margin-left: auto; margin-right: auto; background-color: yellow; text-align: center; } fieldset.f2 { width: 50%; margin-left: auto; margin-right: auto; background-color: black; color: white; text-align: center; } Control de Acceso Nombre: Password: Respuesta ante la autenticacion Lo sentimos ... Tu login o password son falsos. 4) Mediante el uso de un formulario HTML el usuario podrá decidir la acción a realizar sobre los elementos externos: [root@raspberry]# nano /var/www/domotica1/control1.php fieldset.f3 { width: 100%; margin-top: 0px; margin-left: auto; margin-right: auto; background-color: lightblue; color: brown; text-align: right; } fieldset.f4 { width: 80%; margin-top: 100px; margin-left: auto; margin-right: auto; background-color: orange; text-align: center; } fieldset.f5 { width: 50%; margin-top: 100px; margin-left: auto; margin-right: auto; Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 94

background-color: black; color: white; text-align: center; } Bienvenido Sr. ( Cerrar Sesión ) Elije que quieres hacer Acción: --Elige una opcion-- Encender la bombilla Apagar la bombilla Problema de Seguridad No deberías tratar de acceder por aquí. Debes autenticarte primero. Gracias. VOLVER PAGINA INICIO Donde el contenido de el contenido de los programas “encender” y “apagar” sería: [root@raspberry]# nano encender.cpp // Incluimos la librería arduPi #include "arduPi.h" // Necesario para la comunicación serie SerialPi Serial; // Necesario para aceder a GPIO: pinMode, digitalWrite, digitalRead, i2C functions WirePi Wire; //Necesario para SPI SPIPi SPI; // Definimos el pin 2 como pin de salida: deberá haber una resistencia (p.e. 370Ω) y el anodo del led del triac optoacoplado int optoPin2 = 2; void setup() { pinMode(optoPin2, OUTPUT); } // Programa principal int main (){ setup(); //Encendemos la bombilla al excitar el led del triac optoacoplado digitalWrite(ledPin2rojo, HIGH); return (0); }

[root@raspberry]# nano apagar.cpp // Incluimos la librería arduPi #include "arduPi.h" // Necesario para la comunicación serie SerialPi Serial; // Necesario para aceder a GPIO: pinMode, digitalWrite, digitalRead, i2C functions WirePi Wire; //Necesario para SPI SPIPi SPI; // Definimos el pin 2 como pin de salida: deberá haber una resistencia (p.e. 370Ω) y el anodo del led del triac optoacoplado int optoPin2 = 2; void setup() { pinMode(optoPin2, OUTPUT); } // Programa principal int main (){ setup(); //Apagamos la bombilla al excitar el led del triac optoacoplado

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 96

digitalWrite(ledPin2rojo, LOW); return (0); }

Y para poder probar su ejecución vía web, previamente habrá que compilarlos: [root@raspberry]# g++ -lrt -lpthread encender.cpp arduPi.o -o encender [root@raspberry]# g++ -lrt -lpthread apagar.cpp arduPi.o -o apagar Ahora deberíamos acceder desde un navegador Web al servicio HTTPS servidor por Apache, y tras autenticarnos deberíamos estar encendiendo o apagando la bombilla externa, en función de la opción elegida en el campo “select” del formulario.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 97

Práctica nº15.- Implementación final de la Estación de Servicios. Haciendo uso de lo aprendido a lo largo de las diferentes prácticas presentadas en este documento, pasaremos a implementar la mayor parte de los servicios en un entorno de producción real. Para ello, en esta última práctica deberás configurar la conexión ADSL de tu casa para redireccionar determinados puertos del router ISP hacia la Raspberry que se encontrará en la Intranet de tu vivienda, y así de esta forma poder ofrecer los siguientes servicios públicos (serán comprobados por el profesor desde clase): - Deberás registrarte en “no-ip” y dar de alta un nombre de dominio público cualificado (FQDN) que se corresponda con la dirección IP pública asignada a tu router ISP: “nombre_alumno.no-ip.org”. Posteriormente será conveniente que instales en un equipo de la Intranet el software “no-ip” para que informe a los servidores DNS de “no-ip” de algún posible cambio de tu dirección pública, en el caso de que esta sea dinámica. - Deberás redireccionar los siguientes puertos del router ISP hacía la Raspberry: 22-SSH, 443-HTTPS y 1194-VPN. De esta forma podremos gestionar remotamente nuestra estación de servicios vía SSH, hacer un control domótico o de otro tipo vía HTTPS y acceder a todos los recursos (p.e. vía SMB/CIFS) que se comparten en la Intranet gracias a la VPN. - Deberás crear una cuenta SSH para el profesor (login/password): “profesor/1234321”. De esta forma, vía SSH el profesor podrá comprobar todas las configuraciones realizadas.

Configuración de la Raspberry Pi como estación de Servicios – Arturo Martín Romero 98