Accede a tu LAN mediante un Bastión (Host)

Lo primero a comentar aquí es que probablemente todo lo que vaya a decir aquí esté ampliamente superado mediante tecnologías medianamente recientes como WireGuard o como no tan recientes OpenVPN pero no está de más familiarizarse con métodos más tradicionales y menos dependientes de software más complejo que el versátil SSH aunque en el caso de WireGuard este forma parte además del núcleo de Linux.

Este artículo sería una continuación a SSH (a brief introduction) donde se introdujeron los conceptos de ssh tunneling. Esta introducción la hicimos con idea de mostrar las capacidades de encriptado pero existen muchas más posibilidades.

Debo dar por hecho que el lector tiene conocimientos básicos de redes y sabe perfectamente que es una red local o LAN y un Router. En pleno 2026 gran multitud de hogares tienen contratado un servicio de Internet, respecto a las empresas esto es prácticamente obligatorio. En la pequeña y mediana empresa el diseño de la red apenas varía, tan solo cambia el tipo de equipos conectados tras el router, de uso doméstico en el caso del hogar medio, y de utilización profesional en el caso de las empresas.

Por supuesto existen muchas personas que a nivel particular construyen tras sus hogareños routers una red de servicios y/o equipos (algunos virtualizados) que no tienen nada que envidiar a las de muchas empresas, hablamos de los fanáticos de las HomeLabs que tanto están de moda, aunque tampoco es necesario tener todo un cluster de servidores para experimentar con la tecnología y para pensar en algún método para poder acceder a tus dispositivos desde fuera pero de manera segura. Contar con un único servidor en tu LAN, aunque sea un simple NAS puede justificar implementar un sistema de seguridad para protegerlo de conexiones no deseadas y encriptar las conexiones sí deseadas que reciba.

Así, cada vez son más las redes domésticas que se asemejan a lo siguiente:

La representación anterior podría haberse complicado aún más con los elementos IoT así como con alarmas o cámaras de seguridad que a su vez implementan sus propios sistemas de seguridad digital, sin perjuicio de que igualmente podrían ser reforzadas con lo que vamos a continuar diciendo.

Visto el dibujo, la mayoría de los elementos del diagrama está formados por elementos que serían demandantes de conexiones salientes, las cuales aunque se pueden filtrar por los motivos que sean no serán tradicionalmente un problema de nuestra red. Las que nos preocupan son aquellas partes en la que se produzcan las conexiones, a las que queramos conectarnos, pero donde queremos que sólo podamos conectar nosotros (o el que tenga nuestro permiso).

Por tanto, lo trascendental de cara a esta publicación son aquellas partes que pueden ser receptoras de conexiones, especialmente cuando somos precisamente nosotros los que deseamos que tales conexiones entrantes estén disponibles pero no para todos.

La primera vía de contención de conexiones es el firewall que no es más que un servicio analiza todas las conexiones que entran y salen del equipo donde está instalado, configurándose mediante reglas de filtrado que simplemente deciden si admiten o no admiten la conexión, o sí admitiéndola realizan cambios en las mismas incluso traduciendo las IP cuando estos tienen capacidades NAT. Los firewalls pueden actuar en las tres primeras capas del modelo OSI ya comentado, pero también en capas más altas, incluso la de aplicación.

Los propios routers, como puerta de entrada y de salida de nuestra red, implementan sus propias capacidades firewalls además de la obligada capacidad NAT. Estos routers tienen al menos dos interfaces de red conectadas una a la WAN (Internet) y otra a la LAN. Así a través de la interfaz de gestión de los routers deberá ser fácil llegar hasta aquellos apartados en los que se permite bloquear conexiones entrantes (reglas incoming) y conexiones salientes (reglas outgoing), si es que esta posibilidad existe.

La configuración recomendada de un router de Internet es bloquear todas las conexiones entrantes WAN y respecto a las salientes desde la LAN se suele permitir todo excepto lo expresamente prohibido donde por seguridad debe incluirse NetBIOS. Que las conexiones entrantes desde la Internet sean bloqueadas no impide que podamos hacer NAT para redirigirlas a algún otro equipo de la LAN.

Gracias al servicio NAT podemos permitir accesos desde el exterior simplemente mapeando puertos desde el router hasta las direcciones IP de los equipos dentro de la red local en la que realmente escuchan los servicios. No es necesario que los puertos sean los mismos, así por ejemplo podemos mapear el puerto 222 del router al puerto 22 de un servidor interno donde escucha el servidor SSH. De la misma manera podríamos actuar con cualquier otro servicio ofrecido dentro de la red, ya sea en el mismo servidor o en otros equipos ya sea físicos o virtuales.

Las propias capacidades NAT del router son el principal sistema de bloqueo de conexiones externas. Cualquier host desde el exterior únicamente puede, a priori, acceder al router. Haciendo un símil con un edificio, el router hace las funciones de hall de entrada, que comunica la puerta exterior con los accesos a los pisos. Desde ese hall es el portero quien se encarga de permitir la entrada y salida de personas, y cuando llega alguna persona preguntando por determinado inquilino, si tiene instrucciones de que ese inquilino no puede recibir visitas entonces no le permitirá la entrada, en caso contrario le indicará donde encontrarlo.

