La red de casa es uno de los sitios donde más fácil es pasarse de listo. Empiezas queriendo separar invitados e IoT, que es razonable. Luego añades una VLAN para servidores, otra para laboratorio, otra para cámaras, otra para domótica, otra para trabajo, otra para cacharros raros y otra porque total ya que estamos. Un sábado cualquiera reinicias el firewall, algo no resuelve DNS, el móvil no encuentra la tele y alguien pregunta por qué no se puede poner Netflix.
Esa es la señal de que la red ha dejado de ayudar.
Una red doméstica con homelab no tiene que parecer una red corporativa pequeña. Tiene que hacer tres cosas bien: que la casa funcione, que lo crítico esté protegido y que el laboratorio pueda romperse sin arrastrar lo demás. Todo lo que no sirva a eso es decoración técnica.
Si hoy empezara desde cero, diseñaría la red con menos obsesión por segmentar cada aparato y más atención a los flujos reales. Quién necesita hablar con quién. Qué pasa si cae el DNS. Qué servicios usa la familia. Qué dispositivos son basura desde el punto de vista de seguridad. Y qué partes puedo tocar a las once de la noche sin ganarme una mirada peligrosa.
Primero: qué considero crítico#
Antes de hablar de VLANs, pondría por escrito qué cosas tienen que funcionar aunque el homelab esté medio tocado.
En una casa real, para mí lo crítico suele ser:
- Internet básico.
- WiFi estable.
- DNS público funcional.
- Móviles, portátiles y tablets.
- Domótica básica si la familia depende de ella.
- Televisión y streaming.
- Acceso remoto de emergencia.
- Backups en marcha.
- Algún servicio familiar como fotos o documentos.
El resto puede esperar. Un dashboard, un servidor de pruebas, una VM experimental o una app que solo uso yo no deberían tener el mismo peso que la conexión de casa. Esta distinción parece obvia, pero se olvida cuando todo vive detrás del mismo firewall, el mismo DNS y el mismo switch.
Mi regla es simple: si alguien que no mantiene el homelab lo usa a diario, no es laboratorio. Es producción doméstica. Y producción doméstica merece aburrimiento.
Las redes que sí crearía#
No montaría doce redes desde el primer día. Montaría pocas y claras.
Una LAN principal para dispositivos de confianza. Portátiles, móviles, tablets, equipos de trabajo y quizá alguna consola. Aquí quiero poca fricción. Buen WiFi, buen DNS, acceso a servicios internos razonables y cero experimentos raros.
Una red IoT para dispositivos que no me inspiran demasiada confianza. Enchufes, bombillas, aspiradores, cámaras baratas, altavoces, teles y aparatos que piden internet para hacer cosas absurdamente simples. Esta red debe salir a internet si hace falta, pero no debería poder iniciar conexiones libremente hacia servidores, portátiles o almacenamiento.
Una red de invitados. Internet y poco más. Sin acceso a NAS, impresoras, paneles internos ni servicios del homelab. Si alguien viene a casa y necesita WiFi, no necesita ver mis nombres internos ni mis cacharros.
Una red de servidores o homelab estable. Aquí vivirían Proxmox, NAS, Docker, servicios internos, DNS, monitorización y lo que considero infraestructura. No pondría aquí pruebas salvajes. Esta red es la parte seria.
Una red de laboratorio si de verdad la voy a usar. Para VMs temporales, pruebas de seguridad, clusters raros, cacharreo con Kubernetes o servicios que todavía no sé si quiero mantener. Si no tienes laboratorio real, no la crees por estética.
Con eso ya cubres casi todo. Cinco segmentos como máximo, y muchas casas vivirían perfectas con tres: principal, IoT e invitados.
Lo que no segmentaría por deporte#
No separaría cada categoría porque una guía lo diga. Cámaras, domótica, consolas, impresoras, trabajo, niños, laboratorio, servidores, administración, multimedia. Todo puede tener sentido en algunos casos. Pero cada red extra trae coste: reglas, DNS, DHCP, mDNS, descubrimiento, firewall, documentación y mantenimiento.
La segmentación buena reduce riesgo. La mala aumenta averías.
Un ejemplo típico: pones la tele en IoT, el móvil en LAN principal y luego el casting deja de funcionar. Se puede arreglar con mDNS reflector, reglas concretas y paciencia. Perfecto. Pero si lo único que querías era poner YouTube en la tele sin pensar, igual has comprado complejidad para resolver un riesgo bastante limitado.
Otro ejemplo: impresoras. Desde seguridad dan pereza. Desde convivencia, más. Si separarlas obliga a pelearte cada vez que alguien quiere imprimir un documento, quizá merece la pena aislarlas, pero dejando reglas claras desde la LAN principal. No todo tiene que ser bloqueo total.
El objetivo no es ganar una medalla de firewall. Es que el riesgo razonable baje sin que la casa se vuelva insoportable.
DNS: la pieza pequeña que manda demasiado#
En una red con homelab, el DNS acaba siendo más importante de lo que parece. Si usas nombres internos, bloqueadores de publicidad, split-horizon o reverse proxy, muchas cosas dependen de que el DNS responda.
Yo lo diseñaría con dos ideas:
- DNS interno para comodidad.
- Fallback simple para que internet no muera.
El DNS principal puede ser Pi-hole, AdGuard Home, Unbound o lo que prefieras. Lo importante es que no sea un único punto de fallo absurdo. Si el router entrega solo un DNS y ese DNS vive en una VM que reinicias a menudo, la casa sufrirá.
Me gusta tener dos resolvers internos o, como mínimo, un plan de emergencia donde el router pueda entregar DNS externos si el homelab cae. Perder nombres internos durante un rato no pasa nada. Perder todo internet porque reiniciaste un contenedor es una tontería evitable.
También separaría nombres internos de nombres públicos. Para casa usaría algo tipo home.arpa o un dominio interno controlado. Evitaría depender de .local para todo. mDNS está bien para descubrir cuatro dispositivos, pero no lo trataría como base de una arquitectura seria.
IoT: internet sí, confianza no#
La red IoT existe porque muchos dispositivos domésticos son cajas negras. Funcionan, sí. Pero no tengo ganas de darles acceso a portátiles, NAS o paneles internos. Un enchufe inteligente no necesita hablar con mi servidor de documentos.
Mi política para IoT sería:
- Puede salir a internet si el dispositivo lo necesita.
- Puede hablar con Home Assistant si hace falta.
- Puede responder a conexiones iniciadas desde la LAN principal cuando tenga sentido.
- No puede iniciar conexiones hacia la LAN principal.
- No puede acceder al NAS ni a redes de servidores salvo excepciones concretas.
Esto suena estricto, pero en la práctica se reduce a pocas reglas. El truco está en no romper los flujos útiles. Si Home Assistant necesita hablar con dispositivos IoT, permites eso. Si el móvil necesita descubrir un altavoz o una tele, decides si vas a permitir mDNS entre redes o si prefieres dejar esos dispositivos en otra zona.
Aquí no hay pureza perfecta. Hay trade-offs. Yo prefiero un poco menos de aislamiento si eso evita que la casa se convierta en una colección de dispositivos que “funcionan salvo cuando quieres usarlos”.
VPN: entrada de emergencia, no parche para todo#
Tailscale, WireGuard o una VPN clásica son herramientas buenísimas para entrar al homelab desde fuera. Pero no deberían servir para tapar una red interna mal pensada.
La VPN debe responder a una pregunta: si estoy fuera de casa y algo falla, ¿puedo entrar de forma segura a arreglar lo mínimo?
Para mí eso implica:
- Acceso a la red de administración o servidores.
- DNS interno opcional, pero con fallback.
- Autenticación fuerte.
- Dispositivos autorizados de forma explícita.
- Nada de abrir paneles al mundo si no hace falta.
Tailscale me gusta mucho para esto porque reduce fricción. Puedes tener acceso remoto sin abrir puertos, con dispositivos identificados y ACLs razonables. Pero incluso con Tailscale conviene no perder la cabeza. Si todos los dispositivos pueden hablar con todo por la malla, has cambiado el problema de sitio.
WireGuard puro me gusta cuando quiero control sencillo y pocas capas. Requiere más configuración manual, pero también es más transparente. Lo importante no es la herramienta. Es que el acceso remoto no se convierta en una puerta lateral sin criterio.
Firewall: pocas reglas, bien nombradas#
El firewall doméstico no debería ser una novela. Si necesitas leer veinte reglas para saber si un móvil puede llegar a Home Assistant, algo se ha ido torciendo.
Me gustan las reglas agrupadas por intención:
- LAN principal puede iniciar conexiones hacia servicios internos.
- IoT no puede iniciar conexiones hacia LAN ni servidores.
- Servidores solo exponen puertos necesarios.
- Invitados solo salen a internet.
- VPN puede llegar a administración y servicios concretos.
- Laboratorio tiene salida limitada y acceso muy controlado al resto.
Nombraría las reglas con lenguaje humano. “LAN a Home Assistant”, “IoT bloqueado hacia servidores”, “VPN a paneles internos”. Parece una tontería hasta que vuelves seis meses después y no recuerdas por qué permitiste un puerto.
También evitaría reglas temporales que se quedan para siempre. Si abro algo para probar, lo apunto o lo borro al terminar. Las redes domésticas se llenan de permisos fósiles. Luego nadie sabe si son necesarios o si están ahí porque una tarde algo no funcionaba.
Servicios críticos: no todos en el mismo cesto#
Una mala costumbre en homelab es hacer que todo dependa de todo. El router depende del DNS interno, el DNS interno depende de una VM, la VM depende del almacenamiento, el almacenamiento depende del DNS para montar algo, el panel depende del reverse proxy y el reverse proxy depende de certificados que nadie revisa. Muy bonito hasta que cae una pieza y empiezas a tirar del hilo.
Para servicios críticos, intentaría romper ciclos.
El router y el WiFi deben poder funcionar aunque el homelab esté apagado. El DNS debe tener modo degradado. Home Assistant debería poder mantener automatizaciones básicas sin depender de diez servicios externos. El NAS debe ser accesible por IP o nombre simple si el DNS bonito falla. La VPN de emergencia no debería depender del servicio que quieres arreglar.
Esto es más importante que añadir otra VLAN. Una red con pocas dependencias raras aguanta mejor que una red supersegmentada donde todo requiere una excepción.
mDNS, casting e impresoras: el barro doméstico#
La teoría de redes es limpia. La casa no.
Chromecast, AirPlay, impresoras, altavoces, móviles y teles usan descubrimiento local. Muchos esperan estar en la misma red. Cuando separas LAN e IoT, empiezan los detalles feos. Puedes usar reflectores mDNS, reglas específicas y configuraciones del firewall. Funciona. Pero hay que probarlo.
Mi recomendación es decidir qué flujos importan:
- Móvil a tele.
- Móvil a altavoz.
- Portátil a impresora.
- Home Assistant a dispositivos IoT.
- Cámaras a grabador.
Luego abres solo eso. No “IoT a LAN” porque algo no funciona. Eso derrota la segmentación. Tampoco bloquearía todo con orgullo si cada semana alguien tiene que pedir ayuda para poner música. La red tiene que servir a la casa, no al revés.
Laboratorio separado de producción#
Esta es la separación que más valor me parece que aporta. No tanto IoT, invitados o cámaras. Laboratorio separado.
Si pruebas cosas de verdad, necesitas un sitio donde romper sin miedo. Una VLAN o red de laboratorio con salida a internet, acceso mínimo al NAS y casi ninguna capacidad de iniciar conexiones hacia producción. Ahí puedes montar un cluster temporal, probar un reverse proxy, levantar servicios raros o aprender sin mirar de reojo los dispositivos familiares.
La parte importante es no promocionar experimentos a producción sin limpiar. Si un servicio empieza en laboratorio y se queda, toca moverlo, documentarlo, darle backup y revisarlo. Si no haces esa transición, tu producción será un cementerio de pruebas que salieron bien una vez.
Cómo lo montaría por fases#
No haría toda la red perfecta el primer día. La montaría por fases.
Primera fase: LAN principal e invitados. Router estable, WiFi bien puesto, DNS básico, contraseñas decentes y acceso remoto mínimo.
Segunda fase: IoT separado. Mover dispositivos poco fiables, probar Home Assistant, casting, impresoras y reglas básicas. Aquí hay que tener paciencia.
Tercera fase: servidores separados. NAS, Proxmox, Docker, DNS interno, monitorización y paneles. Reglas claras desde LAN principal y VPN.
Cuarta fase: laboratorio. Solo si de verdad hay cacharreo frecuente. Si no, mejor no añadirla.
Quinta fase: refinamiento. Alertas, documentación, backup de configuración del firewall, pruebas de caída de DNS y revisión de reglas.
Este orden evita una trampa: diseñar una red enorme antes de saber qué necesitas. La red debe crecer con los usos reales, no con un diagrama bonito.
La prueba que haría antes de darla por buena#
Una red doméstica no está terminada cuando el diagrama queda bonito. Está terminada cuando falla algo y la casa sigue funcionando.
Yo probaría estas situaciones:
- Apagar el DNS principal.
- Reiniciar el servidor de homelab.
- Cortar la red IoT.
- Entrar por VPN desde fuera.
- Imprimir desde un portátil.
- Enviar contenido del móvil a la tele.
- Acceder al NAS por IP.
- Arrancar Home Assistant sin internet.
- Conectar un invitado al WiFi.
No hace falta hacerlo todo cada mes. Pero sí al montar. Si estas pruebas descubren problemas, perfecto. Ese es el objetivo. Mejor encontrarlos con calma que en mitad de una noche rara.
Mi diseño final#
Mi red ideal para casa sería aburrida en lo importante y flexible en el laboratorio.
La LAN principal tendría dispositivos de confianza y acceso cómodo a servicios internos. IoT estaría aislada, con excepciones concretas. Invitados solo internet. Servidores en su zona, con exposición mínima. VPN para entrar desde fuera sin abrir paneles al mundo. DNS interno útil, pero con plan B. Laboratorio separado para romper cosas sin romper la casa.
No buscaría perfección. Buscaría que las averías fuesen pequeñas. Que si falla IoT, no caiga internet. Que si falla el homelab, la familia pueda navegar. Que si rompo una VM, no deje sin DNS a todos. Que si estoy fuera, pueda entrar a arreglar sin depender de la pieza rota.
La red doméstica buena no es la más segmentada. Es la que reduce riesgos sin convertirse en otro trabajo. Y en un homelab con familia, eso vale más que cualquier diagrama precioso.