En las últimas semanas he estado realizando una serie de cambios bastante importante en mi sistema informático. Desde hace muchos años tengo desplegado en casa un servidor que históricamente ha contenido mi sitio web, pero que con el paso del tiempo ha ido ganando en funcionalidades: domótica, servicio de mensajería, automatización, almacenamiento, VPN, streaming de vídeo… Todo empezó en la Universidad, con unas prácticas de alguna asignatura que ni siquiera recuerdo, pero ha persistido con el paso del tiempo.
En un momento dado tuve una serie de sistemas aislados que complementaban al servidor: un Mini-ITX, un par de Raspberry Pi, una Asus Tinker Board, una NAS… Pero con el paso del tiempo fui simplificando. Un paso trascendental fue la consolidación de las máquinas físicas separadas en un único servidor de virtualización. Para ello escogí realizar un despliegue de ProxMox, virtualización basada en KVM, pero que proporcionaba una interfaz de usuario vía web bastante amigable, lo que hacía la administración del entorno fuera sencilla. Para ello utilicé un viejo PC de oficina con un procesador Intel y 4 GB de RAM. Todo bastante ajustado para contener tres máquinas virtuales: un frontal web NGINX que además desplegaba un servidor MQTT y VPN, un backend con el servidor web WordPress, securizado por el frontal antes comentado, y una máquina separada para el entorno de domótica. Durante años ha funcionado bien, pero hace unos meses el servidor, ya veterano cuando lo desplegué, empezó a presentar fallos hardware. El principal fue que se estropeó uno de los módulos de RAM, quedando reducida la cantidad disponible a 3 MB. Además, presentaba fallos de encendido en caso de que se fuera la luz, lo que hacía que la recuperación del sistema fuera bastante complicado.
Ante ello, decidí renovar el hardware, para lo que me puse a mirar precio de módulos RAM para añadirle el módulo faltante al PC, y también precios de PCs nuevos. Tanto lo uno como lo otro tenían precios elevados (la RAM por tener que adquirirla a través de Ebay y sitios así), y el PC nuevo por el hecho de comprarlo nuevo. Y en ello andaba cuando se me ocurrió una idea disparatada:
Hacerme con un servidor. Uno de verdad. No un viejo PC reconvertido. Un ser-vi-dor. Y resultó que la idea no era tan disparatada. Encontré un servidor HP DL360p Gen8 con doble fuente de alimentación, dos procesadores de 12 núcleos cada uno, 96 GB de RAM, 4 discos de 2 TB a 7200 RPM y controladora RAID, 4 puertos de red a giga, y un año de garantía por la ridícula cifra de 100€. Resultaba que la idea no era tan disparatada. Así que me hice con él. Pero es un servidor, claro. Está optimizado para el rendimiento. Y eso suele tener algunos problemillas cuando lo metes en una casa. Y no es el menor de ellos el que puede ponerse a sonar como un MIG 21 despegando.
Estas semanas he estado lidiando para poner el servidor de manera funcional, adaptarlo a un uso doméstico, volver a instalar un entorno de virtualización, y migrar las máquinas desde el viejo servidor. Por el camino he aprendido una serie de cosas bastante interesantes, y creo que vale la pena recopilarlas por si a alguien más le resultan interesantes, así que espero escribir unos cuantos artículos al respecto.
Etiquetas: domótica, home assistant, hp dl360p gen8, mqtt, nginx, proxmox, virtualización, vpn
Desde hace algunos días vengo experimentando problemas con mi conexión doméstica a Internet. Esto es un problema bastante molesto para mí, porque hago uso de una serie de servicios en un servidor casero que publico hacia el exterior. El principal de ellos es este sitio web, pero hay algunos adicionales, como algunos servicios de domótica y una conexión VPN para acceder de manera segura desde el exterior. Hasta ahora, venía publicándolo todo de manera directa, ya que disponía de una IPv4 con mi conexión, pero desde la semana pasada han pasado a darme acceso a Internet detrás de un CG-NAT. Esto implica que ya no dispongo de una IPv4 propia, sino que salgo a través de una NAT del operador, por lo que no es posible acceder de manera remota a dichos servicios.
Mientras me lo solucionan, he optado por poner en pie un mecanismo para poder seguir publicando servicios, basado en el uso de un pequeño servidor público que se encarga de redireccionar los servicios hacia mi sistema detrás del CG-NAT. Y para ello, hago uso de una plataforma que permite establecer redes securizadas mediante una combinación de SG-NAT y VPN, llamada ZeroTier. La gracia de ZeroTier es que el entorno funciona como un concentrador de VPNs, de tal manera que entre los clientes que necesitemos conectar se establece una red privada, con lo que es posible dotar de conectividad entre ellos a los mismos, tan sólo instalando un agente del propio ZeroTier entre ellos, y establecer la visibilidad oportuna entre nodos. Haciendo que el servidor publicado en Internet sea uno de los nodos, puedo proporcionar servicios utilizándolo de pasarela pública.
La segunda pata del asunto es conseguir este servidor frontal público, y hacer que funcione de pasarela. En mi caso, he optado por hacer uso de Oracle Cloud Infrastructure, donde se puede desplegar de manera gratuita un servidor basado en Linux. Y una vez que me he hecho con este servidor, he montado la pasarela con un servidor NGINX, debido a que me permite redireccionar tanto servicios publicados por TCP (mi servidor web y mi servidor MQTT) como UDP (mi servidor VPN), con lo que me ahorro tener que andar instalando y gestionando servicios duplicados en este frontal. Sencillo y eficiente. El diagrama general de cómo ha quedado el entorno es el siguiente:
La configuración a nivel interno sí que tiene algunos puntos a tener en cuenta:
stream {
upstream web_server {
server IP_PRIVADA_REMOTA_ZEROTIER:443;
}server {
listen 443;
ssl_preread on;
proxy_pass web_server;
}upstream mqtt_server {
server IP_PRIVADA_REMOTA_ZEROTIER:1883;
}
server {
listen 1883;
proxy_pass mqtt_server;
proxy_connect_timeout 1s;
}upstream vpn_server {
server IP_PRIVADA_REMOTA_ZEROTIER:1194;
}
server {
listen 1194 udp;
proxy_pass vpn_server;
}}
stream {
upstream vpn_server {
server IP_SERVIDOR_LOCAL_VPN:1194;
}
server {
listen 1194 udp;
proxy_pass vpn_server;
}}
En realidad, me gusta tanto cómo ha quedado configurado, que es posible que lo deje así incluso cuando se solucione el tema del CG-NAT, ya que añade una capa extra de seguridad y disponibilidad a mis sistemas.
Referencias:
How to bypass CGNAT and expose your server to the internet using ZeroTier, a VPS and NGINX
Bypassing a CGNAT with Wireguard (Especialmente útil para la parte de configuración del entorno en Oracle Cloud)
How to set nginx reverse proxy to an SSL site without certificate?
Etiquetas: cg-nat, iot, mqtt, nginx, oracle cloud, vpn, vps, wordpress, zerotier
La configuración por defecto de OpenVPN permite acceder sólo al equipo servidor de VPN cuando estableces la conexión desde el cliente. Sin embargo, es posible extender el acceso al resto de equipos de la red local de dicho servidor, en caso de necesitar acceso a otras máquinas. La receta es la siguiente:
Referencias: