Hardening de homelab con VLAN: guía completa de seguridad en casa

Informatec Digital » Recursos » Hardening de homelab con VLAN: guía completa de seguridad en casa

Si tienes un homelab con un puñado de cacharros (NAS, miniPCs, Raspberry, cámaras, domótica, etc.) y todo está conectado en el mismo rango de red, tu casa es, a nivel digital, un campo abierto para movimientos laterales y ataques tontos. No hace falta ser una gran empresa para que te escaneen puertos, te revienten una contraseña floja o un cacharro IoT quede expuesto a un fallo de seguridad.

La idea de este artículo es que puedas montar, paso a paso y con cabeza, una red doméstica segmentada con VLANs, firewall y buenas prácticas de hardening, para que tus servicios caseros funcionen igual de bien, pero con mucho más control, menos sustos y una superficie de ataque bastante más pequeña. Vamos a combinar lo mejor de varios enfoques: pfSense/OPNsense, Unifi, Zero Trust (Tailscale, Cloudflare Tunnel), Proxmox, Kubernetes ligero, Pi-hole, Home Assistant, etc.

Por qué tu homelab necesita segmentación y hardening ya

En una red “plana” clásica, tipo 192.168.1.0/24 con todo metido allí, cualquier dispositivo puede ver y, en muchos casos, hablar con todos los demás. Si una bombilla, una TV o un enchufe “listo” se ve comprometido, el atacante puede intentar saltar a tu NAS, tu PC personal, el hypervisor de Proxmox o el servidor donde guardas copias de seguridad. No hace falta un ataque muy sofisticado; basta con un fallo de firmware que nadie parchea.

Además, mezclar todo en la misma red hace que el tráfico de descubrimiento (broadcast, multicast, mDNS, etc.) se descontrole. Eso genera ruido, complica el diagnóstico de problemas y, encima, da demasiada información sobre qué tienes, qué puertos usas y qué servicios corren en tu LAN. La segmentación con VLANs ataca justo ese problema: separar dispositivos por función y nivel de confianza.

Piensa en tu homelab como un pequeño centro de datos: tienes servicios críticos (DNS, VPN, almacenamiento), servicios públicos (reverse proxy, aplicaciones expuestas por túneles), dispositivos poco fiables (IoT, invitados, consolas de los niños) y tu equipo personal. Cada grupo debería estar en su “carril” y sólo poder hablar con los demás mediante reglas de firewall muy concretas y justificadas.

VLANs en el homelab: conceptos que sí vas a usar

Una VLAN no es magia: es simplemente un dominio de broadcast separado en la capa 2. Normalmente se asocia 1 VLAN = 1 subred IP, pero en realidad son conceptos distintos. La VLAN define cómo se separan los frames Ethernet; la subred, cómo se enruta el tráfico en la capa 3. Lo importante para ti es que los dispositivos de una VLAN no ven los broadcasts de otra, y sólo se comunican entre sí si interviene un router o firewall.

La separación se consigue con etiquetas 802.1Q (VID, de 1 a 4095) que los switches insertan en los paquetes. Un puerto puede trabajar de dos formas básicas: como puerto de acceso (access), donde el tráfico sale/entra sin etiquetar y todo pertenece a una única VLAN, o como puerto troncal (trunk), donde un mismo cable transporta varias VLAN etiquetadas a la vez hacia un router, otro switch, un AP o un hypervisor.

El famoso PVID o VLAN nativa define qué VLAN se asigna al tráfico que entra sin etiqueta en un puerto. Cada fabricante lo enseña distinto en la interfaz web (PVID, VLAN de acceso, Native VLAN…), pero la idea es la misma: el switch decide a qué VLAN pertenece un frame sin tag y, al sacarlo por un puerto de acceso, normalmente quita la etiqueta para que el dispositivo final vea “Ethernet normal” y no tenga que saber nada de VLANs.

