Raspberry Pi como servidora multiuso

IMPLEMENTACIN DE
SERVICIOS DE RED
MEDIANTE UNA
RASPBERRY PI
VERSIN 13.3.2
IES TIEMPOS MODERNOS

Zaragoza ESPAA
Arturo Martn Romero
Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 1
Hace escasamente un ao, en febrero del 2012 sali al mercado el

microcomputador Raspberry Pi con la finalidad de acercar y facilitar a los
docentes la enseanza 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. Adems de
estas, otra posibilidad de uso de la Raspberry Pi es la que se va a presentar
en el presente tutorial de prcticas, en la que se presenta a la Raspberry Pi
como una perfecta estacin 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 domtico, 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.
Segn el informe del ao 2012 del Ministerio de Industria, Energa y
Turismo, en enero del 2011 haba en Espaa 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% tenan menos de 9 asalariados. Teniendo en cuenta que
toda empresa necesita de una informatizacin para una mayor
competitividad, el uso de un microcomputador como la Raspberry Pi puede
ser la solucin 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 reducidsimo coste, mnimo volumen y
bajsimo consumo elctrico.
Espero que este manual despierte en muchos el inters por el rea de la
informtica relativa a la implementacin de servidores, y aumente al mismo
tiempo su sagacidad y un mayor afn de experimentacin.
El manual se encuentra bajo licencia creative commons, por lo
cual eres libre para compartir, copiar, distribuir, ejecutar y comunicar
pblicamente la obra, adems de hacer obras derivadas. Tan slo tendrs
que tener en cuenta la atribucin al autor, hacer un uso no comercial de ella,
y en caso de compartirlo, hacerlo bajo la misma licencia.
Para cualquier cuestin, constructiva o destructiva, que pueda mejorar el

presente manual, por favor no dudis en poneros en contacto conmigo.
Saludos,
Arturo Martn Romero
amartinromero@gmail.com
MicroComputador Raspberry Pi
Servicios Gateway/DHCP/DNS/Proxy HTTP
Punto de acceso/Repetidor
Controlador de Dominio Principal (PDC)
Servicio de autenticacin RADIUS
Servicio NAS (SMB/FTP/NFS/SSHFS)
Copias de Seguridad Remotas
Servicio HTTP/HTTPS
Servicio de Correo WebMail
Servicio VPN
Control Domtico Va Web
ndice de Prcticas
Prctica n1.-Instalacin del Sistema Operativo Raspbian..............................................................5
Prctica n2.-Primer Arranque de la Raspberry Pi...........................................................................7
Prctica n3.-Conexin a Internet de la Raspberry........................................................................10
3.1.- Configuracin de la Interfaz Inalmbrica de manera grfica (GUI).................................10
3.2.- Configuracin de la Interfaz Inalmbrica desde la terminal (CLUI)................................10
3.3.- Actualizacin de los Repositorios y del Software del Sistema.........................................11
Prctica n4.-Configuracin de la Raspberry como servidor DHCP..............................................12
4.1.- Instalacin del software servidor DHCP...........................................................................13
4.2.- Configuracin del servicio DHCP....................................................................................13
4.3.- Configuracin de los clientes DHCP................................................................................14
Prctica n5.-Configuracin de la Raspberry como servidor DNS................................................16
5.1.- Instalacin y Configuracin del servicio DNS.................................................................16
5.2.- Raspberry Pi como servidor DNS Maestro......................................................................16
5.3.- Comprobacin del servicio DNS......................................................................................17
Prctica n6.-Configuracin de la Raspberry como Puerta de Enlace...........................................19
6.1.- Configuracin bsica de la Raspberry como Firewall......................................................20
6.2.- Configuracin de la Raspberry como Punto de Acceso (AP)...........................................21
Prctica n7.-Configuracin de la Raspberry como servidor RADIUS.........................................24
7.1.- Introduccin al servicio RADIUS....................................................................................24
7.2.- Definiciones previas: RADIUS, NAS, WEP, WPA..........................................................25
7.3.- Instalacin y Configuracin de FreeRADIUS..................................................................28
7.3.- Configuracin del punto de Acceso..................................................................................30
Prctica n8.-Configuracin de la Raspberry como unidad de red Network-Attached Storage
(NAS).............................................................................................................................................31
8.1.- Configuracin de la Raspberry como servidor FTP..........................................................32
8.2.- Configuracin de la Raspberry como servidor CIFS/SMB..............................................36
8.3.- Configuracin de la Raspberry como servidor SSHFS....................................................38
8.4.- Configuracin de la Raspberry como servidor NFS.........................................................39
Prctica n9.-Configuracin de la Raspberry como servidor HTTP/HTTPS................................42
9.1.- Creacin de la Entidad Certificadora (CA).......................................................................42
9.2.- Creacin de las claves y certificados del servicio HTTPS...............................................42

9.3.- Configuracin de Apache para dar un servicio HTTPS....................................................43
Prctica n10.-Configuracin de la Raspberry como Proxy HTTP................................................47
10.1.- Configuracin previa del Entorno de Red......................................................................48
10.2.- Instalacin del software servidor....................................................................................50
10.3.- Configuracin de la Raspberry como proxy no transparente.........................................50
10.4.- Configuracin de la Raspberry como proxy transparente..............................................53
Prctica n11.-Configuracin de la Raspberry como servidor VPN..............................................56
11.1.- Configuracin del Router ISP.........................................................................................57
11.2.- Instalacin del Software OpenVPN................................................................................58
11.3.- Instalacin de OpenSSL. Creacin de la Autoridad de Certificacin (CA), y las Claves
y Certificados del Servidor y de los Clientes............................................................................58
11.4.- Configuracin del Servidor VPN....................................................................................59
11.5.- Configuracin de los clientes VPN.................................................................................61
Prctica n12.-Raspberry como controlador de dominio primario (PDC).....................................64
12.1.- Registro de los nombres de dominio en el servidor DNS Bind......................................65
12.2.- Instalacin del software servidor PDC: Samba..............................................................66
12.3.- Configuracin de Samba como PDC..............................................................................66
12.4.- Creacin de Cuentas de Usuario del Dominio................................................................68
12.5.- Creacin de Cuentas de Mquinas Clientes del Dominio...............................................69
12.6.- Configuracin del Cliente para agregarlo al Dominio....................................................69
Prctica n13.-Configuracin de la Raspberry como servidor Webmail........................................70
13.1.- Configuracin del servicio DNS Bind............................................................................71
13.2.- Instalacin y Configuracin del servidor SMTP PostFix...............................................73
13.3.- Instalacin y Configuracin del servidor IMAP Dovecot..............................................75
13.4.- Instalacin y Configuracin del servidor HTTP WebMail: Apache y Squirrelmail.......76
Prctica n14.-Configuracin de la Raspberry para gestin Domtica..........................................82
14.1.- Control directo del GPIO de la Raspberry......................................................................83
14.1.1.- Control directo del GPIO: Instalacin de wiringPi......................................................83
14.1.2.- Gestin Domtica va web en modo seguro HTTPS: Control directo del GPIO........84
14.2.- Raspberry con Shield Arduino. Configuracin previa....................................................88
14.2.1.- Ejemplos bsicos de control de dispositivos externo mediante el Shield Arduino......88
14.2.2.- Gestin Domtica va web en modo seguro HTTPS de dispositivos externos mediante
Shield Arduino..........................................................................................................................92
Prctica n15.-Implementacin final de la Estacin de Servicios..................................................98
Prctica n1.- Instalacin del Sistema Operativo Raspbian

Antes de instalar el sistema operativo deberemos descargar previamente desde Internet la
ltima versin de la distribucin que queramos instalar en nuestra Raspberry. En concreto puedes
instalar como sistema operativo Raspbian (versin Debian para Raspberry), Arch Linux o
Risc OS. Por comodidad y mayor facilidad para el alumno, para la presente prctica 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, debers descomprimirla antes de su instalacin:
[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 relacin a esta memoria SD, sera 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 autenticacin o servidor de control domtico
posiblemente con una memoria SD de clase 4 (4MB/sg de transmisin de datos) tal vez sea
suficiente, pero si queremos utilizarla como servidor de archivos, Media Center, servidor
multimedia o estacin de juegos, seguramente debera adquirirse una de clase 6 (6MB/sg) o
clase 10 (10MB/sg).
A continuacin insertaremos la memoria SD en la ranura de nuestro equipo. Para comprobar
que nuestro equipo GNU/Linux la ha detectado correctamente tan slo deberemos ejecutar el
comando df -h:
[arturo@linux]$ df -h
S.ficheros
Tamao
/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 ejecucin 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 nmero 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 particin 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
[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 nmero de particin.
Tambin puede hacerse uso de la interfaz grfica para gramar la imagen *.img en la tarjeta SD
mediante el software usb-imagewriter en Ubuntu.
Prctica n2.- 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. Despus, le
conectaremos los cables de red (o interfaz wireless) y vdeo, los dispositivos
USB (ratn y teclado). Por ltimo lo alimentaremos mediante el alimentador a
la red elctrica o desde un puerto USB libre de nuestro equipo. En breve
deberamos observar en la pantalla como arranca el sistema Raspbian.
Al tratarse de la primera vez que la Raspberry arranca nos mostrar una
ventana de configuracin (Raspi-config), desde la cual podremos configurar aspectos bsicos para
trabajar con nuestra Raspberry (indicar que esta aplicacin de configuracin puede ejecutarse en
cualquier momento ejecutando la aplicacin Raspi-config):
En concreto, cabra destacar que podemos configurar los siguientes aspectos:

1) change_locale y change_timezone, nos permitir indicar la configuracin 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 tambin 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 aplicacin dpkg-reconfigure keyboard-configuration.
Una forma muy cmoda de configurar el teclado es modificar directamente el archivo
/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 automticamente en los siguientes arranques. La activacin SSH es fundamental para
acceder y gestionar remotamente la Raspberry, y poder configurar unidades en red va SSHFS.
Ahora tan slo necesitaremos conocer la direccin IP que tiene asignada la Raspberry: ssh
pi@dirIP_Raspberry_Pi.
4) boot_behaviour, nos permite seleccionar la opcin de arrancar en modo consola o en modo
grfico. Dependiendo de la finalidad para la que la se use la Raspberry convendr ms elegir una
opcin u otra. Por ejemplo, si queremos utilizar la Raspberry como media center, la opcin
idnea es indicar que se desea iniciar en modo grfico (acceso al escritorio o Desktop de
Raspbian). En cambio si vamos a utilizar la Raspberry como servidor, por ejemplo, como almacn
de copias de seguridad, unidad de red NAS o control domtico, no tiene sentido el modo grfico
debido a los recursos que estara consumiendo intilmente; 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 grfico (GUI, Interfaz de Usuario Grfica) ejecutando el comando startx
(por ejemplo, para realizar posteriores configuraciones de la Raspberry puede resultar ms
cmodo acceder a su entorno grfico).
5) expand_rootfs, nos permite agrandar la particin raz del sistema con la finalidad de
aprovechar al mximo la capacidad de la tarjeta SD. Esto es necesario ya que el archivo *.img de
la distribucin 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
grfica como gparted, una vez ejecutado el comando dd, disponible en cualquier distribucin
GNU/Linux. En el caso de que el software gparted nos informe sobre algn tipo de problema al
redimensionar y gestionar las particiones de la memoria SD, sera conveniente ejecutar previamente
los siguientes comandos:
[root@linux]# e2fsck -f /dev/sdc2 #Debe corresponderse con tu particin raiz Raspbian
[root@linux]# e2fsck /dev/sdc2
[root@linux]# gparted
6) change_pass, cambiar la contrasea raspberry que viene por defecto para el usuario pi.
Para ejecutar comandos de administracin habr que precederlos del comando sudo, o
suplantar al usuario administrador ejecutando sudo su. Tambin es conveniente asignar una
password al usuario administrador root por si ocurriera algn desastre con nuestra cuenta habitual
de usuario. Para ello:
[pi@raspberry]# sudo su
[root@raspberry]# passwd root
Prctica n3.- Conexin 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 opcin es la recomendada. A la hora de
elegir entre los diferentes USB wireless que existen en el mercado podra usarse por ejemplo la
TP-LINK 150Mbps Wireless N Nano USB (chipset wn725n) por coste y fiabilidad. Adems
esta interfaz wireless es detectada por el sistema Raspbian sin la necesidad de la instalacin de
ningn tipo de driver.
Para comprobar la correcta deteccin de la interfaz inalmbrica por el sistema Raspbian,
podemos ejecutar el comando iwconfig. Este nos debera mostrar por pantalla una mnima
informacin en relacin 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 documentacin:
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 ms
habitual son de zydas y ralink. En estos casos se puede instalar los drivers mediante la
instalacin de los siguientes paquetes:
1) Si se trata de un chipset Zydas deberas instalar:
[root@raspberry]$ apt-get install zd1211-firmware
2) Si se trata de un chipset Ralink deberas instalar:
[root@raspberry]$ apt-get install firmware-ralink
3.1.- Configuracin de la Interfaz Inalmbrica de manera grfica (GUI)

Tras reconocer nuestro sistema a nuestra interfaz inalmbrica, necesitaremos configurarla.
Para ello, y por facilidad, haremos uso de la Interfaz Grfica (GUI, Interfaz de Usuario Grfica).
Para ello, conectaremos nuestra Raspberry a un monitor, preferiblemente mediante un cable HDMI
por su mayor resolucin, y ejecutaremos el comando startx. Tras iniciarse la sesin grfica,
configuraremos la interfaz mediante las herramientas disponibles como wpa_gui.
3.2.- Configuracin de la Interfaz Inalmbrica desde la terminal (CLUI)

