Montando nuestro propio servidor (V)

De como montar un gateway y otras cosillas.....

Buenas a todos. Volví de la playa con las pilas cargadas, preparado para finalizar nuestro servidor en un par de sudo aptitude install, pero me esperaba unos meses de Agosto y Septiembre que no se lo deseo ni siquiera a Bill Gates. Debe haber una conjunción de planetas dedicada en exclusiva a complicarme la vida, rompiéndose todo a horas intempestivas, cualquier día de la semana, pero preferentemente de noche, y en fin de semana. Ya sé que con lo que tenemos en este país puedo considerarme un privilegiado, pero como quejarse es gratis (y lo seguirá siendo, a pesar del IVA) pues lo hago, que todavía no me han quitado ese derecho....

Este va a ser uno de los post más largos, con diferencia, de la serie. Tenemos que conseguir, al final del post, que todos tengamos nuestro server corriendo como el gateway de nuestra red local con IPTABLES. Como recordaréis de post anteriores, mi hijo me quitó el monitor. Bueno, es cierto que era suyo y yo se lo había quitado antes, pero.... ¿donde quedó la autoridad paterna? Aquello de... “¿Cómo que democracia?... Esta es mi casa, y se hace democráticamente lo que yo diga....” que decía mi padre.... Paissssss...... Bueno, pues el resultado es que hay que hacerlo todo desde consola remota, aunque si tenéis monitor a mano..... pues eso, que es más fácil (Para aquellos que no sepan leer entre líneas, esto quiere decir que yo he tenido que recurrir a quitarle de nuevo el monitor a mi hijo, porque me quedé sin conexión al servidor. Ahora, tal y como explicaré en el post, ya no será necesario).

Para empezar, eso de Gateway, ¿sabemos lo que es?. ¿O sólo lo creemos? Vamos a verlo. En telecomunicaciones, el término gateway puede significar:

• Un nodo de una red de comunicaciones, preparado para la interconexión con otra red que puede utilizar distintos protocolos. Dicho nodo puede estar dotado de dispositivos físico/lógicos como traductores de protocolo, traductores de señal, aisladores de fallos, dispositivos de compatibilidad e impedancia, etc... Vamos, cualquier nodo de cualquier ISP de Internet.
• Un ordenador o programa, que funciona como puerta de enlace, o encaminador, desde una red a otra, pudiendo ser éstas internas o externas. Esto es lo que buscamos nosotros para nuestro server.

Vale, chachi, pero.... ¿para qué nos sirve? Aparte de para darnos trabajo, claro.... Bueno, si recordáis mi primer post de la serie, os indicaba que estaba montando un aula de informática en una asociación a la que pertenezco. Estos ordenadores van a ser usados tanto por adultos como por niños. Si obligamos a que todos los pc “pasen” por nuestro server antes de salir a Internet, podemos establecer una serie de filtros en él para evitar accesos a páginas no “recomendables”, por poner un ejemplo. Claro, estoy hablando de una red que está formada por 20 pc's más el server; en una red doméstica...... pues a lo mejor no es necesario.... o sí..... Yo tengo dos niños, así que me va a venir de perlas....

¿Y cuánto hardware necesito para montarlo? Pues tanto como podáis, que no está la economía para derroches.... Yo lo voy a montar de la siguiente manera:

Internet → Router → 1ª NIC → 2ª NIC  → Wireless Access Point ó Switch → PC's

¿Es necesaria la segunda tarjeta de red? SI. Podríamos intentar hacerlo con una sola NIC, asignando 2 IP's distintas a la misma tarjeta, pero sería un problema a la hora de configurar servicios. Va a ser mejor que sí, que la montemos.

¿Y el switch o Access Point? Hombre, si váis a tener más de un PC en la red, si. Si sólo hay un PC, con un cable cruzado (Crossover) basta para unir el server con dicho PC. En mi caso, como no voy a cablear ni el aula ni mi casa, pues si, voy a montar un Wireless AP.

Vamos allá con la configuración de las NIC. Ante alguna duda suscitada con mi dirección IP privada, comentaros que cuando se crearon las reglas de direcciones IP para internet, se dejaron cuatro redes sin incluir en la web, para poder crear redes privadas. Estas son las siguientes:

10.0.0.0 a 10.255.255.255

172.16.0.0 a 172.31.255.255

192.168.0.0 a 192.168.255.255

169.254.0.0 a 169.254.255.255

Cada una de ellas tiene un numero de direcciones IP limitadas, desde las más de 16 millones de la primera, a las más de 65.000 de las dos últimas. Yo utilizo la primera por deformación profesional, no porque tenga esa cantidad de ordenadores en casa.

