Montando nuestro propio servidor (II)

-->

Hola a todos.

Aprovecho mi semana “light” para ir avanzando en el tema. Llevo dos semanas con implantaciones de sistemas nuevos y formación, que no veas. La semana que viene será de órdago y no podré ni encender mi portátil

Bueno, ya teníamos nuestro servidor instalado. Pero la verdad es que podemos hacer bien poco con él.... Encenderlo, mirar cómo arranca, y poco más.... Me recuerda a mi primera vez delante de un 8088 con MS-DOS:

A:>

¡Jo! ¡Qué chulo!.... Voy a teclear....

A:>ayuda (intro)

¡Oño!.. Cuantas letras...Y todo en inglés.... ¿Comorrr? ¿Error?..... ¿Y ahora que hago?.....

¡Cómo hemos cambiado.....! ¿O no?

-->

Bueno, pues para poder hacer algo con nuestro server, vamos a ir configurándolo. Como he optado por una instalación sin las X instaladas, trabajaremos en modo consola continuamente. Así, para poder modificar archivos utilizaremos como editor vi o nano. Hay estupendos manuales de uso de los mismos en la web, no perderé el tiempo en hacer yo uno nuevo.

No obstante, y debido al miedo cerval que se apodera de algunos a eso de teclear (cuánto mal ha hecho el lado oscuro...), si alguien se siente perdido puede instalar las X de manera muy sencilla:

Iniciamos sesión en nuestro server como root y tecleamos:

• apt-get update
• apt-get install xorg
• apt-get install xfce4 ó apt-get install gnome ó apt-get install e17

Cerramos sesión y entramos con nuestro usuario normal y tecleamos startx. Ea, ya tenéis escritorio, y ahora instaláis synaptic, gedit, y todo lo que queráis, pero yo sigo con mi instalación en modo consola.

En el post anterior, Miguel me hacía un comentario que tenía que ver con lo que vamos a ver ahora. Me indicaba que él conseguía comunicarse con su server en red local, pero no desde el exterior (llámese playa, cibercafé, trabajo...). Bien, vamos a ver a qué puede ser debido eso.

-->

Como ya comentaba, nuestro servidor está en nuestra red local, con la IP que nos ha dado el router. Vamos a partir del siguiente escenario:

Router.

IP Pública: 74.125.230.247 (es la de google, pero me la prestan seguro si nadie les dice nada)
IP Privada: 10.14.100.1 (es mi rango local)

Server:

        IP: 10.14.100.53. Es la que me ha dado el router por DHCP.

Imaginemos que ya hemos conseguido acceder a nuestro servidor desde el trabajo. Nos hemos conectado a él porque sabemos la IP Pública y la IP del servidor (hablo a grandes rasgos). Mientras estamos en ello, Juanele Tricista, que no necesito decir en qué trabaja, realiza una maniobra en el centro de transformación sin poner a tierra el interruptor. Consecuencia: aparte del pepinazo que pega el interruptor, con el susto consecuente de la viejecita que pasaba por allí, se va la luz en tu casa, y en medio barrio. Cuando el pazguato de Juanele se da cuenta del error, aparte de comunicar a su central que él no ha hecho nada, armará de nuevo el interruptor, volviendo la luz a tu casa. Ya veis por donde voy, ¿no?

-->

El router arranca de nuevo. Y nuestro proveedor de internet tiene a bien darnos una IP que no se parece en nada a la que teníamos. Encima, el router tiene a bien darle una dirección IP distinta a nuestro server. Escenario final: Ya no podemos conectarnos a nuestro server desde el trabajo. A seguir jugando al buscaminas.....

Para evitar este escenario ...extremo... vamos a realizar una serie de pasos. El primero, es configurar nuestro server con una IP fija o estática en red local. Para ello, hacemos login como root. Lo primero, actualizar los paquetes (apt-get update). Si tecleamos ifconfig podremos ver como está configurada actualmente nuestra tarjeta de red.

-->

La configuración de la tarjeta de red está en el archivo /etc/network/interfaces. Modificando este archivo, configuramos la interfaz eth0 a la ip que hayamos determinado previamente. Yo le voy a poner la 10.14.100.100. Editamos el archivo: nano /etc/network/interfaces

Vemos como está configurada la interfaz eth0 por DHCP. Lo modificamos, dejándolo de la siguiente manera:

Esos son mis datos de red, cada uno debe poner los suyos. Guardamos cambios y cerramos.

Reiniciamos eth0 y verificamos que haya tomado los cambios:
ifdown eth0
ifup eth0

Y por último comprobamos que seguimos teniendo acceso a la web.

-->

Bueno, ya hemos solucionado la mitad del problema. Pero Juanele Tricista sigue por el barrio, así que vamos a resolver la segunda parte del problema, la IP pública. Os comentaba en el post anterior que aquellos que tengan la suerte de tener IP pública fija o estática, no tienen problema para localizar a su server en Internet. Pero lamentablemente en España eso no es lo habitual, así que vamos a utilizar un servicio que nos asigne un nombre de dominio de Internet a una IP publica dinámica (DDNS, ó Dinamic Domain Name Server).