Cuando queremos proveer ciertos servicios desde el interior de nuestra LAN tenemos infinidad de opciones a utilizar usando tanto software libre como propietario. En cuanto a su acceso, una solución tradicional es la de implementar una zona desmilitarizada o DMZ dentro de tu red local. Con esta implementación tan sólo se permiten conexiones a través del router a un determinado equipo (o a varios) que será responsable de su propia seguridad lo que debe incluir que de ninguna manera deberían poder redirigir tráfico al resto de la red o no se cumpliría lo que una DMZ debe ser:

Aunque en la imagen dice acceso restringido básicamente estaríamos hablando de acceso prohibido sin perjuicio de las posibles necesidades puntuales que puedan surgir o uso de algún tipo de servicio de acceso remoto de escritorio a demanda como Teamviewer y compañía que realmente no representan conexiones entrantes sino salientes hacia quien nos va a asistir. Mismo caso sería los túneles SSH inversos a los que seguro termino dedicando otro artículo.

Continuando con el símil del edificio, la DMZ viene a ser una política en la en el edificio existen locales comerciales u oficinas, que reciben continuamente clientes y se encuentran colocadas en plantas diferenciadas del edificio, con una escalera propia y sin conexión directa con el resto de los pisos. La puerta para acceder a esa planta se abre libremente. Sin embargo la circulación hacia el resto de los pisos debe estar restringida únicamente a aquellos que habitan en ellos por lo que las medidas de seguridad deben tener en cuenta que únicamente sus vecinos pueden realmente comunicarse entre si. Quienes están en el piso de libre acceso son responsables de su propia seguridad, y estos locales comerciales normalmente estarán bien provistos de ella. Si algún inquilino de la zona segura quiere comunicarse con la DMZ podrá hacerlo desde el hall de entrada, como cualquier visitante del exterior.

Sin embargo, implementar esta política de seguridad nos obliga a alojar cualquier tipo de servicio dentro de la DMZ y ofrece poca flexibilidad. Utilizar NAT permite alojar algunos negocios en los pisos, pero en algunas ocasiones queremos que esos "servicios" estén sólo disponibles para gente de confianza. Y es que abrir los puertos los vuelve disponibles para todo el mundo, y a lo mejor no queremos eso.

Imaginemos que cuando cualquiera entra en nuestro edificio y pregunta por un negocio en particular el portero dice que desconoce donde está, pero si ese visitante pregunta por el vigilante de seguridad entonces el portero le indica donde encontrarlo. Cuando el visitante se identifica ante el vigilante y este ve que es personal autorizado, entonces este le permite ir a circular por todo el edificio, sin perjuicio de que algunas puertas pueden encontrarse cerradas.

A esta política de seguridad se la llama Bastion Host, y una implementación consiste en habilitar un servidor OpenSSH en nuestra red al que se le ha asignado una redirección NAT a su puerto de servicio SSH. Cuando un usuario puede conectar a ese servidor usando sus credenciales entonces puede construir un túnel a través de él para acceder a cualquier otro lugar visible desde ese servidor, incluyen especialmente a los equipos conectados a una misma red local.

Dicho todo ello veamos gráficamente una aproximación general de lo que estamos hablando:

Aunque el dibujo puede abrumar un poco en realidad todo es mucho más sencillo de lo que parece. Si volvemos a nuestro símil, el firewall externo sería el portero del edificio. El Bastion Host sería el guardia de seguridad ante el que debemos identificarnos, y el firewall interno sería el que impediría entrar en algunas puertas.

Notar además que se trata de un esquema general en el que se representan entidades donde ni mucho menos es necesario tener un superservidor como Bastion Host, es más, lo habitual es que sea el equipo menos potente de la red. En en nuestro ejemplo en el que únicamente vamos a necesitar que ese equipo aloje un servidor OpenSSH.

El firewall externo puede referirse perfectamente al router de Internet en el que bloqueamos todas las conexiones entrantes excepto la SSH a la que hacemos NAT al Bastion Host, pero también podía referirse al del propio equipo Bastion, o un equipo dedicado a ello. En cuanto al firewall interno puede ser un equipo dedicado, el firewall del propio Bastion o los firewalls de cada equipo. En realidad hablamos de entidades más que dispositivos.

Preparando y eligiendo nuestro Bastion Host

Técnicamente hablando, un Bastion Host no debe necesitar excesiva potencia de cómputo o recursos una vez que, con el objetivo de comprometer el mínimo posible la seguridad de la red, el equipo que asuma este rol debería correr los programas estrictamente necesarios para hacer esta función (kernel, drivers de red, firewall, SSH server) y poco más.

Si pensamos en una red doméstica 2.0, o lo que viene ser un HomeLab, siempre hay algo a tener en cuenta: El consumo eléctrico de nuestros equipos. Y es que normalmente no tendremos la suerte de que la factura de la luz no sea un problema. Si hay un equipo de la red que siempre debe estar conectado este debe ser el Bastion Host y es por ello que hay que valorar como buena opción el seleccionar un ordenador de placa única o SBC medianamente potente. En mi caso va a ser una Raspberry Pi 4. Si el dinero no es tu problema y te da igual la huella de carbono, entonces siéntete libre de usar el equipo que quieras.