En nuestra nueva aventura (y espero que definitiva), voy a utilizar el siguiente escenario:

La IP privada del router es la 10.14.100.1

La IP de la primera NIC (eth0) va a ser 10.14.100.10

Voy a utilizar el rango 172.16.0.x para la red local. Así, la segunda NIC (eth1) tendrá la IP 172.16.0.1

Lógicamente, esto nos va a obligar a recomponer todo lo que habíamos hecho anteriormente. Habrá que reconfigurar/comprobar el archivo /etc/network/interfacespara establecer las IP's, el archivo etc/ssh/sshd_config para seguir teniendo acceso por SSH, el DDCLIENTpara seguir teniendo acceso desde el exterior, el DHCP para servir las nuevas direcciones IP, el archivo /etc/proftpd/proftpd.confpara nuestro FTP y el archivo /etc/samba/smb.confpara nuestro servidor de archivos. Aunque parezca un trabajo de chinos, no es para tanto. Voy a tardar más en describirlo que en cambiarlo. En fin, esto es lo que pasa por no preparar una guía inicial e ir añadiendo cosas sobre la marcha....

Instalamos la segunda nic en nuestro server. 4 reglas importantes: Alimentación eléctrica desconectada, nos descargamos de la posible estática (vamos, con que toquemos el suelo con la mano, vale), insertar correctamente la nic en su bus, y cuidado con las gotas de sudor, tienen la mala costumbre de realizar cortos en las motherboard. Arrancamos y tecleando que es gerundio:

Verificamos que la segunda NIC está correctamente instalada. Probablemente la haya reconocido sin problemas, lspcipara verlo:

 

Ahí está la condenada..... esperando una IP como agua de mayo.... No la vamos a defraudar, ¿no? Pobrecilla, sú único fin en la vida es tener su propia IP y enviar y recibir paquetes......

nano /etc/network/interfaces

# Interface INTERNET, conectada directamente al router

auto eth0

iface eth0 inet static

address 10.14.100.10

netmask 255.255.255.0

network 14.14.100.0

broadcast 14.14.100.255

gateway 10.14.100.1

#Interface RED LOCAL, conectada al Access Point

auto eth1

iface eth1 inet static

address 172.16.0.1

netmask 255.255.255.0

network 172.16.0.0

broadcast 172.16.0.255

y reiniciamos las interfaces:

ifdown eth0 && ifdown eth1 && ifup eth0 && ifup eth1

Lógicamente, perderemos la conexión con el server en cuanto cambiemos la dirección IP, por eso reiniciamos las dos NIC en la misma línea. Configuramos nuestro PC para que tenga una IP estática dentro del rango del nuevo server, por ejemplo: 172.16.0.100. Hasta que no terminemos con el server, tener en cuenta que tampoco tendremos salida a internet.

Nos conectamos de nuevo al server, y verificamos que funcionen las dos interfaces: ifconfig

Ea, pues lo creáis o no, ya está montado el Gateway. Pero, ¿funciona?. Por supuesto que.... NO. Todavía falta un buen cacho..... Antes de seguir configurando, vamos a ver si nuestro kernel tiene implementada la función IP Forwarding.

[Frannoe dixit]: ¿Y eso que es?

[Jose respondere]: ¿Ya empezamos con las preguntitas, Frannoe?

IP Forwarding es parte del Kernel de Linux, en concreto, es parte de IPTABLES, que a su vez es parte del framework NETFILTER del Kernel...... Osea, que no hay que instalar nada. Que ya viene todo empaquetadito en nuestro Kernel. Y lo que hace es, como su propio nombre indica, reenviar los paquetes IP de una NIC a otra. Es decir, el funcionamiento de nuestro server va a ser de la siguiente manera:

Mi portátil con IP 172.16.0.x se conecta por la red local al servidor en la segunda NIC con IP 172.16.0.1. El kernel del server analizará la petición de mi portátil para ver qué es lo queremos (FTP, SSH, HTTP, etc). En función a lo que deseemos, y aplicando las reglas de IPTABLES que definiremos, realizará un reenvío de dichos paquetes (IP Forwarding) a la primera NIC del servidor (IP 10.14.100.2) y de ésta al router (IP 10.14.100.1). De ahí a Internet, se encarga el router. Pero para que haga todo esto, hay que averiguar si está activado o no el IP Forwarding. Para ello, tecleamos 

 

cat /proc/sys/net/ipv4/ip_forward.

Si nos devuelve 1, está activado. Si nos devuelve 0, haremos lo siguiente: tecleamos

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

y a continuación volvemos a teclear

cat /proc/sys/net/ipv4/ip_forward.

Es decir, marcamos el valor de ip_forward a 1, y volvemos a verificar si acepta dicha asignación. Si alguno de vosotros sigue obteniendo de respuesta 0, querido sufridor linuxero, es el momento perfecto de aprender a compilar el kernel, activando el IP Forwarding. No creo que tengáis ese problema, hemos montado todos la misma imagen, pero no obstante, si alguien tiene ese problema, hay manuales en Google de cómo recompilar el kernel.

 

 

Vale, como no tenemos que recompilar el kernel (¡Thanks, My God!) seguimos recomponiendo/verificando todo lo que habíamos hecho con nuestro server. Vamos por partes.

SSH

Bueno, no necesitamos tocar nada en el archivo de configuración. Si editamos el archivo /etc/ssh/sshd_config , vemos que escucha en cualquier interface y a cualquier IP (la verdad es que ya lo sabía, si no es así, al cambiar la IP, no podríamos volver a conectarnos).

DDCLIENT

Comprobamos el archivo /etc/ddclient.conf. Vemos que lo dejamos configurado para que escuchara directamente a la web, con lo que no tenemos que cambiar nada.

DHCP

Cuando un equipo configurado con IP dinámica arranca, solicita una dirección IP a un servidor DHCP. Esto se hace mediante una emisión de un paquete estandarizado de solicitud DHCP a la dirección 255.255.255.255. Si el servidor DHCP tiene más de una interface, hay que agregar una ruta de esta dirección para que el servidor sepa a qué interface debe enviar la respuesta. Si no lo hacemos, enviaría la respuesta DHCP por defecto a la puerta de enlace predeterminada, con lo que nuestra red se quedaría sin direcciones IP. Es sencillo, una simple línea bastaría: route add -host 255.255.255.255 dev eth1. Pero no vamos a estar tecleando continuament esto, ¿no?. ¿Que tal si hacemos que la ruta se ejecute al iniciar la interface?. Editamos de nuevo /etc/network/interfaces, y dejamos así la interface 1:

#Interface RED LOCAL, conectada al Access Point

auto eth1

iface eth1 inet static

up route add -host 255.255.255.255 dev eth1

address 172.16.0.1

netmask 255.255.255.0

network 172.16.0.0

broadcast 172.16.0.255

Reiniciamos eth1 para aplicar los cambios:

ifdown eth1 && ifup eth1

Bueno, pues ya hemos conseguido que el DHCP server responda por la NIC adecuada. Ahora, además, hay que conseguir que escuche también por la interface correcta. Para eso hay que editar el archivo /etc/default/isc-dhcp-server y establecemos ETH1.

-->

Ahora editamos el archivo /etc/dhcp/dhcpd.conf para modificar el pool de direcciones:

nano /etc/dhcp/dhcpd.conf

#Nota: Yo no necesito más que cinco IP's:

#2 portátiles, 2 dispositivos móviles (tablets) y un PC de sobremesa

#Cada cual, que alargue el rango del pool todo lo que necesite....

subnet 172.16.0.0 netmask 255.255.255.0{

range 172.16.0.10 172.16.0.14;

option domain-name-servers 80.58.61.250, 80.58.61.254;

option domain-name "cosillas.ftp21.net";

option routers 172.16.0.1;

default-lease-time 600;

max-lease-time 7200;

}

host impresora_red{

hardware ethernet 01:02:03:04:05:06;

fixed-address 172.16.0.20;

}

host camara_web{

hardware ethernet 06:05:04:03:02:01;

fixed-address 172.16.0.30;

}

host computer_hijo{

hardware ethernet 00:01:02:02:01:00;

fixed-address 172.16.0.50;

}

host computer_hija{

hardware ethernet 00:01:02:00:01:02;

fixed-address 172.16.0.60;

}

Y con esto ya tendríamos listo nuestro DHCP para la nueva configuración. Por supuesto, siempre que modifiquemos algún servicio, lo reiniciamos: 

 /etc/init.d/isc-dhcp-server restart.

-->

FTP

Por defecto, nuestro FTP escucha en la eth0 (la que está conectada a internet directamente). Así, no tendríamos que tocar nada en nuestro archivo de configuración /etc/proftpd/proftpd.conf., ya que configuramos nuestro FTP para acceder desde el exterior.

SAMBA

En nuestro servidor de archivos sí tenemos que especificar en qué interface escucha dicho servicio. Lógicamente, editaremos nuestro archivo de configuración /etc/samba/smb.conf. Buscaremos en la sección Networking, y dejaremos la linea de la siguiente manera:

