Una red de homelab se puede complicar hasta el infinito. VLANs para todo, reglas de firewall con nombres larguísimos, DNS split horizon, túneles, ACLs, redes de storage, redes de gestión, redes de invitados, redes para IoT, redes para Kubernetes, redes para la impresora que nadie entiende por qué necesita hablar con medio planeta.
Todo eso puede tener sentido. También puede ser una forma muy sofisticada de romper Netflix un sábado por la noche.
Mi postura ahora es bastante simple: la red de casa tiene que proteger lo importante sin convertir cada cambio en una intervención quirúrgica. Si la arquitectura es tan fina que solo funciona cuando estoy delante, no es una red doméstica robusta. Es una trampa con documentación pendiente.
He pasado por fases. La fase de “todo en la misma LAN porque así no molesta”. La fase de “voy a separar absolutamente todo porque he visto un diagrama precioso”. La fase actual es más aburrida y bastante mejor: pocas zonas, reglas claras, DNS decente y acceso remoto que no dependa de abrir puertos a lo loco.
el objetivo no es parecer enterprise#
El objetivo de una red doméstica con homelab no es imitar una empresa. En una empresa tienes equipo de IT, ventanas de mantenimiento, usuarios que aceptan tickets y una cultura mínima de procesos. En casa tienes una pareja, un bebé, invitados, móviles, tablets, una tele, enchufes raros, domótica y cero paciencia para que “la red de laboratorio” impida encender una luz.
Esto importa. Mucho.
Si separas demasiado sin pensar en el uso real, acabas con reglas absurdas. La televisión no encuentra el móvil para enviar contenido. Home Assistant no ve un dispositivo IoT. La impresora desaparece. El portátil no resuelve nombres internos. Tailscale funciona desde fuera, pero no desde dentro. Todo tiene explicación técnica, claro. La pregunta es si merecía la pena.
Para mí, una red sensata tiene tres metas.
Primera: que lo crítico de casa funcione aunque el laboratorio esté roto.
Segunda: que los dispositivos poco fiables no puedan pasearse por servidores importantes.
Tercera: que yo pueda acceder y mantener el homelab sin abrir medio router ni depender de memoria tribal.
Con eso ya hay trabajo suficiente.
las zonas que sí separaría#
No haría veinte VLANs de entrada. Haría cuatro o cinco, como mucho.
LAN principal. Aquí viven móviles, portátiles personales y dispositivos de confianza. No significa confianza absoluta, pero sí el entorno normal de casa.
Servidores. Aquí viven Proxmox, NAS, servicios self-hosted, contenedores y máquinas importantes. Es la zona que quiero proteger de cacharros tontos.
IoT. Aquí van enchufes, bombillas, televisores, cámaras si las hay, aspiradores, altavoces y cualquier aparato que tenga una app pésima y un firmware que nadie actualizará jamás.
Invitados. Internet y poco más. Sin acceso a servidores, sin acceso a gestión, sin ver media red.
Laboratorio. Opcional, pero muy recomendable si pruebas cosas raras. VMs temporales, Kubernetes de pruebas, imágenes que no conoces, servicios que expones durante una tarde y luego olvidas.
Con esto cubro el 90 por ciento de los problemas reales sin montar una novela rusa.
qué no metería en la misma LAN#
No pondría IoT en la misma LAN que los servidores. Esta es la separación más fácil de defender. Un enchufe inteligente no necesita hablar con el host de Proxmox. Una tele no necesita ver el NAS entero. Una cámara barata no debería tener ruta libre hacia el panel de administración.
Tampoco mezclaría laboratorio con producción doméstica. Si estoy probando una imagen nueva, un contenedor que no conozco o una VM expuesta, no quiero que comparta zona con documentos, fotos o backups. El laboratorio tiene que poder arder sin llevarse la casa por delante.
No metería invitados en la LAN principal. No porque los invitados sean malvados, sino porque sus dispositivos no son míos. Móviles con apps raras, portátiles de trabajo, tablets de niños, de todo. Internet basta.
Y no pondría gestión de infraestructura en la misma zona que todo lo demás si puedo evitarlo. Interfaces de Proxmox, switches, firewall, NAS y paneles delicados deberían estar más protegidos. No siempre hace falta una VLAN específica de gestión en casa, pero al menos sí reglas que limiten quién entra.
reglas de firewall que entiendo dentro de seis meses#
Aquí soy cada vez menos fan de la creatividad.
Una regla de firewall buena debería poder leerse seis meses después sin sentir vergüenza. Prefiero pocas reglas claras a treinta excepciones con nombres como “TEMP_ALLOW_TEST_2_FINAL”.
Mi enfoque sería:
- LAN principal puede acceder a servicios publicados del homelab.
- LAN principal puede administrar servidores solo desde dispositivos concretos.
- Servidores pueden salir a Internet para actualizaciones y servicios necesarios.
- IoT no inicia conexiones hacia servidores salvo excepciones muy concretas.
- Home Assistant puede hablar con IoT si lo necesita.
- Invitados solo salen a Internet.
- Laboratorio no entra a servidores ni LAN principal salvo excepciones temporales.
La parte difícil no es escribir reglas. Es no abrir excepciones eternas cada vez que algo molesta. Si una excepción es temporal, tiene que tener nombre, motivo y fecha mental de caducidad. Si no, se queda para siempre. Lo temporal en un homelab tiene una esperanza de vida absurda.
DNS: el pegamento silencioso#
El DNS interno es una de esas piezas que parece menor hasta que falla. Entonces todo parece roto a la vez.
Yo no intentaría resolver la vida con .local para todo. mDNS va bien para algunas cosas, pero no sustituye a un DNS interno serio. En cuanto tienes varios servicios, reverse proxy, certificados, Tailscale, contenedores y nombres que quieres recordar, necesitas algo más limpio.
Me gusta tener nombres simples para servicios internos. Algo como:
| |
No hace falta publicar todo fuera. De hecho, mejor no hacerlo. Pero dentro de casa quiero nombres estables. Las IPs cambian, las máquinas se mueven y mi memoria no mejora con los años.
También quiero un fallback. Si el DNS avanzado cae, la casa no debería quedarse sin Internet. El router puede usar DNS externo. Los clientes pueden tener una ruta de emergencia. Lo que no quiero es que un contenedor de DNS roto convierta la red en un pisapapeles.
Pi-hole, AdGuard Home, Unbound o el DNS del firewall pueden servir. Lo importante es entender quién resuelve qué, dónde están las entradas críticas y qué pasa si el servicio se cae.
Tailscale como acceso remoto, no como excusa para no diseñar#
Tailscale me parece de las mejores piezas para un homelab doméstico. Te evita abrir puertos, funciona muy bien para acceso remoto y reduce muchísimo el roce de entrar desde fuera. Pero no lo usaría como excusa para no pensar la red.
Una cosa es acceder por Tailscale a un servidor concreto. Otra es anunciar toda la LAN sin control y olvidarse. Los subnet routers son comodísimos, pero también amplían mucho el alcance. Si desde cualquier portátil conectado a Tailscale puedes entrar a toda la red doméstica, necesitas ACLs y cabeza.
Mi uso ideal sería:
- Acceso directo a servidores concretos por Tailscale.
- Subnet routing solo cuando aporte valor real.
- ACLs para separar dispositivos personales, servidores y accesos temporales.
- Exit node solo si lo necesito de verdad.
- Nada de exponer paneles internos a Internet por comodidad.
Tailscale no sustituye al firewall. Es otra capa. Muy buena, pero otra capa.
También conviene pensar qué pasa si Tailscale no funciona. Si estoy en casa, no debería necesitarlo para administrar la red local. Si estoy fuera y todo depende de él, al menos quiero tener claro qué servicios son accesibles y desde qué dispositivos.
reverse proxy y túneles: publicar menos#
Publicar servicios es tentador. Montas algo, le pones un dominio, certificado, reverse proxy y queda precioso. El problema es que cada servicio expuesto se convierte en una responsabilidad.
No todo necesita estar en Internet.
Para mí hay tres categorías.
Servicios públicos de verdad. Una web, un blog, algo pensado para visitantes externos.
Servicios privados accesibles desde fuera. Paneles personales, apps familiares, herramientas que uso remoto. Estos prefiero meterlos detrás de VPN, Tailscale, Cloudflare Access o autenticación fuerte.
Servicios internos. Paneles de Proxmox, NAS, dashboards sensibles, bases de datos, herramientas administrativas. Estos no deberían estar publicados salvo una razón muy buena.
Cloudflare Tunnel puede ser muy cómodo. Un reverse proxy como Traefik o Nginx Proxy Manager también. Pero comodidad no es lo mismo que criterio. Si publico diez paneles internos porque es fácil, estoy comprando deuda de seguridad a plazos.
storage y cluster: cuidado con mezclar tráfico#
Si usas Proxmox, Ceph, NFS, iSCSI o cualquier storage compartido, la red empieza a importar mucho más. Aquí no conviene mezclar todo sin mirar.
El tráfico de gestión no es lo mismo que el tráfico de VMs. El tráfico de storage no es lo mismo que navegar por Internet. Corosync, si tienes cluster Proxmox, agradece una red estable y predecible. Ceph puede comerse ancho de banda con una alegría considerable. Un backup grande puede hacer que todo parezca roto si comparte enlace con demasiadas cosas.
En un homelab pequeño no siempre tienes switches gestionables, varias NICs y cableado perfecto. Lo entiendo. Pero al menos hay que saber qué tráfico comparte camino.
Si solo tienes una red, no pasa nada. Empieza simple. Pero no metas HA, storage compartido y backups pesados esperando que todo se comporte como un diseño de datacenter. El cuello de botella aparecerá cuando menos gracia haga.
IoT: permitir lo justo#
IoT merece sección propia porque es el cajón de los horrores. Bombillas, enchufes, teles, cámaras, robots, altavoces. Muchos funcionan bien, pero no los trataría como ciudadanos de primera.
La regla base: IoT sale a Internet si lo necesita y habla con Home Assistant o el controlador que toque. Poco más.
Hay excepciones. Chromecast, AirPlay, impresoras y descubrimiento local pueden pedir mDNS, multicast o reglas específicas. Aquí es donde mucha gente abandona y vuelve a meter todo en la misma LAN. Lo entiendo. Pero prefiero abrir lo necesario que rendirme del todo.
La clave es no perseguir pureza. Si una tele necesita una regla concreta para que funcione enviar contenido desde el móvil, se hace. Pero no por eso le doy acceso a todos los servidores.
Seguridad doméstica sensata no es bloquearlo todo. Es que un cacharro barato no tenga más permisos de los que necesita.
la red que montaría si empezase hoy#
Si empezase desde cero, montaría algo así.
Un firewall decente como pfSense, OPNsense, MikroTik o un router prosumer con VLANs bien soportadas. No hace falta comprar lo más caro, pero sí algo que no convierta cada regla en sufrimiento.
Un switch gestionable para separar VLANs sin magia. Pocos puertos al principio, pero fiable.
WiFi con SSIDs separados para LAN, IoT e invitados. Si el punto de acceso no soporta bien VLANs, me pensaría cambiarlo antes de complicar todo lo demás.
DNS interno controlado desde el firewall o desde un servicio que pueda restaurar rápido. Nada de depender de una VM experimental para resolver media casa.
Tailscale para acceso remoto administrativo, con ACLs simples.
Reverse proxy solo para servicios que realmente deban tener nombre y entrada clara. No para cada contenedor que instalo por curiosidad.
Y una VLAN de laboratorio donde pueda romper cosas sin pedir perdón a la red principal.
lo que no haría#
No empezaría con diez VLANs. Es demasiado pronto. Primero hay que entender el uso real.
No pondría reglas tan estrictas que cada dispositivo nuevo requiera una tarde de debugging.
No publicaría paneles administrativos en Internet por comodidad.
No dependería de un único DNS casero sin fallback.
No mezclaría IoT y servidores porque “total, es casa”.
No convertiría Tailscale en una barra libre hacia toda la red.
No montaría HA de red en casa si luego nadie sabe recuperarla. La alta disponibilidad mal entendida puede crear más puntos de fallo que los que elimina.
mi conclusión#
Una red de homelab buena no es la más compleja. Es la que aguanta el uso real.
Tiene que dejarte cacharrear sin poner en riesgo las fotos, las contraseñas o la domótica. Tiene que permitir que la casa siga funcionando aunque tú estés probando algo raro. Tiene que darte acceso remoto sin abrir puertas innecesarias. Y tiene que ser lo bastante simple como para entenderla cuando algo falle.
Para mí, la receta razonable es poca fantasía: LAN principal, servidores, IoT, invitados y laboratorio. DNS interno limpio. Tailscale con límites. Firewall con reglas que pueda leer sin odiarme. Publicar menos servicios y separar lo que de verdad no debería tocarse.
Lo demás puede venir después. Primero una red que no convierta cada sábado en una auditoría de paquetes.