Tras reconocer nuestro sistema la interfaz inalmbrica, podemos configurarla sin necesidad
de iniciar una sesin grfica desde la propia Interfaz de Usuario de Lnea de Comandos (CLUI) o
terminal. Para ello, si suponemos que la red inalmbrica a la que deseamos conectarnos requiere de
una autenticacin WPA2-PSK de clave compartida seguiremos los siguientes pasos:
a) Obtendremos una codificacin en formato hexadecimal de la clave compartida WPA2-PSK que
se requiere para conectarnos a la red inalmbrica mediante el comando wpa_passphrase. Esta
clave codificada se utilizar a posteriori en el archivo de configuracin /etc/network/interfaces,
evitando de esta forma que la clave original pueda ser legible:
Sintaxis de wpa_passphrase: wpa_passphrase ESSID PASSPHRASE/PASSWORD
[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
configuracin que deseamos para nuestra interfaz inalmbrica. En la directiva de configuracin
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 slo 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.- Actualizacin de los Repositorios y del Software del Sistema

Una vez que ya tengamos conexin 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
Aclaracin!! Para saber ms sobre la herramienta de gestin de software apt-get puede
ejecutarse el comando apt-get -h, el cual nos proporciona un buen resumen de sus posibilidades,
o si queremos informacin ms detallada, podemos consultar el manual en lnea man apt-get.
Prctica n4.- Configuracin de la Raspberry como servidor DHCP.

En la presente prctica se mostrar como configurar una Raspberry como servidor DHCP
mediante la instalacin de dhcp3-server, y su posterior configuracin. El cliente tan slo tendr
que solicitar una renovacin de direccin 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 mquinas (servidores,
equipos NAS, impresoras, etc.) reciban del servidor DHCP siempre la misma direccin IP para dar
un correcto servicio en la red. Dicha asignacin deberemos reflejar igualmente en la configuracin
del servicio. Segn esto, en la configuracin del servicio distinguiremos dos partes:
1) Configuraremos el servidor DHCP para asignar dinmicamente direcciones IP a los clientes que
lo soliciten de manera indiferente a quien haga la solicitud. Segn esto el servidor asignar al
equipo cliente en cuestin la primera direccin IP que tenga libre dentro del rango de asignacin.
2) Configuraremos el servidor DHCP para asignar determinadas direcciones IP a determinadas
mquinas en la red. Para ello necesitaremos conocer las direcciones hardware o direccin 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 slo tendremos que ejecutar el comando ifconfig.
[root@servidordhcp]# ifconfig eth0
eth0 Link encap:Ethernet direccinHW e8:03:9a:ba:e9:3c
Direc. inet:192.168.1.1 Difus.:192.168.1.255 Msc:255.255.255.0
Direccin inet6: fe80::c685:8ff:fe1d:d61b/64 Alcance:Enlace
ACTIVO DIFUSIN MULTICAST MTU:1500 Mtrica: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)
4.1.- Instalacin del software servidor DHCP.

Aunque existen otras alternativas de software para convertir a nuestra Raspberry en un
servidor DHCP, para este caso prctico haremos uso del software ms afamado en este rea, el
dhcp3-server:
[root@servidordhcp]# apt-get install dhcp3-server
4.2.- Configuracin del servicio DHCP.

En primer lugar indicaremos a nuestra raspberry a travs de que interfaces de red
escucharemos solicitudes de renovacin de direccin IP, y por tanto, a travs 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 configuracin INTERFACES la lista de
las tarjetas de red que deseemos. Si por ejemplo, nuestra raspberry tiene una interfaz ethernet (eth0)
y una inalmbrica (wlan0), y quisiramos 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 continuacin editaremos el archivo principal de configuracin del servicio ubicado en
/etc/dhcp3/dhcpd.conf, introduciendo algo similar a lo siguiente:
## PARTE N1 Asignacin dinmica de direcciones IP independiente del solicitante
## Indicamos la direccin de la red o subred con su correspondiente mscara 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 dinmicamente el servidor
range 192.168.1.101 192.168.1.240;
## Indicamos la direccin IP de la puerta de enlace o gateway, y de los servidores DNS que
deber quedar configurada en los clientes, la mscara de red o subred, y la correspondiente
direccin de broadcast (la direccin IP ms 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 mximo) tras los cuales el cliente tendr que
hacer una renovacin de direccin IP. Si transcurrido ese tiempo, el cliente no solicita
renovacin, 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";
}
## PARTE N2 Asignacin dinmica 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 slo tendremos que reiniciar el servicio
para que surtan efecto los cambios introducidos en la configuracin:
[root@servidordhcp]# /etc/init.d/dhcp3-server restart
4.3.- Configuracin de los clientes DHCP.

Para comprobar el correcto funcionamiento del servicio DHCP anterior, tan slo tendremos
que solicitar la renovacin de la direccin IP desde un equipo cliente mediante dhclient seguido
de la tarjeta de red que queremos que reciba la configuracin dinmica, por ejemplo, eth0:
direccin IP, direccin 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 asignacin sea efectiva:
1) Al ejecutar un comando ifconfig eth0 deber mostrarse la direccin IP asignada por el servidor.
[root@clientedhcp]# ifconfig eth0
eth0 Link encap:Ethernet direccinHW 08:00:27:ea:69:f0
Direc. inet:192.168.1.250 Difus.:192.168.1.255 Msc:255.255.255.0
Direccin inet6: fe80::c685:8ff:fe1d:d61b/64 Alcance:Enlace
ACTIVO DIFUSIN MULTICAST MTU:1500 Mtrica: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 configuracin 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 Mtric
UG 0
U
1
Interfaz
eth0
eth0
3) Si ejecutamos un more /etc/resolv.conf en el cliente deberan mostrarse los servidores DNS

indicados en la configuracin 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
Prctica n5.- Configuracin de la Raspberry como servidor DNS.

Otra opcin interesante es configurar a la Raspberry como servidor DNS cach (en el
caso de querer configurar a la Raspberry como servidor DNS maestro, convendra repasar el
captulo asociado a la implementacin de este servicio). Esto nos permitira 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 ahorrara el ancho de banda consumido por los equipos de la Intranet a lo hora
de solicitar la resolucin 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 resolucin 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
raz (TNS, Top Name Servers). Una vez cacheada, mantendr dicha informacin 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.- Instalacin y Configuracin del servicio DNS.

Para convertir nuestra Raspberry en un servidor DNS cache tan slo ser necesario instalar
el software bind9. Adems no habr que realizar ninguna post-configuracin del servicio tras su
instalacin 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
situacin real muy tpica donde se requiere de este servicio es en la implementacin 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
continuacin se recordar como configurar un dominio llamado aulainformatica.es:
1) Editamos el fichero principal de configuracin del servicio Bind9, named.conf, e incluimos el
archivo de configuracin 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";
};
3) Editamos el archivo asociado a la zona aulainformatica.es indicado en la configuracin 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 ;Indicaramos la direccin IP de la Raspberry
servidorweb
IN
A
192.168.1.254 ;IP del servidor Web del dominio
www
IN
CNAME
servidorweb ;Definicin 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.- Comprobacin del servicio DNS.

Para comprobar el correcto funcionamiento del servicio anterior, tan slo habr que decirle a
los equipos cliente que su servidor DNS es la direccin IP de la Raspberry. Para hacer una
comprobacin temporal (ya que al reiniciar la mquina o el servicio de red esta configuracin se
pierde) puede modificarse el fichero /etc/resolv.conf:
[root@clientedns]# echo nameserver direccin-IP-Raspberry > /etc/resolv.conf
A continuacin, desde el cliente comprobaremos la correcta resolucin 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 //Informacin detallada del nombre de dominio
[root@clientedns]# dig -t MX gmail.com //Nos permite saber su Mail eXchange
[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
Prctica n6.- Configuracin de la Raspberry como Puerta de Enlace

Una vez que nuestra Raspberry dispone de conexin 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 travs 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 prctica nos basaremos en el esquema que se muestra a continuacin. Tal
como se puede observar en el esquema anterior, la Raspberry dispone de dos interfaces de red, una
inalmbrica, 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 inalmbricos poder comunicarse con la Raspberry, de tal forma que
esta se encargar de asignarles un configuracin IP a travs del servicio DHCP, de resolverles
nombres de dominio a travs del servicio DNS y garantizarles una conexin 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 slo sern necesarias dos cosas:
Activar el reenvo de paquetes TCP/IP entre las diferentes interfaces de red de la

Raspberry. A esto se le suele llamar ms comnmente activar el ip_forward. Para ello
tenemos dos opciones:
1 Opcin: 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 configuracin
se haga automticamente al arrancar la Raspberry:
[root@gw]# echo 1 > /proc/sys/net/ipv4/ip_forward
[root@gw]# nano /etc/rc.local

# Contenido del rc.local. Aadimos la siguiente lnea:
echo 1 > /proc/sys/net/ipv4/ip_forward
exit 0
2 Opcin: Editar el archivo /etc/sysctl.conf y descomentar la lnea 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 conexin 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 haca 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 direccin IP
de origen, aparezca la direccin IP de la Raspberry de la interfaz wlan0 y no la direccin IP
privada de la Intranet. A este proceso se le denomina enmascaramiento (MASQUERADE).
El no hacerlo, provocara 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 pblica) este observando su tabla de enrutamiento no sabra como
devolverlo al equipo cliente originario. Para su habilitacin, tan slo es necesario ejecutar el
siguiente comando iptables (lo incluiramos en el script rc.local para que se habilite la
NAT nada ms que arranque la Raspberry):
[root@gw]# iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

# Contenido del rc.local. Aadimos las siguientes lneas:

iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE
exit 0
6.1.- Configuracin bsica de la Raspberry como Firewall