interfaces=172.16.0.0/24 eth1

 

Ya que si no lo hicéramos, nuestros recursos de red interna estarían disponibles a cualquier hijo de vecino que accediera a nuestro servidor desde Singapur, por poner un ejemplo....

-->

Y una vez arreglado nuestro desaguisado por no haber sido previsores, pasamos al meollo de la cuestión. Jo, llevo dos horas delante de la pantalla, y ni siquiera tengo acceso a internet.... Paciencia, que ya va la cosa sobre la marcha.....

Venga, vamos a poner en marcha nuestro gateway. Primero de todo, configuramos la NIC de los clientes para que obtengan IP del DHCP del server. Podéis hacerlo vía entorno gráfico o editando el archivo /etc/network/interfaces, eso lo dejo a gusto del lector. Llegados a este punto, es hora de hacer funcionar nuestro server como gateway. Porque si intentamos acceder a la web, nos dará un bonito error indicando que no hay acceso. Vamos a utilizar la lógica. ¿Qué necesitamos para que nuestro server sea la puerta de enlace?

Veamos, estamos conectados a nuestro server por medio de la red local, pero no al router para salir a internet. Tenemos que decirle al server que los paquetes que reciba de nuestro/s equipo/s de sobremesa tiene que enrutarlos hacia la segunda tarjeta de red, y de ahí a internet a través del router. Pero además, tiene que hacer otra cosa: tiene que saber que los paquetes de mi portátil, que llegan al server a través de la IP 172.16.0.2, y salen a internet a través de la IP 14.100.10.2, no son los mismos que los del ordenador de mi mujer, que tiene la IP 172.16.0.3 y salen por la misma IP de la tarjeta eth0 hacia internet. Ese proceso se llama NAT (Network Address Translation, ó Traducción de Dirección de Red). Ese proceso lo hace habitualmente el router, y por eso es la puerta de enlace en una configuración normal. Pero como somos un poco masoquistas, y hemos decidido cambiar la puerta de enlace, ahora es nuestro server el que tiene que servir para dar servicio a varias direcciones privadas (LAN), teniendo solo una dirección pública (IP INTERNET). Y a varios protocolos distintos, para más inri.... Yo puedo estar conectado por Putty al servidor de mi empresa (puerto 22, SSH), mi mujer consultando el extracto bancario (puerto 443, protocolo https) y mi hija descargando música con la mula (puerto 32445, protocolo web). Como véis, todo un trabajito para hacer en tiempo real....

Entonces, conectados de nuevo al server, tenemos que conseguir activar el reenvío de paquetes desde la red interna a la externa, además de las reglas necesarias para que los pueda enrutar. Lo haremos mediante la ejecución de un pequeño script, que se ejecutará en cuanto las interfaces de red del server se levanten, utilizando IPTABLES. Como os comenté antes, IPTABLES es parte del kernel, no es ninguna aplicación en sí, así que lo que hacemos con el script es decirle al kernel cómo actuar. Creamos el directorio Firewall dentro de /etc/network:

-->

mkdir /etc/network/Firewall

Creamos el archivo fwall.sh en este directorio:

nano /etc/network/Firewall/fwall.sh

y tecleamos:

-->

Guardamos y salimos. En definitiva, lo que hemos hecho es crear un script que activa un firewall básico, que acepta lo que le hemos dicho y rechaza todo lo demás. Ahora necesitamos hacer que este script se ejecute al inicio del sistema, antes que las interfaces de red se hayan levantado. Para ello, damos permisos de ejecución:

chmod +x /etc/network/Firewall/fwall.sh

y editamos el archivo /etc/network/interfaces para añadir la siguiente línea:

nano /etc/network/interfaces

# Interface INTERNET, conectada directamente al router

auto eth0

iface eth0 inet static

pre-up /etc/network/Firewall/fwall.sh

address 10.14.100.2

netmask 255.255.255.0

network 14.14.100.0

broadcast 14.14.100.255

gateway 10.14.100.1

Así, ejecutamos el script antes de que se levante la interface de red. Reiniciamos eth0 y..... voilá.... ya tenemos acceso de nuevo a Internet.

¿Cual sería el paso siguiente? Pues ahora deberíamos aplicar los filtros a los que queremos que tengan acceso unas personas si y otras no. La manera más cómoda de hacerlo es implantando un proxy. Yo me voy a decantar por Squid, por su facilidad de uso y versatilidad. Pero eso es otra historia y será contada en el próximo post.

Un saludo a todos.