Servidor casero desde cero (3) – Gestión y acceso remoto

No hace falta decir que un servidor casero normalmente no tiene monitor. Es, dicho de forma «guay», un ordenador headless. Yo normalmente sólamente le conecto el monitor, como es lógico, durante el proceso de instalación inicial y a partir de ahi todas las tareas las realizo a través de SSH mediante cualquier ordenador conectado a la misma red local.

Por otros motivos también nos puede interesar acceder al servidor desde fuera de la red local, a través de Internet y para ello necesitaremos un servicio de gestión de IP dinámica como no-ip y dyndns. Voy a explicar rápidamente más o menos cómo funciona cada una de las dos cosas.

Gestión remota mediante SSH

El SSH, dicho de una forma vulgar es como poder estar en la consola de un ordenador, pero a través de la red. Es decir, desde un terminal en mi ordenador puedo realizar todo lo que haría como si estuviera usando una consola local en el servidor, mientras estén conectados a la misma red.

Sólo con estar conectados al mismo router o mismo switch, esos dos ordenadores ya suelen estar en la misma red así que para empezar a usar SSH sólo basta con instalar el paquete openssh-server en el servidor y openssh-client en el ordenador que hará de control remoto, aunque lo más normal es que ambos estén ya instalados por defecto.

Lo más normal es que nada más instalarse openssh-server en el servidor, el mismo servicio se ejecute tras la instalación, pero si no es así, se puede iniciar manualmente ejecutando lo siguiente como root:

/etc/init.d/ssh start

Una vez que esté el servicio SSH activo en el servidor, desde el cliente nos conectamos abriendo una consola y tecleando ssh seguido de la IP que tenga el servidor, por ejemplo:

ssh 192.168.1.105

Si el usuario que tenemos en el cliente no es el mismo con el que nos vamos a querer conectar en el servidor, tenemos que especificar, con qué usuario queremos conectarnos, ya que tenemos que introducir los datos reales de un usuario que exista en el servidor. Por ejemplo, si en el servidor tenemos un usuario llamado pepe, tendremos que conectarnos así:

ssh -l pepe 192.168.1.105

Normalmente el servicio SSH está configurado por defecto con unas opciones de seguridad aceptables y universales, pero éstas se pueden ajustar editando el archivo /etc/ssh/sshd_config.

Como digo, a través de SSH puedes hacer cualquier cosa que harías con la consola. Yo lo uso mucho para actualizar el sistema (usando APT), para instalar y configurar programas, para consultar el dmesg cuando conecto un hardware nuevo, etc… Es por eso también que normalmente instalo el sistema en el servidor con lo mínimo, luego instalo SSH y a partir de ahi, retiro el monitor y lo sigo haciendo todo cómodamente a través de SSH desde otro ordenador.

Acceso desde Internet al servidor

Dado que lo normal es que nuestra red local esté vertebrada con un router, solemos tener dos problemas principales a la hora de acceder a un ordenador de la red (en este caso el servidor) a través de Internet.

El primero es que, al menos en España es muy común tener IP dinámica (me refiero a la IP con la que estamos conectados a Internet) y esto dificulta mucho conectarse desde el exterior usando directamente dicha IP, ya que la misma cambia constantemente.

El segundo es que cuando se está usando un router, hay que configurar a qué IP local se dirigen las peticiones entrantes según el puerto del que procedan. Por defecto no se puede acceder directamente a ningún ordenador local si no está configurado el NAT en el router.

Usando un servidor DNS para IPs dinámicas

El primer problema queda solventado gracias a servicios como dyndns o no-ip. Dichos servicios, digamos, hacen el trabajo sucio por nosotros: nos ofrecen una dirección del tipo servidor.no-ip.org o servidor.dyndns.org de modo que siempre podemos acceder al servidor con esa misma dirección, y en nuestro servidor instalamos un software que detecta cada cambio de IP y se conecta a no-ip o dyndns y actualiza la configuración. De este modo por muchas veces que cambie nuestra IP, siempre podemos acceder al servidor con la misma dirección sin estar pendientes de nada.