Vamos a ver un dibujo más aproximado de lo que realmente estamos describiendo:

El esquema es extremadamente sencillo y para gestionar el tráfico seguro desde internet hasta los servicios de la red interna tan sólo es necesario un cliente SSH, además del servidor en la Raspberry Pi, pero ¿qué sistema *NIX que se precie no lo corre en su configuración más básica?. En nuestra configuración, donde el único usuario probablemente seamos nosotros, realmente no necesitamos ningún firewall interno.

Llegados a este punto si vas a utilizar una Raspberry Pi y la acabas de sacar de la caja te tocará instalarle un sistema operativo siguiendo cualquiera de los muchos tutoriales que gente altruista ha colgado en internet. A la hora de buscar en el momento de escribir estas palabras este es el primer resultado de mi búsqueda Paso a Paso: Instalar y Configurar Raspberry Pi OS y es tan buen tutorial como cualquier otro. No olvidar activar SSH cuando configures la instalación, así como la red inalámbrica si es la que vas a utilizar para conectarla a tu red local.

La instalación inicial ya nos deja listo el equipo para usarlo como Bastion Host no necesitando configurar firewall en el propio equipo una vez que tan sólo vamos a permitir que pase la conexión al puerto SSH a través de nuestro router mediante una directiva NAT al efecto, y así mismo no tendremos muchos más servicios corriendo en el equipo. Hecho esto, y tan sólo haciendo uso de las credenciales del usuario configurado en la Raspberry Pi podremos tunelar desde el ordenador remoto hasta cualquier equipo y cualquier puerto visible desde nuestro recién creado Bastion Host. Por supuesto si queremos restringir de alguna manera el tráfico tocará establecer la configuración de seguridad correspondiente a cada caso.

Recordemos que estamos calificando como firewall a nuestro router de internet. Un firewall es un concepto y no necesariamente un software determinado. Es cualquier cosa que dentro de una red impida, limite o altere conexiones en función de ciertas reglas.

No obstante, la configuración inicial nos deja una configuración de red basada en DHCP lo que puede complicarnos la vida respecto al NAT que debe establecer una regla de redirección del puerto SSH hasta una dirección IP determinada. He aquí un tutorial para establecer una dirección fija Asignar una dirección IP fija a Raspberry Pi.

Otra posibilidad para que la Raspberry Pi adquiera siempre la misma IP es configurarlo en el router, si es que esa opción está disponible. En la mayoría de los casos el router añadirá el dispositivo a una lista de asignaciones recientes DHCP a las que se podrá asignar una IP reservada para ellos. En la siguiente imagen puede observarse el caso de mi router livebox:

Túnel, túnel, túnel

Instalado nuestro Bastión y con nuestras credenciales listas podemos tunelar mediante TPC (o Unix Socket) a cualquier puerto de cualquier dispositivo visible desde nuestra Raspberry Pi, no siendo por tanto necesario que sea visible desde el exterior. Para hacer esto necesitamos hacer un túnel local de los que ya vimos en SSH (a brief introduction).

En ese artículo conocimos que el punto de entrada siempre se abría en el equipo que creaba el túnel, el que ejecutaba el cliente de OpenSSH, y únicamente podíamos decidir la dirección IP de las que estuvieran disponibles localmente. Sin embargo el punto de salida puede ser cualquier dirección de red, tan sólo que exige que la misma sea visible desde el equipo que ejecuta el servidor OpenSSH.

Vamos a formular un ejemplo. Estás conectado a una red pública fuera de tu hogar, pero sabes que la IP del router de tu casa es la 201.45.67.89. Así mismo tienes en tu LAN una Raspberry Pi corriendo un servidor OpenSSH en el puerto 22. Tu router tiene una entrada NAT por la que el puerto 2000 de tu router se traduce al 22 de tu Raspberry. La IP de la Raspberry realmente no necesitamos saberla para acceder a ella ya que con el siguiente comando probaremos que se puede acceder vía SSH con el nombre de usuario manuel:

$ ssh manuel@201.45.67.89 -p 2000

Comprobado que se puede conectar y que tenemos credenciales podríamos establecer un túnel desde nuestro equipo remoto a un servidor web dentro de la LAN que pudiera tener la IP 192.168.1.200. Por ejemplo así:

$ ssh -L 8080:192.168.1.200:80 manuel@201.45.67.89 -p 2000 -N

Con esto ya podríamos acceder al servidor web a través de la dirección http:\\127.0.0.1:8080 a pesar de que el servidor web de nuestra LAN es invisible para nosotros.

Así podemos tunelar hasta cualquier equipo de la red y cualquier puerto de estos siempre y cuando las conexiones hacia los mismos no estén bloqueadas para el Bastión.

De forma similar pueden utilizarse túneles remotos pero ya no estaríamos hablando de la misma estructura ya que sería el servidor web el que debería construir el túnel hacia el equipo remoto, donde debería estar corriendo un servidor OpenSSH.