En un homelab típico vas a tener, al menos, un enlace troncal entre tu firewall/router (pfSense, OPNsense, Unifi, OpenWrt…) y tu switch principal, y desde ahí puertos de acceso para PCs, TVs, consolas, cámaras, etc. Además, si usas Proxmox o un host de virtualización, es muy habitual configurar un enlace troncal hacia el hypervisor y dejar que las VMs o contenedores etiqueten su tráfico directamente, usando bridges tipo vmbr0 + VLAN tags.

Diseño práctico de VLANs para un homelab moderno

Antes de abrir el panel del switch como un poseso, coge papel (o un editor de texto) y define qué redes quieres y para qué. Un esquema razonable, que agrupa lo que se ve en muchas configuraciones reales, podría ser algo así, adaptando rangos IP y números de VLAN a tu gusto:

• Red “Default” o Doméstica: donde viven los dispositivos personales de la familia (móviles, portátiles, sobremesas). Es la red “de confianza” y normalmente la que tendrá un permiso algo más laxo para salir a Internet.
• VLAN Invitados: pensada para visitas. Sólo Internet, sin acceso al resto de rangos privados, con aislamiento entre clientes si el AP lo permite.
• VLAN IoT: para bombillas, enchufes, altavoces, Smart TV, termostatos, robots aspirador, etc. Tráfico muy limitado hacia dentro y controlado hacia fuera.
• VLAN Homelab / Servicios: donde residen tus VMs, contenedores, NAS, Home Assistant, bases de datos, reverse proxies, etc. Suele comunicarse con IoT y Default, pero de forma muy controlada.
• VLAN “Secure” o VPN: segmento en el que todo el tráfico hacia Internet sale por un túnel VPN permanente (por ejemplo, Proton VPN o similar), sin que el dispositivo tenga que instalar un cliente.
• DMZ: opcional pero muy recomendable para servicios potencialmente expuestos (reverse proxy, servidores web, VPNs, etc.), tratándolos como si fueran “semi-confiables” y sin puente directo al resto de redes internas.

Una forma clara de organizar direcciones privadas es usar algo como 10.10.X.0/24 para cada VLAN y mantener una hoja con los rangos, nombres y propósitos. Por ejemplo: 10.10.10.0/24 Default, 10.10.20.0/24 IoT, 10.10.30.0/24 Invitados, 10.10.40.0/24 Homelab, 10.10.50.0/24 Secure. Con esto, tus reglas de firewall y tus reservas DHCP serán mucho más fáciles de mantener en el tiempo.

Si utilizas Unifi o soluciones similares, es habitual mapear cada VLAN a una red en el controlador y, a su vez, vincular cada red a un SSID concreto. Así, al elegir el WiFi “Casa”, “IoT”, “Invitados” o “VPN”, automáticamente el dispositivo cae en la VLAN correcta y hereda las políticas de firewall y acceso que hayas definido para ese segmento.

Elegir hardware y software para manejar VLANs y routing

En cuanto al switch, con que soporte 802.1Q y te deje configurar VLAN tagging, trunks y PVIDs vas servido. La diferencia gorda está en si el equipo sólo hace switching capa 2, o si hace también routing capa 3 a velocidad de línea. Muchos switches “económicos” pueden etiquetar y reenviar frames a gran velocidad, pero cuando les pides que roten tráfico entre VLANs lo derivan a la CPU y se desploman a unos pocos cientos de Mbps.

Si quieres simplificar, lo más habitual en un homelab es dejar el routing entre VLANs al firewall/router principal (pfSense, OPNsense, Unifi Security Gateway, Dream Machine, OpenWrt en un router decente, etc.) y usar los switches sólo para la capa 2. Si tu tráfico interno es muy alto (copias entre cabinas, clusters de virtualización, backups gordos), quizá te compense un switch L3 con offload de routing por hardware, pero para la mayoría de casas no es imprescindible.

En el plano de software, hay tres grandes caminos:

• OpenWrt en routers modestos para empezar, con capacidad de etiquetar puertos, crear varias redes y aplicar reglas básicas de firewall.
• pfSense u OPNsense en una máquina x86 (bare metal o VM) si quieres reglas avanzadas, GeoIP, IPS/IDS, VPNs potentes, alta disponibilidad con CARP, etc.
• Unifi (Dream Machine, Dream Router, etc.) si prefieres un entorno integrado con APs y switches gestionados desde el mismo controlador, con una curva de aprendizaje algo más amable.