Ambos servicios cuentan con un software de código abierto para Linux que está disponible en los repositorios de Debian mediante los paquetes noip2 y dyndns-client respectivamente. Yo sólo he usado no-ip (que funciona muy bien por cierto) pero ambos funcionan de forma parecida: te creas una cuenta en su página y luego, tras instalar el sofware en el servidor, lo configuras con los datos de acceso que usaste para crear la cuenta en el servicio.

En el caso de Debian al menos, tras instalar no-ip2 se ejecuta un asistente muy majo que te guía por todas las partes de la configuración que vas a necesitar, y te lo deja funcionando muy bien. Si más adelante quieres repetir ese asistente de configuración porque han cambiado tus datos de acceso o por cualquier razón, sólo tienes que ejecutar como root lo siguiente:

dpkg-reconfigure noip2

Tras este asistente, se ejecuta el servicio que monitoriza los cambios en la IP y actualiza la configuración en tu dirección no-ip o dyndns

Redireccionando los puertos en el router

El segundo problema también tiene fácil solución. No puedo explicar con detalles el proceso porque la configuración de cada router es totalmente distinta (recomiendo leer el manual correspondiente) pero sí explicaré que hay que configurar lo que se suele llamar NAT (Native Address Translation), que es lo que tienes que buscar en la configuración de tu router. En esa sección tienes que redirigir el puerto del servicio que vayas a usar a la IP del ordenador que haga de servidor. Por ejemplo si tienes un servicio web, tendrás que redirigir el puerto 80, si es un servidor web será el puerto 21, y así con el resto de servicios a los que quieras acceder externamente. Por supuesto, pueden ser varios simultáneamente.

Resumen

Así pues, una vez que hemos configurado un nombre en un servicio DNS, podemos acceder desde cualquier parte con la dirección nombre.no-ip.org o nombre.dynds.org. Una vez llegue la petición al router, éste sabrá que tiene que enviarla al servidor porque tiene correctamente configurado el puerto y la IP local.

Como última reflexión, no recomiendo en absoluto abrir en el router el puerto que usemos para SSH, que por defecto es el 22

El siguiente paso es configurar un servidor de vigilancia casero con activación/desactivación mediante mando a distancia y conexión GSM para alertas… ¡sin duda la cosa se pone interesante!

Previous Post Next Post

2 Comments

  • Reply Drizzt 19 junio, 2009 at 18:00

    También es válido:
    ssh pepe@192.168.1.105

    Pero en el proceso este hay una pega con las versiones castellanizadas de clientes SSH (sobre todo Solaris), y es que cuando accedes desde una máquina al servidor SSHD, el cliente te pide confirmación explicita para añadir el sha/dsa a su BBDD de confianza.

    Y las versiones en español (algunas Linux y sobre todo Solaris x86 comerciales -los Dual Opterons 2×2 que tanto gusta de colar SUN a entornos empersariales) te piden confirmar con «sí», sí con tilde y ni configurando el terminal desde que ejecutas el cliente ssh va (es decir, ni escribiendo «sí» en consola y que aparezca como tal).

    Al final ya te cabreas y pasas de la BBDD de servers confianza :
    ssh pepe@192.168.1.105 -o StrictHostKeyChecking=no
    Te añade la clave de 192.168.1.105 de forma permanente a $HOME/.ssh/known_host y no vuelve a dar guerra.

    Vamos que puedes tener tu servidor SSH correctamente configurado pero un día te toca acceder a él desde estas máquinas y te tocan la moral.
    Que toque hacer esto en Unices comerciales… ¬¬UUUUU

    «El ‘man’ os hará libres»

  • Reply Membris Khan 22 junio, 2009 at 00:04

    Lo de la castellanización también lo he sufrido yo con cfdisk, que no funcionaba ni copiando un «sí» desde el portapapeles al xterm grrrrr

    Menos mal que no sufriré tu problema porque al menos de momento, todos los ordenadores de la red vestirán Linux y más concretamente Debian.

    Ay el man, ese gran desconocido!

  • Responder a Membris Khan Cancel Reply

    Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.