Siguiendo con la configuracin como gateway de la Raspberry, sera 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 diseo (para saber ms
ver el apndice de iptables, recopilado del libro de la Editorial Mira de los autores Arturo Martn
Romero y Juanjo Martn Romero):
Disear un firewall para que los equipos clientes de la Intranet puedan conectarse
nicamente a servicios HTTP, HTTPS y FTP ofrecidos en internet, exceptuando las pginas
de www.youtube.com y www.facebook.com. Adems al equipo de la Intranet con
direccin IP 192.168.2.43 nicamente debemos permitirle el acceso a servicio HTTP, pero
no HTTPS ni FTP:
# Contenido del rc.local. Aadimos las siguientes lneas:

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 deberamos 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.- Configuracin 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 evitara tener que disponer de un punto de acceso dedicado para el esquema
prctico anterior. En concreto, tal como se muestra en la siguiente figura, haramos uso de dos
interfaces inalmbricas wlan0 y wlan1.
Importante!! Para poder implementar esta configuracin la interfaz USB wireless que utilicis
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 prctica N3, el nico modo soportado
es el ad-hoc.
Para probar su comportamiento como punto de acceso, a continuacin se muestran los
comandos que la configuraran para dar servicio wireless en un red inalmbrica 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 configuracin anterior, el cliente de la Intranet recibir la configuracin IP
suministrada por el servicio DHCP ofrecido por la Raspberry tras conectarse a la red inalmbrica
red2. El rango de direcciones IP asignadas va DHCP deber ser del mismo rango que la que
tiene la propia Raspberry en su interfaz inalmbrica wlan1 (en el ejemplo, 192.168.2.0/24).
Una vez comprobado su correcto funcionamiento, deberamos crear un script que contenga
los comandos de configuracin anteriores y asegurarnos que se ejecuta al iniciarse la Raspberry.
Una posibilidad sera incluir los comandos de configuracin en el script de arranque /etc/rc.local
tal como hemos hecho con la configuracin 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
opcin sera editar el archivo de configuracin /etc/network/interfaces e incluir hay la
configuracin deseada (mirar la prctica N3 para ms informacin relativa a la configuracin de
las interfaces de red).
[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
Prctica n7.- Configuracin de la Raspberry como servidor RADIUS.

Siguiendo con redes inalambricas, en su implementacin nos puede interesar disponer de un
servdior de autenticacin que controle el acceso de los equipos clientes a la red Wireless, pero no de
la manera clsica, sino mediante el uso de un login y una password. Es decir, en la mayora 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 contrasea (WEP/WPA/WPA2), pero puede interesarnos
que el acceso sea ms personalizado: controlar quien accede mediante un login/password por
usuario (no por mquina), a que servicios se le da acceso una vez autentificado, ms una auditora
de todo ello.
Una herramienta software que nos va a permitir, entre otras muchas opciones, gestionar la
autenticacin en una red inalmbrica 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.- Introduccin 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 cdigo abierto llamado FreeRADIUS, y lo configuraremos para un uso concreto: controlar el
acceso a una red inalmbrica.
Dentro de esta parte prctica, lo primero que vamos a estudiar es la teora asociada a este
protocolo, viendo tambin conceptos relacionados con el mismo, como AAA, NAS, y mecanismos
de proteccin de redes inalmbricas (como WEP y WPA).
Despus 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 tambin 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 direccin 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 autenticacin
procedente de un punto de acceso. Por ltimo, probaremos nuestra nueva configuracin de la red
inalmbrica conectando a dicha red una mquina 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 comprobacin de
autenticacin en relacin 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 prctica.
7.2.1) Definicin de RADIUS .
RADIUS (Remote Authentication Dial-In User Server) es un protocolo que nos permite
gestionar la autenticacin, autorizacin y registro de usuarios remotos sobre un determinado
recurso. La tupla autenticacin, autorizacin y registro es ms conocida como AAA, al ser ste su
acrnimo de su denominacin original inglesa Authentication, Authorization, and Accounting.
Veamos a continuacin a qu se refiere cada uno de estos trminos:
Autenticacin (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 autenticacin se realiza mediante la presentacin de una identidad y unos
credenciales por parte del usuario que demanda acceso.
Un tipo habitual de credencial es el uso de una contrasea (o password) que junto al nombre
de usuario nos permite acceder a determinados recursos. El nombre de usuario es nuestra identidad,
que puede ser pblicamente conocida, mientras que la contrasea se mantiene en secreto, y sirve
para que nadie suplante nuestra identidad. Otros tipos ms avanzados de credenciales son los
certificados digitales tal como se ha visto en el servicio SSH, para crear usuarios de confianza.
Existen muchos mtodos concretos que implementan el proceso de la autenticacin. Algunos
de ellos, soportados por RADIUS, son:
- Autenticacin de sistema (system authentication), tpica en un sistema Unix, normalmente
realizada mediante el uso del fichero /etc/passwd.
- Los protocolos PAP (Password Authentication Protocol), y su versin segura CHAP (Challenge
Handshake Authentication Protocol), que son mtodos de autenticacin usados por proveedores de
servicios de Internet (ISPs) accesibles va PPP.
- LDAP (Lightweight Directory Access Protocol), un protocolo a nivel de aplicacin (sobre TCP/IP)
que implementa un servicio de directorio ordenado, y muy empleado como base de datos para
contener nombres de usuarios y sus contraseas.

- Kerberos, el famoso mtodo de autenticacin diseado por el MIT.
- EAP (Extensible Authentication Protocol), que no es un mtodo concreto sino un entorno
universal de autenticacin empleado frecuentemente en redes inalmbricas y conexiones punto a
punto.
- Freeradius tambin se permite la autenticacin basada en ficheros locales de configuracin del
propio servidor RADIUS /etc/freeradius/users.
Autorizacin (authorization) se refiere a conceder servicios especficos (entre los que se

incluye la negacin de servicio) a un determinado usuario, basndose para ellos en su
propia autenticacin, los servicios que est solicitando, y el estado actual del sistema. Es
posible configurar restricciones a la autorizacin de determinados servicios en funcin de
aspectos como, por ejemplo, la hora del da, la localizacin del usuario, o incluso la
posibilidad o imposibilidad de realizar mltiples logins de un mismo usuario.
El proceso de autorizacin determina la naturaleza del servicio que se concede al usuario,

como son: la direccin IP que se le asigna, el tipo de calidad de servicio (QoS) que va a recibir, el
uso de encriptacin, o la utilizacin obligatoria de tneles para determinadas conexiones.
Los mtodos de autorizacin 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 configuracin locales al servidor.
No se debe confundir los trminos autenticacin con autorizacin. Mientras que la
autenticacin es el proceso de verificar un derecho reclamado por un individuo (persona o incluso
ordenador), la autorizacin es el proceso de verificar que una persona ya autenticada tiene la
autoridad para efectuar una determinada operacin.
Registro (accounting, a menudo traducido tambin 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 cundo 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 tecnologas de red (incluyendo mdems,
xDSL, VPNs y redes inalmbricas) no slo para gestionar el acceso a la propia red, sino tambin
para servicios propios de Internet (como e-mail, Web o incluso dentro del proceso de sealizacin
SIP en VoIP).
Un uso de RADIUS que queremos enfatizar mediante esta prctica con Raspberry, es la
autenticacin en redes inalmbricas (Wi-Fi), sustituyendo mtodos ms simples de clave
compartida (pre-shared key, PSK), que son bastante limitados al gestionar una red cuando sta
alcanza un determinado tamao.
Aunque RADIUS es el protocolo para AAA ms extendido en la actualidad, ya existe un
nuevo protocolo que est llamado a sustituir a RADIUS. Su nombre es DIAMETER, y tambin
proporciona manejo de errores y comunicacin entre dominios.
7.2.2) Definicin de NAS .

Aclaracin!! No confundir con la definicin de NAS vista en otras prcticas que se harn con la
Raspberry como NAS, Network-Attached Storage, que comnmente 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 tambin 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 telfono para VoIP o una impresora, hasta el acceso a una red inalmbrica 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 (tpicamente RADIUS) preguntando si las credenciales
proporcionadas por el cliente son vlidas. Basndose en su respuesta, NAS le permitir acceder o no
a este recurso protegido. El sistema NAS no contiene ninguna informacin sobre los usuarios que se
pueden conectar ni sus credenciales, sino que utiliza esta informacin 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 ms global, tenemos la tpica 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 sera 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 prctica 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 conexin inalmbrica). 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 inalmbrica
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 slo tienen que implementar el
protocolo de comunicacin con RADIUS, y no todas las posibilidades de AAA existentes (PAP,
CHAP, LDAP, kerberos, mySQL, etc.). En el ejemplo del punto de acceso, tan slo necesitamos
implementar una solucin NAS que realice las consultas a RADIUS.
Otra ventaja del protocolo RADIUS es que, en su comunicacin con NAS, nunca transmite las
contraseas directamente por la red, lo que se conoce como en Cleartext, ni siquiera al usar PAP,
sino que usa algoritmos para ocultar las contraseas como MD5. Sin embargo, al no ser considerado
MD5 un sistema de proteccin de credenciales demasiado seguro, es aconsejable utilizar sistemas
adicionales de proteccin para cifrar el trfico de RADIUS, como puede ser tneles de IPsec.
7.2.3) Definicin de seguridad en tecnologas de red inalmbrica .
En redes inalmbricas se utiliza un punto de acceso (wireless access point, WAP o
simplemente AP) para interconectar todos los dispositivos inalmbricos de la red. Usualmente un AP
se conecta tambin a una red cableada, transmitiendo datos entre los dispositivos conectados a la
red cable y los dispositivos inalmbricos.
La seguridad es un tema importante en las redes inalmbricas porque, al contrario que en
una red cableada a la que slo tienen acceso las personas que fsicamente pueden conectarse,
cualquier persona de la calle o pisos o edificios vecinos pueden conectarse a una red inalmbrica o
ver el contenido de los paquetes que circulan por ella si sta no est convenientemente protegida.
Algunos de los principales protocolos estndar para proporcionar seguridad en redes inalmbricas
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 esttica de 64
128 bits con el algoritmo RC4. Su uso se desaconseja completamente, ya que aunque es muy
fcil 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 mltiples fallos detectados en el
protocolo WEP. WPA fue diseado por el consorcio Wi-Fi Alliance basndose en un
borrador del estndar 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 (podra funcionar actualizando el firmware). En concreto,
WPA sigue usando RC4 como algoritmo de cifrado con claves de 128 bits, pero usa TKIP
para cambiar dinmicamente estas claves. WPA fue diseado 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 domsticos o pequeas oficinas
tambin 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 estndar 802.11i, y el cambio ms 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 ms nuevo. Sin
embargo, se sabe que WAP tambin terminar siendo comprometido a medio plazo y por
tanto slo se recomienda como transicin a WAP2.
Otro concepto relacionado con la seguridad en redes inalmbricas que merece la pena
destacar es EAP (Extensible Authentication Protocol). EAP es un marco general de autenticacin, y
no un mecanismo de autenticacin concreto. EAP proporciona algunas funciones comunes y un
mtodo para negociar el mecanismo de autenticacin a usar. Actualmente hay ms de 40 mtodos
distintos. En esta prctica haremos uso del denominado EAP protegido (PEAP) para la
autenticacin de nuestro usuario en la red inalmbrica, ya que los suplicantes, equipos bajo
GNU/Linux o Windows, o un mvil bajo sistema Android soportan PEAP con MSCHAPv2.
7.3.- Instalacin y Configuracin de FreeRADIUS.
En primer lugar instalaremos el software que convertir nuestra Raspberry en un servidor
RADIUS:
[root@raspberry]# apt-get install freeradius
Despus lo configuraremos en tres pasos: A) configuracin de equipos clientes, B) creacin
de cuentas de usuario (login/password) vlidas en la autenticacin, y C) protocolos a usar en el
proceso de autenticacin. Todos los archivos de configuracin necesarios los encontraremos en
/etc/freeradius. En concreto, el archivo principal de configuracin es radiusd.conf, y en este se
encuentran incluidos el resto mediante directivas $INCLUDE, lo que facilita su gestin y
configuracin:
[root@raspberry]# more radiusd.conf | grep '$INCLUDE'
# $INCLUDE line.
$INCLUDE proxy.conf
$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 comprobacin de la autenticacin del usuario.
Para ello editaremos en primer lugar el archivo /etc/freeradius/clients.conf y aadiremos lo
siguiente:
[root@raspberry]# nano /etc/freeradius/clients.conf
#client direccin_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 permitira 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
inalmbrica y as poder acceder al servicio. Aunque existen otro tipo de gestin de cuentas ms
eficiente (p.e. Mediante una BD MySQL), aqu usaremos la ms simple: editar el fichero users.
[root@raspberry]# nano /etc/freeradius/users
# <nombre_cuenta_usuario>
Cleartext-Password := <password_usuario>
#
Reply-Message = "<mensaje personalizado>"
arturo
Cleartext-Password := "1234"
Reply-Message = "Hola, %{User-Name}, Bienvenido!!"
usuw1
Cleartext-Password := "usuwireless1"
Reply-Message = "Hola, %{User-Name}, Bienvenido!!"
C) Indicaremos el protocolo de autenticacin. Como ya se ha dicho previamente tanto los equipos

como dispositivos mviles que funcionan bajo Windows como GNU/Linux (Ubuntu, Debian,
Android, etc.) soportan PEAP con MSCHAPv2. Para ello comprobaremos la configuracin 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
configuracin. Tambin tenemos la opcin 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
configuracin clients.conf (la direccin IP del cliente debe figurar en clients.conf):
[root@raspberry]# freeradius -X
[root@cliente]# radtest <nombre-usuario> <password> <IP_Raspberry> <port> <secret>
[root@cliente]# radtest arturo 1234 dir_IP_Raspberry 1812 pass_secret
[root@raspberry]# /etc/init.d/freeradius restart
7.3.- Configuracin del punto de Acceso.
En la configuracin del punto de acceso deberemos indicarle los parmetros de
configuracin del servicio RADIUS que se soliciten: direccin 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 cuestin.
Ahora ya deberamos poder acceder a la red inalmbrica mediante una autenticacin previa.
Prctica n8.- Configuracin de la Raspberry como unidad de red

Network-Attached Storage (NAS).
A continuacin 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 configuracin de cuotas.
No obstante, se muestra a continuacin como se implementaran 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 continuacin se muestran algunos ejemplos (repasar el captulo 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 podramos 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 podran proponer infinidad de ellos), para comprender la
importancia de disponer de una unidad de almacenamiento NAS, nos pondremos en un hipottico
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,
tendramos dos posibles opciones para llevar dicha labor a cabo:
1) Ir con un montn de CDs de instalacin 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 instalacin anterior, y en caso
de requerirlo, conectarnos a este desde cualquier equipo de la red, descargarlo y llevar a cabo la
instalacin. En este caso, la mquina 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 importacin y que se beneficia de la
informacin proporcionada por el servidor, se denomina cliente.
En definitiva, el uso de nuestra Raspberry como una unidad de red nos garantizara entre
otros beneficios:
1) Evitar redundancia de informacin 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: realizacin de informes, noticias actualizadas, disponibilidad de audio y
vdeo, etc. Una solucin sera realizar tantas copias de la informacin como usuarios
(equipos) la requieran, con los innumerables inconvenientes que ello supone: desperdicio de
espacio al redundar la informacin, adems de poder encontrar posibles problemas de
inconsistencia. Otra solucin sera ubicar toda esa informacin 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 gestin 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 informacin disponible. Esto puede llevarse al extremo, configurando los equipos
de tal forma que el HOME (/home/<usuario>) 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 mltiples equipos con una
configuracin muy similar, puedan compartir los ficheros de configuracin, ubicndolos en
un nico nodo de la red, lo que favorecera el posterior mantenimiento.
4) Y todo ello nos lo permitira nuestra Raspberry con una consumo de energa elctrica muy
reducido.
8.1.- Configuracin de la Raspberry como servidor FTP.

Para convertir nuestra Raspberry como servidor FTP tan slo tendremos que instalar el
software proftpd:
[pi@raspberry]$ sudo su
[root@raspberry]$ apt-get install proftpd
A modo de ejemplo, a continuacin 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 annimo, y
otro hbrido (acceso annimo y no annimo). El primero se ofrecer por el puerto por
defecto, 21, y el segundo por el puerto 21000.
Suponemos que la Raspberry tiene la direccin IP 192.168.1.1.
Las cuentas de usuario FTP no tendrn una shell vlida para evitar accesos indeseados por
otras vas que no sea FTP. Por ello al crear los usuarios se les asignar una shell falsa
/bin/false. Estas cuentas de usuario se agruparn 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 navegacin 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 configuracin 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 / Auditora
dir_IP_Raspberry
Puerto 21
serftp1.raspFTP.es
Auditora: /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

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
Annimo (suplantar a un usuario llamado

anonimo)
/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
Auditora: /var/ftp/serftp2
En cuanto a la configuracin 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
# 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
<VirtualHost dir_IP_Raspberry>
Port 21
Requirevalidshell off
DefaultRoot ~
<Limit LOGIN>
AllowUser profesor
AllowGroup ftpg1
AllowGroup ftpg2
DenyAll
</Limit>
<Limit WRITE>
DenyAll
</Limit>
<Directory /mnt/disco2/ftp1/publico>
<Limit STOR>
AllowUser profesor
AllowGroup ftpg1
DenyAll
</Limit>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
<Directory /mnt/disco2/ftp1/privado>
<Limit WRITE>
AllowGroup ftpg2
DenyAll
</Limit>
</Directory>
<Directory /mnt/disco2/ftp1/subidas>
<Limit STOR>
AllowGroup ftpg2
</Limit>
<Limit WRITE>
AllowGroup ftpg1
AllowUser profesor
DenyAll
</Limit>
</Directory>
</VirtualHost>
<VirtualHost dir_IP_Raspberry>
Port 21000
DefaultRoot ~
<Limit LOGIN>
AllowUser profesor
AllowGroup ftpg3
DenyAll
</Limit>
<Directory /mnt/disco2/anonimo/privado>
<Limit WRITE>
AllowAll
</Limit>
</Directory>
<Directory /mnt/disco2/anonimo/publico>
<Limit WRITE>
AllowAll
</Limit>
</Directory>
<Directory /mnt/disco2/anonimo/subidas>
<Limit WRITE>
AllowAll
</Limit>
</Directory>
<Directory /mnt/disco2/anonimo>
<Limit STOR>
AllowAll
</Limit>
<Limit WRITE>
Denyall
</Limit>
</Directory>
<Anonymous /mnt/disco2/anonimo>
User anonimo
Useralias anonymous anonimo
<Directory /mnt/disco2/anonimo/privado>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
<Directory /mnt/disco2/anonimo/publico>
<Limit WRITE>
AllowAll
</Limit>
</Directory>
<Directory /mnt/disco2/anonimo/subidas>
<Limit STOR>
AllowAll
</Limit>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
<Directory /mnt/disco2/anonimo>
<Limit WRITE>
DenyAll
</Limit>
</Directory>
</Anonymous>
</VirtualHost>
8.2.- Configuracin de la Raspberry como servidor CIFS/SMB.

CIFS/SMB es uno de los protocolos ms utilizados tanto por redes Windows como
GNU/Linux a la hora de implementar unidades en red. Por tanto, la configuracin de nuestra
Raspberry como servidor de archivos compartidos en formato CIFS/SMB garantizar que una red
hbrida compuesta por equipos con sistema operativo Windows, GNU/Linux, o dispositivos mviles
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:
[root@raspberry]# aptitude search samba # Para conocer paquetes relacionados con samba
[root@raspberry]# apt-get install samba samba-common samba-common-bin
A continuacin tan slo deberemos configurar el servicio adecuadamente. Para ello
editaremos el archivo de configuracin /etc/samba/smb.conf. Este archivo esta dividido en
secciones acotadas por un encabezamiento entre corchetes, [nombre_seccin] que la identifica.
La seccin ms importante es [global] al contener las directivas de configuracin generales.
Dicha seccin slo 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.
Aclaracin!! Para saber ms sobre la seccin [global] mirar el apndice 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 slo ser necesario crear una nueva
seccin con el nombre que le queramos dar a la unidad de red, junto a una serie de directivas de
configuracin que personalizarn los permisos en el acceso. A continuacin 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
Ejemplo de configuracin 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 slo 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 Annimo: nobody/nogroup
[recursoespecial]
path = /mnt/disco2/privado
read only = yes # Recurso de slo lectura. Slo permite escritura a write list
write list = ususamba1 ususamba2
max connections = 10
browseable = yes
guest ok = no
public = no # Permiso de acceso No Annimo. Slo accedern autenticandose valid users
valid users = @gruposamba # Usuarios con posibilidad de acceso (LOGIN)
En relacin a la configuracin de este ltimo recurso compartido por samba
recursoespecial aclarar que al tratarse de un recurso no annimo (no se permite acceso
pblico), 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 annimo por samba no se puede autentificar con el
login y password con los que inicia sesin normalmente en el sistema. Para dar de alta un
nuevo usuario Samba ejecutaremos el siguiente comando smbpasswd:
[root@raspberry]# smbpasswd -a ususamba1
La opcin -a (add) del comando smbpasswd permite aadir 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 sesin en el sistema, y as de esta forma, el usuario har
uso de una nica password para todo (cuando inicie sesin va SSH o al acceder al recurso
compartido).
Importante!! En relacin a los privilegios o permisos de lectura y escritura concedidos va
Samba, tenemos que tener clarsimo que dichos permisos deben ser congruentes con los asignados a
nivel de sistema de ficheros. Es decir, si va 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 apndice 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
Una vez configurado Samba, podemos comprobar si hemos cometido algn error sintctico
al escribir las directivas de configuracin 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 slo 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

\\direccin_IP_Raspberry\nombre_recurso, o haciendo uso del asistente grfico de
conexin con una unidad de red.
GNU/Linux: ejecutando el comando mount -t cifs.
[root@cliente]$ mount t cifs //direccin_IP_Raspberry/nombre_recurso /punto_montaje \

-o username=nombre_usuario,password=pass_usuario
8.3.- Configuracin de la Raspberry como servidor SSHFS.

Una de las opciones ms 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 podramos 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 conexin, nos pedir o no la contrasea del usuario remoto
arturo en funcin de si el usuario que trata de acceder es de confianza o no. Para que el usuario
sea un usuario de confianza tan slo 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 automticamente)
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.
En el caso de querer desmontar la unidad de red ejecutaremos el siguiente comando:

[usuario@cliente]$ fusermount -u ~/docs-remotos
Aclaracin!! Para saber ms sobre el servicio SSH, o querer que el montaje se realice de manera
automtica tras iniciar sesin en el equipo cliente consultar el apndice correspondiente a SSH.
8.4.- Configuracin de la Raspberry como servidor NFS.

El sistema de archivos NFS (Network File System, Sistema de Ficheros en Red) es la
solucin clsica adoptada por los sistemas operativos UNIX/GNU Linux para compartir archivos
en redes TCP/IP. Su historia se remonta a 1984, ao en que la empresa SUN Mycrosystems
implementa esta tecnologa para compartir informacin dentro de la red. Adems, gracias a que
SUN lo implemento bajo licencia gratuita para la industria, provoco que se consolidar como un
estndar 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 informacin 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 impresin 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 direccin IP, sin necesidad de autenticarse (login/password) o
de mostrar credenciales (certificado del cliente que asegure que es quien dice ser).
Para evitar confusiones, sera importante recalcar que aunque en la figura anterior de la
impresin 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
informacin.
Para convertir nuestra Raspberry en un servidor NFS deberemos instalar el software
siguiente:
[root@raspberry]# apt-get install nfs-kernel-server
Aclaracin!! 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:
[root@raspberry]# more /proc/filesystems | grep nfs

Una vez instalado, veremos que el resultado de la ejecucin 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 comparticin 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

# <ruta del acceso a compartir va NFS> <mquinas clientes>(<permisos>)
/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 configuracin 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 ejecucin del comando mount o de manera automtica 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

[root@cliente]# nano /etc/fstab

# Lnea a aadir en el fstab:
dir_IP_Raspberry:/home/arturo/datos /mnt/datos-remotos nfs auto,user,rw
Aclaracin!! Para saber ms sobre el servicio NFS mirar el apndice correspondiente.
Prctica n9.- Configuracin

HTTP/HTTPS.
de
la
Raspberry
como
servidor
A continuacin veremos como configurar nuestra Raspberry como servidor Web mediante la
ayuda del software ms 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
prcticas correspondiente al control domtico va Web.
[root@raspberry]# apt-get install apache2
Adems 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.- Creacin de la Entidad Certificadora (CA).

Para crear una CA tan slo necesitaremos crear una pareja de claves asimtricas (clave
pblica y privada), y el certificado auto firmado por la propia entidad CA con todos sus datos.
Antes deberemos instalar el software openssl:
[root@raspberry]# apt-get install openssl
Despus 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.- Creacin 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 confen en el servicio, y se atrevan a introducir datos confidenciales (login y password,
cdigos, etc.) necesitaremos crear un par de claves asimtricas, 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 ms 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
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.- Configuracin de Apache para dar un servicio HTTPS.

Aclaracin!! Para saber ms sobre el servicio Apache y su configuracin, consultar el apndice
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 prctica se
establecern el mayor nmero de especificaciones posibles: 2 virtualhost, secciones annimas y no
annimas (autenticacin bsica 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 Raz del Servicio
Pgina 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)
Annimo
ususeguro1, ususeguro2,
ususeguro3
Annimo con secciones no
annimas (un directorio y un
archivo)
ususeguro1, ususeguro2
otrospdf
/mnt/disco2/pdf
otrospdf
/mnt/disco2/pdf
otrosdoc
/mnt/disco2/doc
Con la finalidad de cumplir las especificaciones anteriores, seguiremos los siguientes pasos
para su correcta configuracin: 1) Crearemos un fichero de configuracin auxiliar en
sites-available (p.e. ejemplo1.conf), 2) habilitaremos el fichero de configuracin anterior, 3)
habilitaremos los mdulos que no estn precargados en la instalacin 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 ms de un sitio Web bajo la misma IP, 5)
crearemos la base de datos para la autenticacin bsica de usuarios Apache, 6) crearemos el fichero
de usuarios de apache para la autenticacin 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) Creacin del fichero de configuracin asociado al servicio que queremos dar:
[root@raspberry]# nano /etc/apache2/sites-available/ejemplo1.conf
# Especificacin del primer virtualhost
<VirtualHost dir_IP_Raspberry:80 dir_IP_Raspberry:443>
ServerName servicio1.miservidor.es
DocumentRoot /var/www/misite1
DirectoryIndex my-site1.html
Userdir /home/*/myweb
Userdir enabled ususeguro1 ususeguro2 ususeguro3
Userdir disabled
<Directory /home/*/myweb>
Allow from all
</Directory>
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
<Directory /var/www/misite1>
Allow from all
</Directory>
Alias /otrospdf /mnt/disco2/pdf
</VirtualHost>
# Especificacin del segundo virtualhost
<VirtualHost dir_IP_Raspberry:443>
ServerName servicio2.miservidor.es
DocumentRoot /var/www/misite2
DirectoryIndex my-site2.html
Userdir /home/*/myweb
Userdir enabled ususeguro1 ususeguro2
Userdir disabled
<Directory /home/*/myweb>
Allow from all
</Directory>
SSLEngine on
SSLCertificateFile /etc/apache2/server/servercert.pem
SSLCertificateKeyFile /etc/apache2/server/server.pem
<Directory /var/www/misite2>
Allow from all
</Directory>
Alias /otrospdf /mnt/disco2/pdf
Alias /otrosdoc /mnt/disco2/doc
<Files trabajo.html>
AuthType Basic
AuthName No Annima 1
AuthDBMType SDBM
AuthDigestProvider dbm
AuthDBMUserFile /etc/apache2/control/access.db
Require user access1 access3
</Files>
<Directory /var/www/misite2/clases>
AuthType Digest
AuthName No Annima 2
AuthDigestProvider file
AuthUserFile /etc/apache2/control/access.dat
Require valid-user
</Directory>
</VirtualHost>
2) Habilitaremos el fichero de configuracin anterior para que sea tenido en cuenta en el prximo
reinicio del servicio:
[root@raspberry]# a2ensite ejemplo1.conf
3) Habilitaremos los mdulos de Apache necesarios para poder ofrecer un servicio seguro (mdulo
ssl) y para permitir que determinados usuarios puedan publicar contenidos Web desde su HOME
(mdulo 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 direccin IP de la Raspberry y puerto (80/443) en ms 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 seccin no annima
No Annima 1. Para ello haremos uso del comando htdbm el cual nos pedir la password del
usuario que deseamos crear (la opcin -c crea la base de datos, luego hay que quitarla para
aadir 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 seccin no annima No
Annima 2 tipo digest. Para ello haremos uso del comando htdbm:
[root@raspberry]# htdigest -c /etc/apache2/control/access.dat No Annima 2 access4
[root@raspberry]# htdigest /etc/apache2/control/access.dat No Annima 2 access5
[root@raspberry]# htdigest /etc/apache2/control/access.dat No Annima 2 access6
7) Por ltimo reiniciaremos el servicio:
[root@raspberry]# /etc/init.d/apache2 restart
Prctica n10.- Configuracin de la Raspberry como Proxy HTTP.

En esta prctica 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 direccin IP)
durante el Time To Live (TTL) indicado en la definicin de la correspondiente zona maestra del
dominio solicitado, evitando de esta forma tener que salir a Internet a buscar la correspondiente
resolucin 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 pginas 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.
Adems 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 conexin, 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 autenticacin previa.
4. Filtrar URLs y contenidos evitando que los usuarios puedan conectarse a determinados
sitios Web.
1.
5.
Informar mediante ficheros de auditora 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 decisin de permitir o denegar mediante la directiva
http_access. De manera resumida, destacaramos los siguientes tipos de ACL:
Sintaxis directiva acl: acl nombre-acl tipo-acl descripcin|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 alusin a un

equipo cliente basndonos en su nombre acl eq1 srcdomain equipo1.intranet.es
srcdomain
de dominio. Para la comprobacin se http_access deny eq1
requiere resolucin inversa
dst
Destination. Hace alusin 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 [das] [h1:m1-h2-m2]
acl horario1 M T W H F 9:00-18:00
Los das se especifican con la abreviatura acl finde A S 9:00-13:00
del da en ingls: 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 alusin 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 opcin -i le
indica que no distinga entre maysculas
y minsculas
10.1.- Configuracin previa del Entorno de Red

Antes de empezar ya con la prctica, si observamos el esquema anterior, podremos advertir
que la Raspbery hace las veces de puerta de enlace o gateway de las Intranet cableada e inalmbrica
haca la Internet, hace de servidor DNS cach para los equipos de las Intranet, hace servidor DCHP
y hace de proxy HTTP. Adems, con la finalidad de hacer una divisin lgica (que no fsica) 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 direccin de red del rango 192.168.2.0/24. Para todo ello
recordamos que habr que hacer lo siguiente, a excepcin de la configuracin como proxy HTTP
que la veremos a continuacin:
a) Para que haga de gateway, activaremos el ip_forward para que puedan reenviarse paquetes
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 direccin 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
...
#Aadimos la siguientes lneas:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
exit
b) Para que haga de servidor DNS cach simplemnente haremos lo indicado en la prctica N5 del
siguiente documento, que bsicamente 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 slo tendremos que seguir las explicaciones
de la prctica N4 del presente documento. Importante advertir, que para poder asignar direcciones
IP va 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 configuracin al reiniciar el equipo, o modificar el archivo de configuracin
/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
Aclaracin!! El nombre de la interfaz virtual eth0:nombre puede ser el que uno desee.
10.2.- Instalacin del software servidor.

Para configurar nuestra Raspberry como servidor proxy HTTP instalaremos el software ms
afamado en ello, squid:
[root@raspberry]# apt-get install squid3
10.3.- Configuracin de la Raspberry como proxy no transparente.

La primera configuracin 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 travs 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 direccin 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
caractersticas:
Directorio Cach
Puertos
de Servicio
Cantidad
Memoria RAM
Autenticacin
Tamao Cach
Webs no permitidas
N Directorios y
Subdirectorios
Auditoria Cach
Tamao mximo 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 excepcin
del 192.168.2.100
access_log
/var/log/squid3/access.log
Para ello, modificaremos el archivo de configuracin 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 ms de un puerto simultnemente:
http_port 3128
http_port 8088
# Datos de la Cache:
## Ruta absoluta del directorio donde se cachearn los sitios Web visitados, su tamao 1000MB, y
el nmero 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!!!
## Mximo tamao del archivo que una vez descargado ser cacheado (p.e.): 128 MB
maximum_object_size_in_memory 128 MB
# Archivos de auditora en relacin con los accesos y contenidos visitados:
access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
# Autenticacin de usuarios:
## Mtodo de autenticacin: ncsa_auth, y archivo de usuarios y contraseas: claves.dat
auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid3/claves.dat
## Cantidad de procesos involucrados en la autenticacin
auth_param basic children 5
## Nombre realm identificativo
auth_param basic realm "Raspberry HTTP Proxy - Arturo"
## Periodo de validez de la autenticacin. Trascurrido ese tiempo se requerir de nuevo
auth_param basic credentialsttl 2 hours
# Definicin de Listas de Control de Acceso, ACLs
## Definicin de ACL para asegurar la autenticacin declarada anteriormente
acl passwd proxy_auth REQUIRED
## Definicin de ACLs para controlar el acceso a mquinas
acl todos src all
acl maquina1 src 192.168.2.100
#acl acceso src 192.168.100.0/24
## Definicin de ACLs para filtrar URLs de determinados sitios Web por nombre de dominio:
acl websnopermitidas dstdomain "/etc/squid3/websprohibidas1.dat"
## Defincin de ACLs para filtrar URLs Web segn 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 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 configuracin anterior: claves.dat,
websprohibidas1.dat y websprohibidas2.dat.
Respecto al fichero de autenticacin de usuarios claves.dat, haremos uso de la
herramienta software htpasswd, tal como utilizbamos para la autenticacin de zonas no
annimas en Apache. A modo de ejemplo, crearemos a continuacin un fichero que contendr tres
usuarios vlidos (login/password) llamado usuproxy1, usuproxy2 y usuproxy3 (la opcin
-c crea el fichero de usuarios, y por tanto, slo se incluye al crear el fichero para el primer
usuario):
[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 relacin a los ficheros donde le indicaremos las URLs no permitidas y contenidos que
sern filtrados:
[root@raspberry]# nano /etc/squid3/websprohibidas1.dat
# Para evitar visualizar videos de Youtube
www.marca.com
www.sport.es
www.as.com
Aclaracin!! Es importante resaltar que el filtrado de las Web a travs de sus URLs tambin lo
podramos 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
...
Despus de todo lo anterior tan slo nos quedar reiniciar el servicio para que surtan efecto
los cambios en la configuracin:
[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
direccin IP y puerto de escucha del proxy. Por ejemplo, en el caso de estar utilizando Mozilla
como navegador deberamos ir a Preferencias, y en Avanzado, en su pestaa Red
pulsaramos sobre el botn Configuracin , y all ya podremos indicar todo lo relativo al
proxy:
Una vez establecida la conexin podremos comprobar tanto la necesidad de autenticacin

como el filtrado de contenidos:
10.4.- Configuracin de la Raspberry como proxy transparente.

A continuacin, realizaremos una configuracin similar a la anterior, pero evitando que el
usuario tenga que configurar su cliente Web para poder navegar a travs del proxy. Es decir, desde
punto de vista del usuario final, navegar por Internet a travs del proxy le es totalmente
transparente, no debe configurar nada en el cliente. Para ello, en la configuracin del servicio lo
indicaremos explcitamente al indicar el puerto de servicio aadiendo transparent, http_port
3128 transparent, adems de tener que redirigir mediante iptables los paquetes recibidos por
los clientes que vayan destinados a la navegacin por Internet (p.e. HTTP/80), al puerto
configurado en el proxy (p.e. Proxy HTTP/3128). A modo de ejemplo, basndonos en la
configuracin anterior del proxy no transparente, en la siguiente tabla se resumen las caractersticas
del proxy a configurar:

Directorio Cach
Puertos
de Servicio
Cantidad
Memoria RAM
Autenticacin
Tamao Cach
Webs no permitidas
N Directorios y
Subdirectorios
Auditoria Cach
Tamao mximo 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 annimo)

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 explcitamente que queremos que se comporte de
manera transparente
http_port 3128 transparent
# Datos de la Cache:
## Ruta absoluta del directorio donde se cachearn los sitios Web visitados, su tamao 1000MB, y
el nmero 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!!!
## Mximo tamao del archivo que una vez descargado ser cacheado (p.e.): 128 MB
maximum_object_size_in_memory 128 MB
# Archivos de auditora en relacin con los accesos y contenidos visitados:
access_log /var/log/squid3/access.log
cache_log /var/log/squid3/cache.log
## Definicin de ACLs para controlar el acceso a mquinas
acl todos src all
#acl acceso src 192.168.100.0/24
## Definicin 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 allow todos
Por ltimo, tan slo tendremos que reiniciar el servicio proxy para que surtan efecto los
cambios anteriores realizados en la configuracin y redigirigir (NAT PREROUTING) al puerto del
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). Despus tan slo nos quedar
comprobar que desde el cliente se puede navegar sin necesidad de una configuracin 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
Prctica n11.- Configuracin 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 ubicacin remota a los diferentes equipos que forman parte de la red del trabajo.
En la presente prctica se mostrar como configurar un conexin 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
algn firewall que lo evite, y adems de una manera segura.
Antes de que existieran las VPN, la forma ms 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 travs 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 travs de un
dispositivo de interconexin (hub, switch, punto de acceso, etc.), cuando en realidad, la conexin
entre todos ellos se realiza a travs de la Internet con multitud de dispositivos de enrutamiento entre
ellos.
Para ello, el software OpenVPN que usaremos en la presente prctica 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 direccin IP dentro de la red privada reservada para ello, y permitirn que
se puedan interconectar entre s a travs de un supuesto dispositivo de interconexin virtual. En
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 slo necesitamos manejar paquetes de
nivel 2 o de capa de enlace. Segn lo anterior, si la VPN va a establecerse a travs 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 configuracin del servicio escogeremos
tap.
En concreto, para la prctica que aqu se plantea, se ha escogido la direccin de red/subred
privada 172.30.1.0/24, y dispositivos de red de tipo tun. A la hora de escoger dicha direccin
de red en la prctica, debemos tener cuidado con no entrar en conflicto con ninguna otra direccin
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 estn 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 direccin 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 asignacin pblica, con validez en
Internet). En concreto son las siguientes:
Clase y Mscara de red
Rango de direcciones de Red disponibles para asignacin 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.- Configuracin del Router ISP

Antes de empezar con la prctica 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 direccin IP pblica univoca y reconocida desde Internet. Por ello, cuando
queramos hacer una solicitud de conexin al servicio VPN, se la tendremos que hacer a l, y este
programarlo para que la redireccione (NAT Prerouting) haca el equipo servidor de la Intranet que
ofrece ese servicio. Es decir, debemos decirle al router ISP que cuando reciba una solicitud de
conexin va 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 prctica, por facilidad emularemos el
router ISP mediante una mquina virtual funcionando bajo GNU/Linux Ubuntu tal como se puede
ver en el esquema o figura del comienzo. Para que haga la funcin equivalente del router ISP
programaremos los siguientes comandos, tal como vimos en el captulo del diseo e
implementacin 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
[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 sesin, lo ms
idneo sera crear un script que se ejecute al iniciarse el equipo, o incluirlas al final del script
/etc/rc.local:
## Lneas aadidas al final de rc.local:

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.- Instalacin 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.- Instalacin de OpenSSL. Creacin de la Autoridad de Certificacin

(CA), y las Claves y Certificados del Servidor y de los Clientes.
Al igual que vimos en el captulo del servicio HTTPS (repasar lo visto en dicho captulo),
para garantizar una comunicacin 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 lneas 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 extensin 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 extensin crt, en lugar de pem
echo "Creamos las claves y certificado para el servidor"
mkdir /etc/openvpn/server
cd /etc/openvpn/server
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..."
cd /etc/openvpn/ca
openssl dhparam -check -text -5 1024 -out dh1024.pem
# Generamos los certificados para el cliente1 con extensin crt
echo "Creamos las claves y certificado para el cliente1"
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.- Configuracin del Servidor VPN

En este paso configuraremos el equipo servidor encargado de atender las solicitudes de
conexin realizas por los clientes remotos de la VPN. Para ello editaremos el archivo de
configuracin /etc/openvpn/server.conf. En concreto, estableceremos la siguiente configuracin,
congruente con el esquema de red mostrado al comienzo:
Se asignar a la VPN la direccin de subred 172.30.1.0/24. El servidor VPN se asignar a

si mismo de manera automtica la direccin IP ms 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 conexin.
Habilitaremos un dispositivo de red virtual de tipo tun (tunel), tun0, al cual
asignaremos la direccin 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 conexin 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 travs del servidor VPN haciendo
este de gateway o puerta de enlace. Segn el esquema planteado al comienzo de la prctica,
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 travs de los protocolos de la capa de transporte tcp o
udp. Para este caso prctico se ha seleccionado udp (no orientado a conexin), puede
elegirse tcp, y advertir cual podra dar un mejor servicio (depender del trfico de red, de
la cantidad de servicios que ya se estn dando en el servidor, etc.). Adems se ha respetado
el puerto por defecto del servicio 1194, aunque puede igualmente modificarse en el caso
en que queramos dar servicio a mltiples VPNs simultneamente.
A continuacin se muestra una configuracin ya probada previamente de manera exitosa en un

servidor VPN, con la explicacin de las directivas utilizadas:
# Contenido de /etc/openvpn/server.conf
## Comenzaremos indicando el puerto (por defecto, 1194), el protocolo (tcp/udp) y la topologa
port 1194
proto udp
topology subnet
## Indicamos la ubicacin de los certificados y claves creados anteriormente:
## Clave asimtrica 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 lnea:
;duplicate-cn
## Definimos las caractersticas del tunel seguro que se va a generar:
## Tipo de dispositivo que crear el tunel (tun/tap), y caractersticas de la conexin
dev tun
persist-tun
persist-key
keepalive 10 120
comp-lzo
## Especificamos el rango de direcciones que se asignarn a los equipos de la VPN
## Debe tratarse de una direccin 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 ambigedad y confusin en las tablas de enrutamiento de los clientes.
## Por ejemplo, usaremos la direccin de subred 172.30.1.0/24.
## El servidor recibir automticamente la direccin IP ms baja del rango: 172.30.1.1
server 172.30.1.0 255.255.255.0
## Para registrar la asignacin de direcciones IP realizada por el servidor:
ifconfig-pool-persist ipp.txt
## Indicamos las redes internas que sern accesibles desde el exterior a travs 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 confusin 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
## trfico hacia Internet se enva a travs del servidor VPN, descomentaremos la siguiente lnea:
;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"
## 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 nmero de conexiones:
;max-clients 100
## Para auditar el estado de la VPN, y el nivel de auditora o verbosidad:
status openvpn-status.log
log-append /var/log/openvpn.log
verb 4
Una vez creado el fichero de configuracin 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 (reenvo 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
lnea net.ipv4.ip_forward=1 en el archivo de configuracin /etc/sysctl.conf)
[root@servidorvpn]# iptables -t nat -A POSTROUTING -j MASQUERADE
Estos ltimos comandos sera conveniente aadirlos en el script /etc/rc.local para que se
ejecuten al iniciar el sistema, o crear nuestro propio script de configuracin de arranque dentro de
/etc/init.d y posteriormente crear el correspondiente enlace a dicho script desde el directorio
/etc/rcX.d en funcin del nivel de arranque de nuestro servidor, el cual se puede conocer
ejecutando runlevel (X, se corresponder con el nivel de arranque).
11.5.- Configuracin de los clientes VPN

Tras configurar el servidor, tan slo 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 N2, 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 ejecutaran 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 revs, que sea el propio servidor VPN el que tenga instalado el
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 configuracin del equipo cliente VPN
/etc/openvpn/cliente1.conf. End dicha configuracin deberemos tener en cuenta lo siguiente:
El servidor da el servicio va protocolo udp, por el puerto 1194, tal como tiene
configurado en su archivo de configuracin.
El tipo de dispositivo virtual necesario para comunicarse con el servidor ser tun, tal
como justificamos en la configuracin del servidor VPN.
La solicitud de conexin 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 direccin IP pblica que tenga asignada nuestro
router ISP (proporcionado por nuestro Proveedor de Servicios de Internet), que en el
ejemplo propuesto en este caso prctico es 192.168.123.170. Por tanto ser necesario
configurar una NAT prerouting en el router ISP para que redireccione las solicitudes de
conexin recibidas por udp/1194 haca el equipo de la Intranet que hace de servidor VPN
(en el esquema 192.168.1.X+50). Dicha configuracin se ha realizado al comienzo de la
prctica.
## Contenido del archivo de configuracin /etc/openvpn/cliente1.conf

client
dev tun
proto udp
topology subnet
persist-key
persist-tun
resolv-retry infinite
nobind
## Indicamos la direccin IP pblica del router ISP al que se har la solicitud de conexin.
## Se podra poner ms 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 travs del servidor VPN descomentaremos la siguiente lnea:
;redirect-gateway def1
## Indicamos la ubicacin 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
user nobody
group nogroup
## Indicamos que los datos de la comunicacin entre cliente y servidor VPN viajarn comprimidos
comp-lzo
## Nivel de verbosidad: cantidad y tipo de mensajes de informacin que aparecern por pantalla
verb 4
Por ltimo, haremos la solicitud de conexin mediante la ayuda del archivo de configuracin
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 travs del servidor VPN. A continuacin se muestran las tablas antes y despus de
establecer la conexin con la VPN:
[root@cliente1vpn]# route -n (antes de iniciar la conexin VPN)
Destino
Gateway
Mscara
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
Mtrica
0
0
Interfaz
eth0
eth0
[root@cliente1vpn]# route -n (despus de iniciar la conexin VPN)

Destino
Gateway
Mscara
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
Mtrica
0
0
0
0
0
Interfaz
tun0
tun0
tun0
eth0
eth0
Si habilitramos la directiva redirect-gateway def1 en los archivos de configuracin,

adems de las reglas anteriores, tambin apareceran nuevas reglas que enrutaran todo el trafico de
Internet generado por el cliente de la VPN, haca el gateway del servidor de la VPN ( puede tener
inters para control los accesos a Internet realizados por el equipo cliente):
[root@cliente1vpn]# route -n (incluyendo redirect-gateway def1)
Destino
Gateway
Mscara
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
Mtrica
0
0
0
0
1000
0
Interfaz
tun0
tun0
tun0
eth0
tun0
eth0
Prctica n12.- Raspberry como controlador de dominio primario (PDC)

En la prctica 8.2 se mostr como formar un grupo de trabajo hbrido entre equipos
GNU/Linux y Windows, con la finalidad de compartir recursos (directorios e impresoras) entre los
equipos. Este tipo de configuracin en red se denomina habitualmente red P2P (Peer To Peer),
entorno en la cual todo equipo perteneciente al grupo de trabajo hace simultneamente de cliente y
de servidor.
En cambio, en la presente prctica se mostrar como implementar una red jerrquica

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 bsicamente de las dos
siguientes caractersticas:
- Controlar la autenticacin de los usuarios en las mquinas clientes. Es decir, cuando un usuario
trate de iniciar sesin en un equipo cliente requerir introducir un login y una password, los
cuales sern validados por el PDC.
- Gestionar los perfiles de los usuarios (perfiles mviles). Es decir, una vez autentificado el usuario
e iniciada la sesin, 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 sesin, 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 cargndose el perfil con el que estuvo trabajando la ltima vez que inicio
sesin en el dominio. A esta caracterstica se le denomina perfil mvil.
Segn lo anterior, uno de los servicios ms tiles que podemos implementar con nuestra
Raspberry es el de controlador de dominio principal (PDC) supliendo de esta forma al clsico
Windows Server 2000/2003/2008 en sus funciones ms bsicas, evitando de esta forma el pago de
la correspondiente licencia, sus tediosos arranques y sus molestas actualizaciones. Con la
configuracin que se va a presentar a continuacin, los clientes del dominio, Windows o

GNU/Linux, podrn 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
resolucin de nombre a direccin 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 travs de la cual daremos de alta el
nombre do dominio deseado, tal como se mostr en la prctica 5.2.
En el ejemplo que se muestra a continuacin, y siendo congruentes con la imagen anterior,
registraremos un nuevo dominio llamado intranet.es:
[root@raspberry]# nano /etc/bind/named.conf
# Anaadimos la siguiente lnea y Bind9 incluir en su configuracin el archivo 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 configuracin 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
2013030801
; Nmero de Serie o versin de zona
604800
; Tiempo de Refresco para DNS esclavos
86400
; Tiempo de Reintento para DNS esclavos
2419200
; Tiempo de Expiracin para DNS esclavos
604800 )
; Time To Live, tiempo de vida en cach
;
@
IN
NS
ns ; Indicamos el nombre de la mquina Servidora de Nombres (NS)
ns
IN
A
192.168.1.102 ; Indicamos la direccin IP de la mquina ns.intranet.es
@
IN
A
192.168.1.102 ; Indicamos una direccin IP para el dominio intranet.es
server IN
A
192.168.1.102 ; Indicamos una direccin IP para el equipo server.intranet.es
cliente1
IN
192.168.1.105 ; Indicamos una direccin IP cliente1.intranet.es
Por ltimo chequeamos el archivo de zona y comprobamos su correcta resolucin con el

comando dig o nslookup tras reiniciar el servicio para que surtan efecto los cambios:
[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.- Instalacin 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:
[root@raspberry]# aptitude search samba # Para conocer paquetes relacionados con samba
[root@raspberry]# apt-get install samba samba-common samba-common-bin
12.3.- Configuracin de Samba como PDC

Para configurar el servidor deberemos editar el fichero de configuracin de Samba que
encontraremos en /etc/samba/smb.conf. Segn vimos en la prctica 8.2, este archivo esta
dividido en diferentes secciones encabezadas por el nombre de dicha seccin encerrada entre
corchetes. Estas secciones se suelen corresponder con los diferentes recursos que comparte la
mquina, [homes], [printers] o [clases]. Pero hay una seccin que no un recurso compartido
propiamente dicho, sino una seccin donde se localizan las directivas generales de configuracin
que configuran el servicio. Esta seccin es la primera que nos encontraremos, [global]. En
concreto, entre las muchas directivas que pueden usarse en la seccin [global], nosotros haremos
uso de las siguientes directivas de configuracin 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 mquina. 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: Descripcin 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 direccin IP.
dns proxy: Permite redireccionar la resolucin 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 autenticacin. En nuestro caso elegiremos un modo
bajo el cual cuando un usuario trata de iniciar sesin desde un equipo cliente dentro
dominio, el login y password introducidos se debern corresponder con el nombre de
usuario y contrasea 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 autenticacin 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 almacenarn 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 ubicacin. De igual forma, cuando un usuario cierra sesin, todas las
modificaciones producidas en su perfil se almacenarn 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 travs de dicha unidad los usuarios accedern, 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 sesin.
add machine script: Script de creacin de mquinas dentro del dominio.
Haciendo uso de las directivas de configuracin anteriores, la seccin [global] debera tener
al menos las siguientes directivas configuradas adecuadamente, para lo cual habr que aadir
aquellas directivas que no aparezcan, descomentar aquellas que lo estn (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 seccin [global]
Por otro, para que surta efecto todo lo anterior, habr que habilitar el los siguientes recursos
compartidos descomentando las lneas 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 seccin [homes] que ya viene preconfigurada en archivo
smb.conf:

[homes]
comment = Home Directories
browseable = no
writable = yes # read only = no
create mask = 0700
directory mask = 0700
valid users = %S
Adems habr que habilitar la seccin [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:

[netlogon]
comment = Network Logon Service
path = /home/samba/netlogon
guest ok = yes
read only = yes
share modes = no
Tras todo lo anterior, sera conveniente testear la sintaxis del fichero smb.conf mediante el
comando testparm por si hubiramos cometido algn error sintctico al hacer uso de las
directivas de configuracin, y posteriormente reiniciar el servicio:
[root@raspberry]# testparm
[root@raspberry]# /etc/init.d/samba restart
A continuacin, 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 mquina cliente que
posteriormente se agregar.
12.4.- Creacin de Cuentas de Usuario del Dominio

En primer lugar recordar, tal como se indic en la prctica 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 aplicacin 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
opcin -a (aadir usuario):
[root@raspberry]# smbpasswd -a root
Despus crearemos una cuenta de usuario que pueda utilizarse para autenticarse al iniciar
sesin 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 va 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.- Creacin de Cuentas de Mquinas Clientes del Dominio

Para dar de alta una mquina cliente que posteriormente ser agregada al dominio, haremos
uso del siguiente comando. Por ejemplo, para una mquina 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.- Configuracin del Cliente para agregarlo al Dominio

Una vez configurada la Raspberry, tan slo 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 botn derecho del ratn sobre Mi PC y editar los parmetros de la pestaa nombre de equipo.
En el caso de que el cliente sea un GNU/Linux deberemos instalar likewise.
Prctica n13.- Configuracin de la Raspberry como servidor Webmail

En la presente prctica 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 nmero de equipos posibles en la prctica,
se har uso nicamente de dos equipos para el diseo del esquema que se muestra en la siguiente
figura: puede implementarse mediante dos Raspberrys, una Raspberry y una mquina 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 prctica se correspondera con una situacin donde se veran

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, ms un ltimo equipo que se correspondera con el
servidor DNS donde estn 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 mquinas virtuales.
A continuacin se detallarn los diferentes pasos que vamos a seguir para su correcta
implementacin:
1.- Instalacin del servicio DNS y configuracin. 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.- Instalacin de los servicios de transmisin de correo SMTP y su configuracin. El protocolo
SMTP ser el utilizado en el envo/transporte de los correos desde el equipo servidor de correo
asociado a la cuenta de email del emisor hasta el buzn dentro del equipo servidor asociado a la
cuenta de usuario del receptor. Para ello, haremos uso del software postfix.
3.- Instalacin de los servicios de recepcin de correo IMAP y su configuracin. El protocolo
IMAP ser el utilizado para recoger los emails depositados en el buzn del usuario. El software
utilizado ser dovecot-imapd.
4.- Instalacin y personalizacin del sitio Web PHP SquirrelMail bajo Apache. Mediante esta
aplicacin WebMail los usuarios podrn tanto enviar, como recibir emails.
13.1.- Configuracin del servicio DNS Bind.

En este paso de la prctica, daremos por supuesto que se ha realizado exitosamente la
prctica N5 correspondiente a la configuracin del servicio DNS.
1) Editamos el fichero principal de configuracin del servicio Bind9, named.conf, e incluimos en
la configuracin del bind9 el archivo de configuracin miszonas.conf donde se definirn la zonas
o dominios utilizados en la presente prctica servidormail1.es y servidormail2.es:
[pi@servidordns]$ sudo su
[root@servidordns]# nano /etc/bind/named.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, cabra destacar al registro
MX (Mail eXchange), ya que ese el encargado de informar al que lo solicite de cual es el nombre
de la mquina 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
direccin IP de ese equipo servidor.
[root@servidordns]# mkdir /etc/bind/maestras
[root@servidordns]# nano /etc/bind/maestras/maestra.servidormail1.es
$TTL 604800
@
IN
2012100501
; Serial
604800
; Refresh
86400
; Retry
2419200
; Expire
604800 )
;
@
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
webmail
IN
192.168.1.254 ;IP del servidor webmail 2 dominio
[root@servidordns]# nano /etc/bind/maestras/maestra.servidormail2.es

$TTL 604800
@
IN
2012100501
; Serial
604800
; Refresh
86400
; Retry
2419200
; Expire
604800 )
;
@
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 configuracin de zona ms importante de todos es el MX (Mail
eXchange). Cuando una cuenta de usuario de un dominio, p.e. usu1@servidormail1.es, manda un
email a un usuario de otro dominio, p.e. usu2@servidormail2.es, dicha solicitud le llega va 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 direccin IP asociada (registro A, Address). De esta forma, el servidor de
origen ya dispone de la direccin IP 192.168.1.253 del servidor destinatario, al cual le enva el
email. Este al recibirlo lo almacenar en el buzn 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 configuracin DNS anterior, se chequearn tanto el
archivo de configuracin, 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, sera conveniente hacer solicitudes
de resolucin desde las mquinas involucradas en el esquema de red de la prctica. Para ello,
deberemos indicar en el fichero de configuracin /etc/resolv.conf de cada uno de ellos la
direccin IP del equipo servidor DNS, y a continuacin ejecutar un dig o un nslookup:
[root@servidordns]# echo nameserver 127.0.0.1 > /etc/resolv.conf #En el propio equipo

servidor DNS, con direccin 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.- Instalacin y Configuracin del servidor SMTP PostFix.

A continuacin 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 buzn (normalmente, una directorio de su HOME). Por
tanto la instalacin 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), segn el esquema indicado al principio
de esta prctica. 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 instalacin nos harn unas preguntas que pre-configurarn el servicio:
Nos preguntarn 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 pblica, 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).
Despus 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.
Tras la instalacin de postfix, pasaremos a configurarlo editando el fichero

/etc/postfix/main.cf (en ambos servidores). Entre todas las directivas de configuracin cabra
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 sern 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, situacin 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, situacin ante la cual pasar a almacenarlo en el buzn del
usuario correspondiente. En definitiva, esta directiva contiene los nombres de dominio y de
equipos, que son entendidos por el propio servidor como de gestin propia, y que por tanto,
los emails dirigidos a alguno de los nombres asociados a esta directiva, no sern 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.
Segn lo anterior, el aspecto del archivo de configuracin del postfix en su configuracin