Para el hypervisor, Proxmox brilla precisamente en redes complejas: basta con crear bridges asociados a las NIC físicas (por ejemplo vmbr0 sobre enp1s0), marcar ese puerto del switch como troncal y dejar que cada VM o contenedor etiquete con el VLAN ID que necesite. Esto permite que un mismo servidor forme parte de varias VLANs a la vez y actúe, por ejemplo, como host de servicios de homelab accesibles desde Default e IoT sin montar inventos raros en los switches.

De la teoría a la práctica: creación y prueba de VLANs

Una vez decidido el diseño, en el switch defines cada VLAN con su VID y un nombre descriptivo. Después marcas los puertos que conectan con el router/firewall, con otros switches y con Proxmox como troncales, permitiendo las VLANs que quieras transportar. En esos puertos, es mejor evitar usar VLAN nativa distinta en cada extremo para no tener fugas de tráfico sin etiquetar o comportamientos raros.

Los puertos a los que vas a conectar dispositivos “tontos” (TV, consola, PC sin soporte de VLANs, cámaras) los dejas como puertos de acceso: una sola VLAN sin etiquetar, con el PVID correspondiente. Así, ese equipo siempre caerá en la red que tú hayas decidido, sin que pueda “escaparse” a otra por error de configuración.

En el firewall/router, creas una interfaz lógica por cada tag que atraviese la tarjeta de red conectada al switch. pfSense y OPNsense, por ejemplo, dejan crear interfaces VLAN sobre una NIC física, y a cada interfaz le asignas IP, rango DHCP, DNS, descripción y, lo más importante, sus reglas de firewall independientes. Esas reglas por interfaz son la clave del aislamiento.

Cuando lo tengas configurado, toca probar: enchufa un portátil a un puerto de acceso de IoT, mira qué IP recibe, comprueba qué gateway y DNS ve, y verifica que no puede hacer ping a la subred Default ni a la de Homelab, pero que sí resuelve dominios públicos y sale a Internet (si es lo que quieres). Repite ejercicios similares para Invitados, Homelab y Secure hasta que te asegures de que cada red se comporta como pretendías.

Firewall y reglas para cortar el movimiento lateral

El enfoque de base que mejor funciona es el de denegar por defecto y sólo permitir lo necesario. Es decir, en cada VLAN creas una regla inicial que permite tráfico “establecido/relacionado” (para dejar pasar respuestas a conexiones iniciadas desde dentro) y, después, niegas el tráfico hacia otras redes privadas (tipos RFC1918) salvo las excepciones justificadas.

Una técnica cómoda es crear un grupo de IPs que contenga todos tus bloques privados (por ejemplo 192.168.0.0/16, 10.0.0.0/8, 172.16.0.0/12) y referenciarlo en las reglas. Así, una regla que bloquee “IoT → PrivateNetworks” corta de un plumazo que las bombillas y cacharros intenten hablar con tu NAS o tu portátil, dejando sólo abierto el camino hacia Internet y, si lo necesitas, hacia algún servicio muy concreto del homelab.

En la red Default puedes permitir “LAN a cualquier sitio” (internet + otras VLANs) pero es buena idea seguir limitando qué puede acceder a la DMZ o a ciertos servidores sensibles. En Invitados, en cambio, lo normal es bloquear todo acceso a rangos privados y mantener únicamente salida a Internet. Si el AP soporta aislamiento entre clientes, actívalo para que los móviles de tus visitas ni siquiera se vean entre sí.

Para la relación entre Homelab e IoT, un patrón típico es permitir que un único host (por ejemplo, el contenedor o VM de Home Assistant) pueda llegar a ciertos dispositivos IoT en puertos específicos (puerto de API, puerto de control), pero no al revés. Esto se implementa con una regla tipo “HomelabHost → IP_IoT:puerto” permitida y, a continuación, un bloqueo general de IoT hacia Homelab y Default salvo tráfico establecido.

Hacer que multicast, mDNS y compañía no sean un infierno

En cuanto empiezas a separar redes, te das cuenta de que cosas como AirPlay, Chromecast o algunas impresoras “desaparecen”. No es un bug: muchos mecanismos de descubrimiento usan broadcast o multicast y, por diseño, no saltan entre VLANs. Para que sigan funcionando, necesitas ser selectivo con qué tráfico de descubrimiento dejas pasar.

Lo habitual es activar IGMP Snooping en los switches para limitar el multicast sólo a los puertos donde haya clientes interesados. Luego, en el router/controlador, habilitas un relay de mDNS/Bonjour o un servicio equivalente, diciendo explícitamente entre qué VLANs quieres que se reenvíen anuncios (por ejemplo, entre Default y IoT, o entre Default y Homelab).

En Unifi, además, puede hacer falta crear reglas LAN-IN que permitan el puerto y el tipo de tráfico de mDNS, o ajustar perfiles de multicast para cada SSID. Conviene ir con calma: habilita el relay sólo entre los segmentos que realmente necesitan verse y comprueba que no se cuela más información de la cuenta entre redes que pretendías aislar.

Hay dispositivos, como Sonos, que se llevan regular con las VLANs y pueden dar muchos dolores de cabeza aunque técnicamente haya relays configurados. Mucha gente acaba dejándolos en la red Default (o en una VLAN específica de multimedia) y aceptando que esa parte no va a estar tan segmentada a cambio de que todo funcione sin pelearse con el firmware del fabricante.

Gestión segura: MFA, SSH con llaves y Zero Trust

Tu firewall, tus hosts Proxmox, los NAS y los servicios de administración son “las llaves del reino”. No vale dejar un usuario root con contraseña simple accesible desde cualquier sitio. Lo sensato es crear una cuenta de administración específica para el panel web del firewall, deshabilitar el acceso directo de root y activar siempre doble factor (TOTP, por ejemplo, en OPNsense).

Además, es muy buena idea limitar el acceso a esas consolas de gestión sólo a una IP o subred muy concreta dentro de la VLAN de dispositivos de confianza (por ejemplo, a tu sobremesa o portátil principal). De este modo, si alguien consigue entrar en otra red o comprometer un cacharro IoT, no tendrá ni el panel del firewall ni la interfaz de administración del hypervisor a tiro.

Para el acceso por SSH a servidores y VMs, lo ideal es desactivar por completo la autenticación por contraseña y usar sólo claves públicas. Puedes ir más allá y meter un segundo factor con soluciones tipo Duo: aunque alguien robe tu clave privada, el intento de login genera una aprobación en tu móvil y, si no la autorizas, la conexión se rechaza.

De cara al acceso remoto, la consigna es clara: dejar de abrir puertos directos (80, 443, 22…) en el router. En su lugar, apóyate en soluciones Zero Trust como Tailscale (VPN mesh apoyada en WireGuard), Cloudflare Tunnel o Twingate. Estas herramientas permiten exponer servicios internos de forma autenticada y cifrada sin tener que publicar tu IP o tus puertos en Internet. Tus apps web, paneles y SSH pasan a estar accesibles sólo tras autenticación previa y políticas de acceso finas.

Endurecer contenedores, sistemas y servicios

Los contenedores dan una falsa sensación de seguridad: están aislados, sí, pero si corres todo en modo privilegiado, compartiendo volúmenes de escritura por todas partes y con imágenes sin mantenimiento, acabas igual de expuesto que con servicios instalados directamente en el host. La base es usar imágenes oficiales o muy reputadas, actualizar con regularidad y evitar el flag privileged salvo casos muy estudiados.

Siempre que puedas, monta volúmenes en modo lectura para datos estáticos, separa configuraciones de datos y limita las capacidades del contenedor a lo imprescindible. Comprueba los permisos de los sockets Docker y no expongas paneles sensibles como Portainer directamente a Internet; colócalos detrás de un reverse proxy seguro, con autenticación adicional, o protégelos bajo Tailscale / Cloudflare Tunnel.