-->

Hay varios servicios de este tipo, y, como vamos a lo barato, vamos a utilizar uno gratuito. Me he decantado por el servicio que da www.dnsdynamic.org. Hay más, yo he utilizado en otras ocasiones www.no-ip.compor ejemplo, así que la elección del servicio DDNS lo dejo a gusto del consumidor. Los pasos son muy sencillos.

Abrimos la dirección indicada y pulsamos sobre el botón SIGN UP (en nuestro ordenador, recordad que tenemos el server en modo consola).

Introducimos nuestra cuenta de correo, y validamos.

Nos enviará un correo de confirmación, con un enlace para activar el servicio.

-->

Click en el enlace, se activa la cuenta y pulsamos en login.

Ahora nos pregunta por el nombre del dominio que vamos a crear, y una extensión entre las que ofrece el servicio. En homenaje al blog donde estamos, he seleccionado cosillas.ftp21.net, para ver si está disponible.

Y como lo está, nos muestra nuestra dirección IP, y nos pide que introduzcamos la IP deseada para el dominio. Lógicamente, escribimos la que tenemos en ese momento, y pulsamos el botón ADD.

Bueno, pues ya está el dominio creado.

Si cerramos el explorador, podemos verificar que la cosa va bien, haciendo un ping a la dirección que acabamos de crear:

-->

Ya tenemos nuestro dominio, apuntando a la direccíon IP pública de nuestro router. ¡Que guay! ¡Esto pinta bien! ¡Voy a ser el próximo Mark Zuckemberg.....!

Pues va a ser que no..... ¿No os acordáis de Juanele Tricista? Sigue haciendo de las suyas..... ¿Que hacemos para que el servicio DDNS se entere cuando cambia nuestra dirección IP pública? Fácil: instalamos un cliente DDNS, que actualizará en el servicio de DNSDynamic la IP de nuestro router, relacionándola con la dirección que hemos creado (cosillas.ftp21.net).

En el server, logados como root, instalamos el paquete DDCLIENT. Tecleamos apt-get install ddclient

-->

El paquete se instala y nos muestra el configurador. Seleccionamos otro, Aceptar

Introducimos la dirección del servidor DDNS: www.dnsdynamic.org

Seleccionamos el protocolo de actualización: dyndns2

Introducimos el usuario con el que hacemos login en www.dnsdynamic.org, y su contraseña en la siguiente pantalla.

Aquí seleccionamos eth0, cada cual que marque el interface que utiliza.

Por último, el dominio que creamos anteriormente. En mi caso, cosillas.ftp21.net, y queda finalizado el cliente.

A pesar de estar configurado, vamos a teclear lo siguiente:

dpkg-reconfigure ddclient

Vamos aceptando las pantallas y le indicamos que no queremos conectar cada vez que inicie una conexión PPP, que queremos que se inicie ddclient como servicio (demonio) y el intervalo de actualización del mismo.

-->

-->

Edito: Las prisas son malas consejeras. Como yo tengo IP fija, ni siquiera probé el funcionamiento del cliente. Estos servicios ya los había utilizado anteriormente en el lado oscuro, y alli funciona bien.... peeeero.... Linux is diferent.... A ver, me he dado cuenta que si configuramos en el cliente la interfaz eth0, nos encontraremos con que nuestro dominio apunta.... a la dirección IP de nuestro server, la local. Pero no hay nada que no se pueda arreglar.
Editamos el archivo /etc/ddclient.conf, y modificamos la linea:

use=if, if=eth0
por
use=web, web=checkip.dyndns.org

Así, actualizará la dirección IP pública. Y ahora sí, tecleamos /etc/init.d/ddclient restart para arrancar el servicio con los últimos cambios. Ya puede cambiar la dirección IP pública de nuestro router, que cosillas.ftp21.net seguirá apuntando a ella.

-->

Ea, ya hemos conseguido tener localizado a nuestro servidor. Vamos a ver si nos podemos conectar a él. Vamos a utilizar para ello el protocolo SSH, o Secure Shell, de manera que empecemos a tomar conciencia de que las comunicaciones que hagamos con nuestro servidor deben ser seguras.

Instalamos SSH: apt-get install ssh

 


-->

Nos aseguramos que en el archivo de configuración etc/ssh/sshd_config, el valor de Protocol sea 2 , para evitar utilizar el antiguo protocolo, más inseguro, y reiniciamos (nano /etc/ssh/sshd_config , reboot)

Ahora vamos a utilizar nuestro equipo de sobremesa, que lo tenemos un poco abandonado con el dichoso server, para conectarnos a él. Abrimos una consola, y tecleamos

-->ssh -l root DIR.IP.NUESTRO.SERVER (dirección del la red local, es decir, en mi caso: ssh – l root 10.14.100.100). Aclaro: el parámetro -l root lo pongo para conectarme con el usuario root en el server. Si no lo pusiera, me pediría el password del usuario con el que estoy logado en mi estación de trabajo, y dicho usuario no existe en el server. Otra manera sería:

ssh root@10.14.100.100

-->

¿Qué significa todo el rollo que suelta la consola? ¿Escribo yes o no? Bueno, el protocolo SSH establece comunicación entre dos equipos de manera remota. Y remota quiere decir que puedo conectarme en mi red local a mi servidor, o conectarme a los servidores del FBI en Cuántico, Virginia. Esta comunicación se establecerá de una máquina a otra de manera segura, y para ello utiliza una serie de algoritmos de encriptación de la información que va y viene. Durante la instalación del servidor SSH en nuestro server, éste crea dos claves de encriptación, SSH2 RSA Key y SSH2 DSA Key. SSH usará de manera indistinta una u otra para encriptar la información. Asímismo, el servidor SSH generará las huellas digitales únicas (fingerprint) durante la instalación.

Así, lo que nos está diciendo el cliente es: Oye, este servidor que está en esa dirección IP yo no te puedo asegurar que sea el que buscas. Tiene una fingerprint de xxxxxxx. ¿Estás seguro que es éste?

- Hombreeeee, estamos en nuestra red local, tenemos el server aquí al ladito..... si no me puedo fiar de éste, apaga y vámonos.-

Vale, pero vamos a asegurarnos, ¿no?. Así aprendemos un poquito más...

Para saber si el servidor es realmente el nuestro, tenemos que conocer el fingerprint. Este se guarda en el directorio /etc/ssh

-->

Los archivos con extensión .pub son las claves públicas de nuestro servidor. Como veis, se han generado dos claves, la RSA y la DSA. En la pantalla de login de nuestro equipo, vemos que nos indica la RSA. Tecleamos en nuestro server: more ssh_host_rsa_key.pub

-->

Ups, vamos a pasarlo a hexadecimal, que así nos lo pregunta en la consola: Tecleamos ssh-keygen -l, y el archivo ssh_host_rsa_key.pub

Ahora si, y verificamos que el fingerprint RSA es el mismo que el que nos preguntaba en el terminal de nuestra estación de trabajo. Entonces, estamos seguros y podemos aceptar la conexión.

Y si todo ha ido bien, ya estamos conectados de manera remota a nuestro server.

-->

¿Cual seria el siguiente paso? Ya que nos hemos dado el curro de preparar nuestro dominio, vamos a hacer lo mismo de antes, pero a través de Internet. Ahora voy a utilizar en vez de la consola, el archifamoso y fantástico PUTTY. Así, veremos que nos podemos conectar a nuestro servidor desde nuestro ordenador del trabajo, que, para variar, tiene XP. Y este programa tiene una versión en el lado oscuro.

-->

Es el momento de presentaros a mi cuñado Fran DerBar. No, no es holandés, pero se llama Fran, y es dueño de un bar.... (qué malo es el alcohol a determinadas horas de la noche...). Me voy a conectar desde su ordenador en el bar a mi servidor. Pero hemos de tocar en nuestro router, porque puede ocurrirnos lo siguiente:

Je, je, je.... Ya os comenté que tengo un router Cisco. Me estoy conectando por consola via internet.... al router. ¿Por qué ocurre esto? En mi caso, es sencillo, el cisco acepta (porque así lo tengo configurado) conexiones a través del puerto 22, y como está antes que el server.... Con un router Conceptronic, 3Com, Dlink, Linksys....etc, no suele estar configurado, pero aún así debemos ir preparando nuestro router para los servicios que van a venir después.

-->

Llegados a este punto, es imposible que os diga lo que tenéis que hacer, ya que cada uno tendrá un router distinto, pero si os digo: abrir puertos para el emule.... ¿a que sabéis lo que quiero decir? Es tan sencillo como eso, indicarle al router que todas el tráfico entrante de internet por el puerto 22 se redirija a la IP de nuestro server, al puerto 22.

Y eso de los puertos ¿que es lo que es? Pufffff..... toca teoría.... Los puertos son utilizados por el protocolo TCP (Transmision Control Protocol) para identificar a las aplicaciones emisoras/receptoras. Dichas aplicaciones, a ambos lados de una comunicación establecida, tienen asociado dicho número de puerto. Es una numeración lógica que se establece en los equipos, no forma parte de la transmisión de los datos el paquete TCP. Así, el sistema operativo de mi server “escucha” en los puertos que dejemos abiertos y cuando recibe algún paquete para dicho puerto, se lo “pasa” a la aplicación que está configurada para dicho puerto. Ejemplo: en navegación web, el firefox utiliza el puerto 80 para mostrar paginas http, y el puerto 443 para páginas https.

Vale, pues ya que las conexiones entrantes por el puerto 22 a nuestro router las hemos redirigido a la IP de nuestro server, vamos a ver si funciona o no.

-->

et voilá....

Nota aclaratoria: el dominio cosillas.ftp21.net ha sido dado de baja en el momento de publicar este post.

En el próximo post terminaremos de configurar nuestro server y crearemos un ftp para ir empezando a darle uso.

To be continued.....