ms bsica debera 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 bsicas 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
13.3.- Instalacin y Configuracin 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 configuracin editaremos los ficheros de configuracin de dovecot que
encontraremos
en
/etc/dovecot/
(el
archivo
principal
de
configuracin
es
/etc/dovecot/dovecot.conf, pero por cuestin de organizacin, dovecot, ha dividido su
configuracin en varios archivos que encontraremos en el subdirectorio /etc/dovecot/conf.d/. En
concreto, con la finalidad de obtener una configuracin mnima 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 guardarn 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 debern tener en su directorio HOME (~) un subdirectorio
llamado ~/mail donde se almacenarn 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 irn aadiendo 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 informarn 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 configuracin, y
descomentaremos o aadiremos la lnea 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 configuracin dovecot.conf
listen = *
...
Por ltimo, antes de reiniciar el servicio dovecot para que surtan efecto los cambios en la
configuracin, segn la configuracin 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, quisiramos crear una cuenta de correo
llamada usuario1@servidormail1.es haramos lo siguiente, dependiendo de si queremos que dicha
cuenta de usuario tenga una shell vlida para poder iniciar sesin, por ejemplo va SSH, o con una
shell falsa para evitar posibles problemas de seguridad:
[root@servidorimap]# useradd -m -d /home/usuario1 -s /bin/bash 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]# 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.- Instalacin y Configuracin del servidor HTTP WebMail: Apache y

Squirrelmail
Para terminar, instalaremos en ambos equipos servidores la aplicacin Web PHP que nos
proporcionar la interfaz Web para la gestin WebMail (envio/recepcin/gestin de emails va
Web/HTTP). Para ello, instalaremos la aplicacin squirrelmail (en caso de no tener instalado
Apache, o la librera necesaria para que interprete PHP, etc. al instalar squirrelmail tambin las
instalar todas ellas por cuestiones de dependencias de software):
[root@servidorwebmail]# apt-get install squirrelmail
A continuacin configuraremos Apache para que suministre un servicio WebMail a travs
de squirrelmail. Configurar Apache es muy sencillo, ya que tras la instalacin de
squirrelmail, se crea el directorio /etc/squirrelmail, y dentro de este, encontramos el fichero de
configuracin 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 configuracin 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 configuracin anterior. Concretamente descomentaremos las
lneas relativas al VirtualHost que aparecen, indicando la direccin IP a travs 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
<VirtualHost 192.168.1.254:80>
DocumentRoot /usr/share/squirrelmail
ServerName webmail.servidormail1.es
</VirtualHost>
...
Aclaracin!! La directiva NameVirtualHost tan slo ser necesaria si el servidor Web Apache ya
esta sirviendo otro sitio Web bajo la misma direccin 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 ms de un VirtualHost
con la misma direccin IP y el mismo puerto, debe fijarse en el ServerName de la URL solicitada
para saber que sitio Web debe servir. Esta directiva slo debe aparecer una vez por IP y puerto,
independientemente del nmero de VirtualHost habilitados en la configuracin que lo cumplan.
Por ello, al tener que definirse una sola vez, por cuestin de organizacin, sera 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 travs del puerto 443, modificaremos el VirtualHost anterior, habiendo seguido
previamente los pasos ya explicados a lo largo de la prctica N9. Segn lo visto en esa prctica, lo
primero ser crear un certificado para el nuevo servicio que vamos a ofrecer (suponemos que la
entidad certificadora ya fue creada en la prctica N9 correspondiente a HTTP/HTTPS):
Importante!! Repasar lo visto ya en la prctica N9 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
servicio Webmail, el ms 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 configuracin 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 \
[root@servidorwebmail]# nano /etc/apache2/sites-available/servicio-webmail.conf

NameVirtualHost 192.168.1.254:443 # Solo se indicar si es necesaria
<VirtualHost 192.168.1.254:443>
DocumentRoot /usr/share/squirrelmail
ServerName webmail.servidormail1.es
SSLEngine on
SSLCertificateFile /etc/apache2/webmail/webmailcert.pem
SSLCertificateKeyFile /etc/apache2/webmail/webmail.pem
<Directory /usr/share/squirrelmail>
Allow from all
</Directory>
</VirtualHost>
Aclaracin!! La directiva NameVirtualHost tan slo ser necesaria si el servidor Web Apache ya
esta sirviendo otro sitio Web bajo la misma direccin 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 ms de un
VirtualHost con la misma direccin IP y el mismo puerto, debe fijarse en el ServerName de la
URL solicitada para saber que sitio Web debe servir. Esta directiva slo debe aparecer una vez por
IP y puerto, independientemente del nmero de VirtualHost habilitados en la configuracin que lo
cumplan. Por ello, al tener que definirse una sola vez, por cuestin de organizacin, sera 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 slo nos quedar habilitar el sitio Web anterior, habilitar el mdulo ssl en el caso de querer dar
el servicio en modo seguro y reiniciar Apache para que surtan efecto los cambios en la
configuracin.
[root@servidorwebmail]# a2ensite servicio-webmail.conf
[root@servidorwebmail]# a2enmod ssl
[root@servidorwebmail]# /etc/init.d/apache2 restart
Ahora ya deberamos poder visualizar nuestro sitio web Webmail, si desde un equipo cliente
iniciamos un navegador Web, que tenga configurado como servidor DNS la direccin IP del equipo
donde se ha configurado el servicio DNS al comienzo de la prctica, 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 ingls, con el logotipo y
ttulo de squirrelmail, etc. Por tanto, el ltimo paso ser configurar el squirrelmail y de esta
forma personalizar la aplicacin. Para ello ejecutaremos el script de configuracin
/etc/squirrelmail/conf.pl, desde el cual encontraremos opciones para personalizar prcticamente
todo:
[root@servidorwebmail]# /etc/squirrelmail/conf.pl
Tal como se podr observar, con la opcin 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 continuacin se detalla alguna de las opciones ms importantes:
Opcin n1 del men principal: nos permite personalizar el nombre de la organizacin, el

logo que se mostrar en la pgina de inicio del sitio Webmail (la imagen logo deber estar
en formato png en /usr/share/squirrelmail/images), las dimensiones del logo, etc.
Opcin n2 del men principal: nos permite informar a squirrelmail sobre los servidores
SMTP y IMAP. De este submen elegiremos la opcin A para configurar las opciones del
protocolo IMAP. En concreto le informaremos de que el software que estamos utilizando
como servidor IMAP es dovecot.
Opcin n3 del men principal: nos permite personalizar los nombres que se asignarn a
los enlaces de la aplicacin Web que nos permiten ver los mensajes enviados, borradores o
enviados a la basura.
Opcin n10 del men principal: nos permite personalizar el idioma de la aplicacin
Webmail. En el caso de que queramos que el idioma sea el espaol deberemos seleccionar
el idioma es_ES, adems 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
Por ltimo, tas slo ser necesario comprobar que se pueden enviar perfectamente los
correos entre usuarios de un dominio y otro tras iniciar sesin con el nombre de usuario
correspondiente (p.e. usuario1 y su correspondiente password del sistema).
Prctica n14.- Configuracin de la Raspberry para gestin Domtica

En esta ltima parte de las prcticas planteadas para la Raspberry, se mostrar como
utilizarla para controlar cualquiera de los dispositivos elctricos que se nos ocurra. Para ello
gestionaremos el puerto de entradas/salidas de propsito 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:

Opcin N1) Controlar directamente los pines de entrada/salida del puerto GPIO mediante la ayuda
de libreras existentes en entornos de programacin en Python y Java. El problema que presenta esa
opcin es que la manipulacin directa de dichos puertos no es aconsejable por usuarios inexpertos
(electrnicamente hablando), ya que son pines sin ningn tipo de sistema de proteccin. Esto
implica que si por un descuido cortocircuitramos alguno de ellos, podramos deteriorar la
Raspberry.
Opcin N2) 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 caractersticas y versatilidad se ha
elegido el Arduino shield diseado y distribuido por la empresa Zaragozana Cooking
Hacks/Libelium. Este nos ofrece las siguientes caractersticas:
Nos garantiza 100% de compatibilidad con todos los mdulos ya existentes para Arduino.
Esto nos permite desarrollar entornos muy verstiles.
Nos permite poder trabajar con seales analgicas 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 programacin utilizado para el desarrollo de aplicaciones es C, un lenguaje
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 ms 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 propsito 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 alimentacin y de referencia o masa, patillas de
comunicacin con elementos externos como UART o SPI, etc.) y otras que s que lo son (las patillas
de propsito 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 ms sencilla de gestionarlo es mediante comandos especficos de la
shell del sistema, ofrecindonos la opcin de poderse ejecutar directamente desde una consola o
terminal del sistema o embeber en cualquiera de los lenguajes de programacin que existen. En el
ejemplo que se mostrar a continuacin, se ha desarrollado una sencilla aplicacin Web en PHP que
permite ejecutar comandos del sistema de gestin del GPIO desde un cliente Web.
14.1.1.- Control directo del GPIO: Instalacin de wiringPi.
Antes de empezar a controlar elementos externos, habr que instalar el programa o librera
wiringPi, para lo que seguiremos los siguientes pasos:
[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 gestin GPIO mediante wiringPi
[pi@raspberry]# git clone git://git.drogon.net/wiringPi #Descargamos la librera necesaria
[pi@raspberry]# cd wiringPi
[pi@raspberry]# git pull origin #Comprobacin de que esta actualizado
[pi@raspberry]# ./build
Para comprobar que se ha instalado correctamente podemos ejecutar los siguientes
comandos, que nos dar informacin del estado de cada uno de los puertos GPIO:
[pi@raspberry]# gpio readall
Adems, si queremos hacer algunas pruebas de gestin del GPIO, podramos conectar
alguna resistencia y diodo led entre cualesquiera de los puertos de propsito general del GPIO y
masa o GND, configurar a continuacin el correspondiente puerto como salida (out), y encender y
apagar el diodo led en funcin 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 nmero o posicin (p.e. pin 22), sino a su identificador (p.e.
GPIO 25).
14.1.2.- Gestin Domtica va web en modo seguro HTTPS: Control

directo del GPIO
Ahora haremos uso de la gestin de puertos remotamente va Web a travs de un sitio que
hallamos configurado en nuestro servidor Web (p.e. Apache).
En cuanto a la configuracin de Apache para dar un servicio en modo seguro HTTPS:
1) Para garantizar una comunicacin 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 prctica N9 correspondiente a HTTP/HTTPS):
[root@raspberry]# mkdir /etc/apache2/server2
[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
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).
[root@raspberry]# openssl x509 -req -in server2cert.p10 -out server2cert.pem \
[root@raspberry]# nano /etc/apache2/sites-available/ejemplo-domotico1.conf
ServerName domotica.miservidor.es
DocumentRoot /var/www/domotica1
DirectoryIndex index.php
SSLEngine on
SSLCertificateFile /etc/apache2/server2/server2cert.pem
SSLCertificateKeyFile /etc/apache2/server2/server2.pem
<Directory /var/www/domotica1>
Allow from all
</Directory>
</VirtualHost>
Tras configurar el nuevo sitio Web seguro, tan slo tendremos que habilitarlo y reiniciar el
servicio para que surtan efecto los cambios:
[root@raspberry]# a2ensite ejemplo-domotico1.conf
2) Para poder progamar nuestro sitio Web en PHP, deberemos previamente instalar la librera en
Apache que le permite interpretar cdigo 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 aplicacin, ser necesario autenticarse. Un ejemplo bsico de cdigo PHP
para la pgina index.php sera el siguiente, donde mediante variables de sesin $_SESSION
almacenamos la correcto autenticacin del usuario y redireccionamiento hacia el resto de las
pginas del sitio Web (p.e. control1.php):
En cuanto al contenido de la pgina de inicio del sitio Web de gestin domtica (el
index.php controla el acceso de usuarios a la pgina Web desde la cual se establece el control
domtico), y la subpgina Web (control1.php) encargada de interactuar con el usuario para permitir
la gestin domtica podra ser el que se muestra a continuacin:
Importante!! Mediante la ayuda de la funcin 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 podra ser el estado de una bombilla a travs de un rel o cualquier otro
dispositivo elctrico.
[root@raspberry]# nano /var/www/web/index.php
<? session_start(); ?>
<style type="text/css">
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; }
</style>
<fieldset class="f1">
<legend>Control de Acceso</legend>
<form name="form1" method="post" action="">
Nombre: <input type="text" name="nombre" size="20"><br><br>
Password: <input type="password" name="pass" size="20"> <br><br>
<input type="submit" name="boton" value="Enviar">
</form>
</fieldset>
<?
if ( isset($_POST['boton']) ) {
if ( $_POST['nombre'] == "arturo" && $_POST['pass'] == "1234" ) {
$_SESSION['comprobacion'] = "ok";
$_SESSION['nombreusu'] = $_POST['nombre'];
header('Location: control1.php');
}
else {
$_SESSION['comprobacion'] = "error";
?>
<br>
<legend style="color: red;">Respuesta ante la autenticacion</legend>
Lo sentimos ... Tu login o password son falsos.
</fieldset>
<?
}
unset($_POST['boton']);
} ?>
[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; }

background-color: orange; text-align: center; }
</style>
<?
if ( $_SESSION['comprobacion'] == "ok" ) {
?>
Bienvenido Sr. <? echo $_SESSION['nombreusu']; ?>
( <a href="desconectar.php">Cerrar Sesin</a> )
</fieldset>
<legend>Elije que quieres hacer</legend>
Accin:
<select name="accion">
<option value="op0">--Elige una opcion--</option>
<option value="op1">Encender la bombilla</option>
<option value="op2">Apagar la bombilla</option>
</select>
<input type="submit" name="boton" value="Ejecutar">
</form>
</fieldset>
<?
}
else {
?>
<legend>Problema de Seguridad</legend>
No deberas tratar de acceder por aqu. Debes autenticarte primero. <br><br>
Gracias.
</fieldset>
<?
}
?>
<?
if ( isset ($_POST['boton']) ) {
if ( $_POST['accion'] == "op1" ) {
shell_exec('gpio -g mode 25 out');
shell_exec('gpio -g write 25 1');
shell_exec('echo Accion: `date +%H:%M_%d/%m/%y` Encender bombilla >>
/home/pi/auditoria.dat');
}
if ( $_POST['accion'] == "op2" ) {
shell_exec('gpio -g mode 25 out');
shell_exec('gpio -g write 25 0');
shell_exec('echo Accion: `date +%H:%M_%d/%m/%y` Apagar bombilla >>
/home/pi/auditoria.dat');
}
unset ($_POST['boton']);
}
?>
<br><br>
<hr><a href="index.php">VOLVER PAGINA INICIO</a>
14.2.- Raspberry con Shield Arduino. Configuracin previa

Antes de poder empezar a programar aplicaciones de control domtico 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 pgina Web:
http://www.cooking-hacks.com/index.php/documentation/tutorials/raspberry-pi-toarduino-shields-connection-bridge.
1) Descargar desde la URL anterior la librera arduPi.

2) Editar los archivos de configuracin /boot/cmdline.txt y /etc/inittab, y reiniciar para que
surtan efecto los cambios:
[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 lnea anterior
dwc_otg.lpm_enable=0 console=tty1 $
[root@raspberry]# nano /etc/inittab
# Comentar en inittab la lnea siguiente:
## T0:23:respawn:/sbin/getty -L ttyAMA0 115200 vt100
[root@raspberry]# reboot
14.2.1.- Ejemplos bsicos de control de dispositivos externo mediante

el Shield Arduino.
A continuacin se mostrarn tres ejemplos muy bsicos de gestin de entradas y salidas a
travs del puerto GPIO.
Antes de empezar a programar, en primer lugar compilaremos la librera arduPi que te
habrs descargado en el apartado anterior, ya que ser necesaria para la posterior compilacin de
cualquier otro programa que la requiera:
[root@raspberry]# g++ -c arduPi.cpp -o arduPi.o
Ahora, una vez realizado nuestro programa lo compilaremos apoyndonos en la librera
anterior, ejecutando el siguiente comando:
[root@raspberry]# g++ -lrt -lpthread mi_programa.cpp arduPi.o -o mi_programa
Ejemplo 1) Encender/Apagar un led externo conectado en el Pin2 del Arduino shield.

El siguiente cdigo muestra la estructura que deber tener todo programa que quiera
gestionar los puertos del Arduino shield mediante la ayuda de la librera arduPi:
// Incluimos la librera arduPi
#include "arduPi.h"
// Necesario para la comunicacin serie
SerialPi Serial;
// Necesario para aceder a GPIO: pinMode, digitalWrite, digitalRead, i2C functions
WirePi Wire;
//Necesario para SPI
SPIPi SPI;
// Zona Declaracin de funciones que se usarn en el programa principal
// Funciones que sern llamadas desde el cdigo que se programe a continuacin
// A continuacin declararemos el cdigo arduino

// Cdigo
// Estructura general de todo programa cclico (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
#include "arduPi.h"
SerialPi Serial;
// Necesario para acceder a GPIO: pinMode, digitalWrite, digitalRead, i2C
functions
WirePi Wire;
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);
//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 peridicamente: 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.
#include "arduPi.h"
SerialPi Serial;
// Necesario para aceder a GPIO: pinMode, digitalWrite, digitalRead, i2C
functions
WirePi Wire;
SPIPi SPI;
// Definimos los pines 2 y 6 del Arduino shield como salidas
int ledPin6verde = 6;
void setup()
{
pinMode(ledPin6verde, OUTPUT);
}
// Programamos lo que ocurrir en cada ciclo
void loop()
{
digitalWrite(ledPin6verde, LOW);
delay(2000);
digitalWrite(ledPin6verde, HIGH);
delay(2000);
}
// Editamos el programa principal
int main (){
setup();
while(1){
loop();
}
return (0);
}
Y para probarlo:

Ejemplo 3) Encender/Apagar dos leds externos conectado en el Pin2 y Pin6 en funcin 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,
provocara lo contrario. Adems 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 librera 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:
#include "arduPi.h"
SerialPi Serial;
functions
WirePi Wire;
SPIPi SPI;
// Definimos los pines 2 y 6 del Arduino shield como salidas
int ledPin3verde = 3;
int interruptor1Pin4 = 4;
int interruptor2Pin5 = 5;
void setup()
{
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(ledPin3verde, HIGH);
system(echo `date +%H:%M_%d/%m/%y` Led Verde ON >> auditoria.dat);
}
if ( valor2 == HIGH && valor1 == LOW )
{
digitalWrite(ledPin3verde, LOW);
system(echo `date +%H:%M_%d/%m/%y` Led Rojo ON >> auditoria.dat);
}
// Editamos el programa principal
int main (){
setup();
while(1){
loop();
}
return (0);
}
Y para probarlo:
14.2.2.- Gestin Domtica va web en modo seguro HTTPS de

dispositivos externos mediante Shield Arduino.
A continuacin 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 accin directa del humano, sino remotamente a travs de un navegador Web mediante nuestro
smartphone, tablet u ordenador (porttil o de sobremesa). En concreto en el ejemplo que se muestra
a continuacin se tendrn en cuenta las siguientes caractersticas: 1) la comunicacin ser segura
entre el navegador Web y la Raspberry mediante el protocolo HTTPS, 2) el acceso ser restringido
mediante login y password, 3) los dilogos de comunicacin entre el cliente y servidor se basarn
en formularios HTML, 4) el lenguaje de programacin 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 elctrica
(230v/50Hz) mediante un triac optoacoplado o rel de estado slido (p.e. S108T02), a travs del pin
n2 del puerto de I/O del Arduino shield (a modo de prctica se puede hacer simplemente
conectando un led en el pin n2 y probar a encenderlo y apagarlo).
RLED
Triac Optoacoplado
Rel de estado slido
VRED
230V/50Hz
1) Para garantizar una comunicacin 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 prctica N9 correspondiente a HTTP/HTTPS):
[root@raspberry]# mkdir /etc/apache2/server2
[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
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).
[root@raspberry]# openssl x509 -req -in server2cert.p10 -out server2cert.pem \
[root@raspberry]# nano /etc/apache2/sites-available/ejemplo-domotico1.conf
ServerName domotica.miservidor.es
DocumentRoot /var/www/domotica1
DirectoryIndex index.php
SSLEngine on
SSLCertificateFile /etc/apache2/server2/server2cert.pem
SSLCertificateKeyFile /etc/apache2/server2/server2.pem
<Directory /var/www/domotica1>
Allow from all
</Directory>
</VirtualHost>
Tras configurar el nuevo sitio Web seguro, tan slo tendremos que habilitarlo y reiniciar el
servicio para que surtan efecto los cambios:
[root@raspberry]# a2ensite ejemplo-domotico1.conf
2) Para poder progamar nuestro sitio Web en PHP, deberemos previamente instalar la librera en
Apache que le permite interpretar cdigo 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 aplicacin, ser necesario autenticarse. Un ejemplo bsico de cdigo PHP
para la pgina index.php sera el siguiente, donde mediante variables de sesin $_SESSION
almacenamos la correcto autenticacin del usuario y redireccionamiento hacia el resto de las
pginas del sitio Web (p.e. control1.php):
[root@raspberry]# nano /var/www/domotica1/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;
</style>
<legend>Control de Acceso</legend>
Nombre: <input type="text" name="nombre" size="20"><br><br>
Password: <input type="password" name="pass" size="20"> <br><br>
<input type="submit" name="boton" value="Enviar">
</form>
</fieldset>
<?
if ( isset($_POST['boton']) )
{
if ( $_POST['nombre'] == "arturo" && $_POST['pass'] == "1234" )
{
$_SESSION['comprobacion'] = "ok";
$_SESSION['nombreusu'] = $_POST['nombre'];
header('Location: control1.php');
}
else
{
$_SESSION['comprobacion'] = "error";
?>
<br>
<legend style="color: red;">Respuesta ante la autenticacion</legend>
Lo sentimos ... Tu login o password son falsos.
</fieldset>
<?
}
unset($_POST['boton']);
}
?>
4) Mediante el uso de un formulario HTML el usuario podr decidir la accin a realizar sobre los
elementos externos:
[root@raspberry]# nano /var/www/domotica1/control1.php
background-color: lightblue; color: brown; text-align: right; }
background-color: orange; text-align: center; }

</style>
<?
if ( $_SESSION['comprobacion'] == "ok" )
{
?>
Bienvenido Sr. <? echo $_SESSION['nombreusu']; ?>
( <a href="desconectar.php">Cerrar Sesin</a> )
</fieldset>
<legend>Elije que quieres hacer</legend>
Accin:
<select name="accion">
<option value="op0">--Elige una opcion--</option>
<option value="op1">Encender la bombilla</option>
<option value="op2">Apagar la bombilla</option>
</select>
<input type="submit" name="boton" value="Ejecutar">
</form>
</fieldset>
<?
}
else
{
?>
<legend>Problema de Seguridad</legend>
No deberas tratar de acceder por aqu. Debes autenticarte primero.
<br><br>
Gracias.
</fieldset>
<?
}
?>
<?
if ( isset ($_POST['boton']) )
{
if ( $_POST['accion'] == "op1" )
{
shell_exec('sudo /home/arturo/programas/encender');
/home/arturo/programas/auditoria.dat');
}
if ( $_POST['accion'] == "op2" )
{
shell_exec('sudo /home/arturo/programas/apagar');
/home/arturo/programas/auditoria.dat');
}
unset ($_POST['boton']);
}
?>
<br><br>
<hr><a href="index.php">VOLVER PAGINA INICIO</a>
Donde el contenido de el contenido de los programas encender y apagar sera:
[root@raspberry]# nano encender.cpp
#include "arduPi.h"
SerialPi Serial;
functions
WirePi Wire;
SPIPi SPI;
370) y el anodo del led del triac optoacoplado
int optoPin2 = 2;
void setup()
{
pinMode(optoPin2, OUTPUT);
}
int main (){
setup();
//Encendemos la bombilla al excitar el led del triac optoacoplado
return (0);
}
[root@raspberry]# nano apagar.cpp

#include "arduPi.h"
SerialPi Serial;
functions
WirePi Wire;
SPIPi SPI;
370) y el anodo del led del triac optoacoplado
int optoPin2 = 2;
void setup()
{
pinMode(optoPin2, OUTPUT);
}
int main (){
setup();
//Apagamos la bombilla al excitar el led del triac optoacoplado
return (0);
}
Y para poder probar su ejecucin va 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 deberamos acceder desde un navegador Web al servicio HTTPS servidor por Apache,
y tras autenticarnos deberamos estar encendiendo o apagando la bombilla externa, en funcin de la
opcin elegida en el campo select del formulario.
Prctica n15.- Implementacin final de la Estacin de Servicios.

Haciendo uso de lo aprendido a lo largo de las diferentes prcticas presentadas en este
documento, pasaremos a implementar la mayor parte de los servicios en un entorno de produccin
real. Para ello, en esta ltima prctica debers configurar la conexin 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 pblicos (sern
comprobados por el profesor desde clase):
- Debers registrarte en no-ip y dar de alta un nombre de dominio pblico cualificado (FQDN)
que se corresponda con la direccin IP pblica 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 algn posible
cambio de tu direccin pblica, en el caso de que esta sea dinmica.
- Debers redireccionar los siguientes puertos del router ISP haca la Raspberry: 22-SSH,
443-HTTPS y 1194-VPN. De esta forma podremos gestionar remotamente nuestra estacin de
servicios va SSH, hacer un control domtico o de otro tipo va HTTPS y acceder a todos los
recursos (p.e. va SMB/CIFS) que se comparten en la Intranet gracias a la VPN.
- Debers crear una cuenta SSH para el profesor (login/password): profesor/1234321. De esta
forma, va SSH el profesor podr comprobar todas las configuraciones realizadas.

Raspberry Pi como servidora multiuso

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Raspberry Pi como servidora multiuso

Transféré par

Droits d'auteur :

Formats disponibles

IMPLEMENTACIN DE

IES TIEMPOS MODERNOS

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 1

Hace escasamente un ao, en febrero del 2012 sali al mercado el

Para cualquier cuestin, constructiva o destructiva, que pueda mejorar el

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 2

9.2.- Creacin de las claves y certificados del servicio HTTPS...............................................42

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 4

Prctica n1.- Instalacin del Sistema Operativo Raspbian

Tras la ejecucin del comando anterior, df -h deberemos advertir como ha detectado

[root@linux]# dd bs=4M if=Descargas/version-raspbian.img of=/dev/sdc

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 6

Prctica n2.- Primer Arranque de la Raspberry Pi.

En concreto, cabra destacar que podemos configurar los siguientes aspectos:

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 8

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 9

Prctica n3.- Conexin a Internet de la Raspberry

3.1.- Configuracin de la Interfaz Inalmbrica de manera grfica (GUI)

3.2.- Configuracin de la Interfaz Inalmbrica desde la terminal (CLUI)

[pi@raspberry]$ wpa_passphrase red1 1234567890

3.3.- Actualizacin de los Repositorios y del Software del Sistema

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 11

Prctica n4.- Configuracin de la Raspberry como servidor DHCP.

4.1.- Instalacin del software servidor DHCP.

4.2.- Configuracin del servicio DHCP.

## PARTE N2 Asignacin dinmica de direcciones IP dependiente del equipo solicitante

4.3.- Configuracin de los clientes DHCP.

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 14

3) Si ejecutamos un more /etc/resolv.conf en el cliente deberan mostrarse los servidores DNS

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 15

Prctica n5.- Configuracin de la Raspberry como servidor DNS.

5.1.- Instalacin y Configuracin del servicio DNS.

5.2.- Raspberry Pi como servidor DNS Maestro.

5.3.- Comprobacin del servicio DNS.

[root@clientedns]# dig -t MX aulainformatica.es

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 18

Prctica n6.- Configuracin de la Raspberry como Puerta de Enlace

Activar el reenvo de paquetes TCP/IP entre las diferentes interfaces de red de la

1 Opcin: Introducir un 1 el fichero virtual /proc/sys/net/ipv4/ip_forward. Para ello

[root@gw]# nano /etc/rc.local

echo 1 > /proc/sys/net/ipv4/ip_forward

Activar el NAT Postrouting. Para evitar problemas de encaminamiento en los paquetes de

[root@gw]# iptables -t nat -A POSTROUTING -o wlan0 -j MASQUERADE

echo 1 > /proc/sys/net/ipv4/ip_forward

6.1.- Configuracin bsica de la Raspberry como Firewall

echo 1 > /proc/sys/net/ipv4/ip_forward

6.2.- Configuracin de la Raspberry como Punto de Acceso (AP)

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 21

[root@puntoacceso]# nano /etc/network/interfaces

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 23

Prctica n7.- Configuracin de la Raspberry como servidor RADIUS.

7.1.- Introduccin al servicio RADIUS.

Autenticacin (authentication) hace referencia al proceso por el cual se determina si un

contener nombres de usuarios y sus contraseas.

Autorizacin (authorization) se refiere a conceder servicios especficos (entre los que se

El proceso de autorizacin determina la naturaleza del servicio que se concede al usuario,

Registro (accounting, a menudo traducido tambin como contabilidad) se refiere a realizar

Es interesante el uso del protocolo RADIUS cuando tenemos redes de dimensiones

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 26

7.2.2) Definicin de NAS .

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 29

C) Indicaremos el protocolo de autenticacin. Como ya se ha dicho previamente tanto los equipos

Configuracin de la Raspberry Pi como estacin de Servicios Arturo Martn Romero 30