En los sistemas base (Raspberry, miniPCs, VMs Linux) aplica la higiene mínima: cambiar contraseñas por defecto, activar actualizaciones regulares, deshabilitar servicios que no uses, configurar UFW o firewall equivalente con política de denegar por defecto y abrir sólo lo que haga falta. Para servicios muy atacados como SSH, un Fail2Ban o herramientas modernas tipo CrowdSec ayudan a bloquear intentos de fuerza bruta.

En cuanto al cifrado de comunicaciones, ya no tiene sentido servir nada en HTTP plano, ni siquiera dentro de la LAN. Reverse proxies como Caddy, Nginx Proxy Manager o Traefik facilitan el uso de certificados TLS (Let’s Encrypt, etc.) y permiten añadir una capa extra de autenticación, rate limiting, cabeceras de seguridad y demás, tanto para tráfico interno como para el que pase por túneles Zero Trust.

DNS, Pi-hole y bloqueo de “listas negras” de DoH

Un punto clave para la privacidad y el control de tu red es gestionar tú mismo el DNS. Pi-hole (o AdGuard Home) desplegado de forma redundante te permite bloquear publicidad, telemetría y dominios sospechosos a nivel de red, sin tener que configurar extensiones de navegador en todos los dispositivos. Eso sí, necesitas montar la infraestructura para que sea difícil de tumbar y difícil de saltarse.

En cuanto al “hardening” DNS, la idea es que todos los dispositivos consulten exclusivamente a tus servidores Pi-hole y que no puedan irse alegremente a 1.1.1.1, 8.8.8.8 o a direcciones de DNS-over-HTTPS públicas. Para quienes se empeñan en ignorar el DNS de DHCP, se pueden crear grupos de IP que contengan las direcciones de los grandes proveedores de DNS y DoH públicos (Cloudflare, Google, Quad9, etc.) y escribir reglas de firewall que dejen salir peticiones DNS sólo si vienen de tus Pi-hole y las bloqueen para el resto.

En la práctica, se suelen definir perfiles de grupo tipo “Servidores Pi-hole” y puertos “DNS” y “TLS-DoH”. Luego se añaden reglas de salida que permiten a Pi-hole hablar con Internet en esos puertos, y justo debajo reglas que descartan cualquier intento de usar esos mismos puertos desde otras IP de la LAN. Con eso, quien intente usar DNS propios se quedará sin resolución y “aprenderá” a respetar tu configuración.

Para que Pi-hole sea resiliente, es buena idea alojar las instancias en dispositivos diferentes (por ejemplo, un contenedor en NAS, otro en Proxmox, otro en una Raspi con SSD) y configurar DHCP para entregar varias IP de DNS a los clientes. Así, la caída de un nodo no te deja sin Internet, y el servicio sigue funcionando mientras investigas qué ha pasado.

Zero Trust y accesos remotos con Cloudflare Tunnel y Tailscale

En lugar de abrir puentes directos a tu casa, puedes jugar con un combinado muy potente: Cloudflare Zero Trust para exponer servicios web seleccionados (con identidades, políticas y auditoría) y Tailscale para acceder por VPN mesh a recursos internos como si estuvieras en la LAN, pero sin tocar el NAT del router.

Cloudflare Tunnel (con el cliente cloudflared corriendo como contenedor o servicio) crea túneles salientes desde tu red hacia la infraestructura de Cloudflare. A partir de ahí, asocias un subdominio a ese túnel y apuntas tráfico HTTPS hacia uno o varios servicios de tu homelab. Nadie ve tu IP doméstica ni tus puertos; ven sólo el dominio protegido por las capas de Cloudflare, donde puedes exigir login, 2FA, filtros geográficos y otras lindezas.

Para acceso tipo “VPN tradicional” a toda la red o a segmentos concretos, Tailscale es una maravilla. Se instala con un simple script, registra cada dispositivo en tu “tailnet” y genera una red privada basada en WireGuard, con ACLs para decidir qué usuario puede llegar a qué IP y puerto. De esta forma, puedes limitar, por ejemplo, que sólo tus cuentas personales accedan a 192.168.1.10:22 (el hypervisor) o a 10.10.40.100:3000 (tu herramienta de CI).

Si quieres ir un paso más, puedes describir toda tu configuración de Zero Trust en Terraform utilizando el proveedor de Cloudflare. Así mantienes tu política como código, haces cambios de forma reproducible y puedes versionarlo en Git, como si fuera otro proyecto de infra más. Es una forma muy profesional de tratar tu homelab, aunque esté en un armario del pasillo.

Cableado, LAGs y problemas típicos de rendimiento

El hardening lógico no sirve de mucho si tu red física es un chiste. Reaprovechar antiguas tomas RJ11 y cable viejo puede ser una solución temporal, pero es habitual que con cargas altas aparezcan cortes, errores de CRC o caídas de velocidad al negociar. Siempre que tengas oportunidad (obra, reforma, cambio de muebles), plantéate tirar cableado CAT6 o CAT7 de calidad y usar patch panels con keystones decentes.

Para interconectar cuartos o armarios donde tengas varios switches, el enlace troncal suele ser un cuello de botella. Si ves que el tráfico entre zonas se satura, puedes pensar en agrupar varios enlaces físicos en un LAG (link aggregation), siempre que los switches lo soporten. Así aumentas el ancho de banda disponible y tienes algo más de resiliencia ante la caída de un cable.

Documentar físicamente qué puerto va a dónde, qué VID se usa en cada tramo y cómo están configuradas las nativas te ahorra horas en el futuro. Etiqueta cables, anota puertos y mantenlo sincronizado con tu diagrama lógico de VLANs. Una parte enorme de los “misterios” de red acaban siendo un puerto mal etiquetado o un PVID incorrecto.

Cuando algo vaya raro (latencias locas, TTL expirado, rutas que se repiten), tira de herramientas básicas: traceroute desde distintos puntos (cliente, router, modem), contadores de errores en interfaces, captures de paquetes en el firewall y, si tu switch lo permite, un mirror port para ver qué etiquetas y MACs circulan realmente por un enlace problemático, y sigue nuestra guía para solucionar problemas de conexión.

Homelab como laboratorio: Proxmox, Kubernetes ligero y servicios clave

Una vez tienes la base de red y seguridad asentada, el homelab se convierte en un campo de pruebas brutal para practicar cosas muy cercanas a entornos de producción: clusters con Proxmox, Kubernetes ligero tipo k3s, NFS desde NAS como almacenamiento compartido, backups, alta disponibilidad, etc.

Proxmox te permite orquestar VMs y contenedores con una interfaz web sencilla, clustering nativo, snapshots y backups integrados. Puedes montar un NFS desde tu NAS y usarlo como almacenamiento compartido de discos virtuales, copias de seguridad o isos. Aunque la latencia no será la de un SSD local, a cambio ganas la resiliencia del NAS y la facilidad de gestionar copias, migraciones y restauraciones rápidas.

Sobre Proxmox, mucha gente levanta un pequeño cluster k3s con tres VMs de Ubuntu LTS para el plano de control, añadiendo componentes como kube-vip (IP virtual de alta disponibilidad), Longhorn (almacenamiento distribuido y copias automáticas de volúmenes), controladores de ingreso como Traefik o Nginx, y herramientas de observabilidad (Prometheus, Grafana, Loki). Todo ello te permite desplegar servicios del homelab en Kubernetes usando Helm o manifests y versionarlo con Git.

A partir de ahí, llegan las piezas que hacen que el homelab “mole” de verdad: Pi-hole para DNS y bloqueo de publicidad; Home Assistant para integrar domótica, cámaras y energía; Homebridge y Scrypted para integrar dispositivos no soportados y cámaras en HomeKit; Plex o similares para multimedia; y todo ello colgando de tus VLANs y de tus túneles Zero Trust bien atados.

El resultado de juntar segmentación, firewall estricto, DNS controlado, acceso remoto seguro, monitorización y backups es un entorno doméstico que se parece mucho a una infra moderna de empresa pero a escala casera: con menos ruido, más visibilidad, menos sorpresas cuando se cae algo y, sobre todo, con la tranquilidad de que un fallo en un cacharro WiFi barato no debería convertirse en un drama mayor.