Durante mucho tiempo, exponer servicios en un homelab era casi sinónimo de abrir puertos en el router y poner un reverse proxy delante. Funcionaba. También te dejaba esa sensación tan agradable de tener media casa colgando de una regla NAT que escribiste una noche con sueño.
Ahora tenemos más opciones. Cloudflare Tunnel, Tailscale, WireGuard, VPNs clásicas, reverse proxies, autenticación delante, ACLs, DNS interno, DNS externo. El problema ya no es falta de herramientas. El problema es elegir sin convertir la red de casa en un sudoku.
Mi forma de verlo ha cambiado bastante. Ya no intento usar una sola solución para todo. Divido los servicios en tres grupos:
- Servicios públicos que quiero que vea cualquiera.
- Servicios privados que quiero usar desde mis dispositivos.
- Servicios administrativos que no deberían estar cerca de Internet ni por accidente.
Esa separación parece simple, pero evita muchas decisiones malas.
la mala idea: abrir puertos porque sí#
Abrir un puerto no es pecado. A veces es exactamente lo que toca. El problema es hacerlo por inercia.
Tienes un servicio nuevo, quieres verlo desde fuera, abres 443 hacia un reverse proxy, metes un subdominio y listo. Luego añades otro servicio, otro subdominio, otro contenedor, otra excepción. Al cabo de unos meses tienes una colección de aplicaciones con calidades de seguridad muy distintas entrando por la misma puerta.
No todos los servicios están pensados para estar expuestos. Un blog estático, una web pública o una API con autenticación seria pueden tener sentido. Un panel de administración, un dashboard casero o una aplicación que usas tú solo, normalmente no.
El router tampoco debería convertirse en el índice de tu homelab. Cuantas menos reglas públicas tenga, mejor duermo.
Cloudflare Tunnel: cómodo para lo público y semi público#
Cloudflare Tunnel me gusta para servicios web que quiero publicar sin abrir puertos entrantes. La idea es sencilla: un conector dentro de tu red crea una conexión saliente hacia Cloudflare y Cloudflare entrega el tráfico desde fuera. Tu router no necesita redirigir 80 o 443 hacia dentro.
Para un homelab, eso tiene varias ventajas claras.
La primera es que no dependes tanto de la IP pública de casa. Si tu conexión cambia o estás detrás de CG-NAT, el túnel puede seguir funcionando.
La segunda es que reduces superficie en el router. No eliminas todos los riesgos, pero no dejas un puerto escuchando directamente en tu WAN.
La tercera es que puedes añadir capas como Access, reglas por identidad, políticas por correo, país, método de autenticación o aplicación.
Lo usaría para:
- Webs estáticas o públicas.
- Aplicaciones que quiero enseñar a terceros.
- Servicios con autenticación propia decente.
- Paneles semi privados protegidos por Cloudflare Access.
- Endpoints concretos de automatización.
No lo usaría como excusa para publicar todo el homelab. Que sea fácil no significa que sea buena idea. Un túnel mal planteado puede ser simplemente un puerto abierto con mejor traje.
También hay una dependencia clara: Cloudflare pasa a formar parte del camino. Si quieres independencia total de terceros, no es tu herramienta principal. A mí me parece un trade-off aceptable para servicios públicos o semi públicos, pero no para acceso administrativo crítico.
Tailscale: mi opción favorita para acceso privado#
Tailscale me parece de las herramientas más agradecidas para un homelab doméstico. Usa WireGuard por debajo, pero evita gran parte del trabajo manual de claves, peers y rutas. Instalas cliente, autenticas dispositivos, defines ACLs si quieres ponerte serio y tienes una red privada entre máquinas aunque estén en sitios distintos.
Para acceso personal, es difícil de batir.
Lo usaría para entrar al panel de Proxmox, dashboards internos, servidores, Home Assistant, NAS, bases de datos, herramientas de monitorización, interfaces de administración y servicios que solo necesito yo o mi familia.
La ventaja práctica es enorme: no abro puertos, no publico paneles raros, no dependo de recordar qué subdominio escondía qué cosa. Si mi portátil o móvil está en la tailnet, entra. Si no está, no entra.
Eso sí, Tailscale también necesita orden.
Si metes todos los dispositivos en la misma red plana, sin ACLs y sin pensar roles, acabas con una VPN cómoda pero demasiado permisiva. Para una casa pequeña puede valer al principio. Para un homelab con varios servidores, laboratorios y servicios sensibles, conviene separar.
Mi estructura mental sería:
- Dispositivos personales con acceso a servicios internos.
- Servidores con acceso limitado entre ellos.
- Subnet router solo cuando hace falta.
- Exit node solo si tienes un caso claro.
- ACLs para que no todo hable con todo.
El subnet router es especialmente cómodo, pero peligroso si lo activas sin pensar. De repente una red entera puede ser accesible desde fuera a través de Tailscale. Bien configurado es fantástico. Mal configurado es una autopista privada demasiado ancha.
VPN clásica: menos moderna, todavía útil#
WireGuard manual, OpenVPN o una VPN tradicional siguen teniendo sitio. No todo tiene que pasar por una red mesh gestionada por terceros. Hay casos donde prefiero algo más directo.
Por ejemplo, una VPN clásica tiene sentido si quieres control completo, si no quieres depender de un proveedor de coordinación, si tienes un firewall tipo OPNsense o pfSense haciendo de centro de red, o si quieres dar acceso muy concreto a una sede, familiar o dispositivo.
WireGuard puro es elegante y rápido, pero exige más disciplina. Tienes que gestionar claves, rutas, DNS, revocación y configuración de clientes. Para una persona técnica no es un drama. Para familia o dispositivos que cambian mucho, Tailscale suele ganar por goleada.
OpenVPN lo usaría cada vez menos para algo nuevo, salvo que ya esté integrado en una infraestructura o necesites compatibilidad concreta. Funciona, pero WireGuard me parece más limpio.
La VPN clásica también tiene una virtud: es fácil entender el perímetro. Hay un servidor, hay clientes, hay rutas. Menos magia. A veces eso viene bien cuando toca reparar.
mi matriz de decisión#
Si el servicio debe ser público, Cloudflare Tunnel o un reverse proxy bien cuidado.
Si el servicio es solo para mí, Tailscale.
Si el servicio es administrativo, Tailscale o VPN, pero sin exposición pública.
Si necesito acceso de emergencia independiente de Cloudflare o de una cuenta externa, WireGuard clásico o acceso local documentado.
Si tengo que compartir algo con una persona no técnica durante poco tiempo, Cloudflare Access puede ser más cómodo que meterla en mi VPN.
Si voy a conectar redes completas, lo pienso dos veces antes de anunciar subredes. A veces es mejor instalar Tailscale en dos máquinas concretas que abrir una LAN entera.
La pregunta que más me ayuda es esta: ¿quién necesita acceder y desde dónde?
No empiezo por la herramienta. Empiezo por el usuario y el riesgo.
ejemplos prácticos en casa#
Un blog público o una web de documentación externa puede ir por Cloudflare Tunnel. Tiene sentido que exista en Internet, no necesita acceso a toda mi red y puedo poner caché, TLS y reglas delante.
Un panel de Proxmox no debería ir por Cloudflare Tunnel abierto ni por un subdominio escondido. Lo pondría detrás de Tailscale o VPN. Que un panel tenga contraseña no lo convierte automáticamente en buen ciudadano de Internet.
Home Assistant depende del caso. Si solo lo uso yo, Tailscale. Si necesito acceso familiar cómodo desde móviles, puedo valorar Cloudflare Access, Nabu Casa o una exposición muy controlada. Aquí pesa mucho la convivencia. La solución técnicamente perfecta que nadie de casa puede usar acaba siendo mala.
Vaultwarden me parece delicado. Si lo expones, debe estar muy bien protegido, actualizado, con 2FA y backups probados. Si lo usas solo tú, Tailscale reduce bastante la exposición. Si la familia necesita acceso desde fuera sin VPN, toca hacer el diseño con más cuidado.
Uptime Kuma, Grafana, Portainer, Dockge, paneles de NAS y administración de routers: privado. Sin discusión larga. Son herramientas para mirar y tocar infraestructura. No necesitan estar en Google.
Immich o Paperless-ngx dependen del uso. Para acceso personal, VPN. Para familia, habría que equilibrar comodidad y seguridad. Si el servicio guarda fotos familiares o documentos, no lo publicaría alegremente solo porque el túnel tarde dos minutos en configurarse.
DNS: la mitad invisible del problema#
Exponer servicios no va solo de tráfico. También va de nombres.
Me gusta tener DNS público para lo público y DNS interno para lo privado. Parece obvio, pero mucha gente acaba usando subdominios públicos para todo, aunque solo resuelvan por dentro o aunque apunten a direcciones privadas. Funciona, pero mezcla conceptos.
Para servicios internos, un DNS local decente ayuda mucho. Pi-hole, AdGuard Home, Unbound, el DNS del router o una solución más seria. Lo importante es que los nombres sean predecibles.
Prefiero servicio.home.arpa o un dominio interno claro antes que depender de .local para todo. .local tiene su sitio con mDNS, pero no lo usaría como base de una red con varios servicios, VPN y servidores.
Con Tailscale, MagicDNS es comodísimo. También puede volverse otra dependencia si no documentas rutas alternativas. Si mañana MagicDNS falla, quiero poder llegar por IP privada de Tailscale o por nombre local básico.
La red se rompe muchas veces por DNS, no por el servicio en sí.
autenticación delante no arregla una mala exposición#
Cloudflare Access, Authelia, Authentik y soluciones similares son útiles. Mucho. Pero no deberían usarse como perfume sobre una arquitectura rara.
Si un servicio no debería estar público, ponerle una puerta extra puede ser mejor que nada, pero quizá la pregunta correcta es por qué está público.
Una capa de autenticación delante ayuda con:
- Servicios sin login propio.
- Acceso temporal a terceros.
- Paneles semi privados.
- Separar identidad externa de usuarios internos.
Pero no elimina la necesidad de actualizar la aplicación, revisar logs, limitar métodos, cuidar cookies, gestionar sesiones y entender qué endpoints quedan fuera.
También hay servicios que no se llevan bien con proxies, websockets, apps móviles o callbacks. Antes de declarar victoria, hay que probar el flujo real.
no todo merece acceso remoto#
Esta es quizá la parte menos técnica y más útil. No todo servicio necesita funcionar desde fuera de casa.
Hay cosas que uso solo cuando estoy en la red local. Hay paneles que puedo consultar mañana. Hay dashboards que no merecen abrir un camino nuevo. Hay herramientas que existen para mantenimiento y no deberían ser cómodas desde el móvil en una cola del supermercado.
La comodidad tiene coste. Cada acceso remoto añade algo que mantener, auditar y recordar.
Mi regla es que un servicio debe justificar su exposición. No al revés.
Si no puedo explicar quién lo usa, desde dónde, con qué autenticación y qué pasa si se compromete, se queda dentro.
diseño que me parece sensato#
Para un homelab doméstico con servicios reales, plantearía algo así.
Cloudflare Tunnel para webs públicas, documentación pública, endpoints concretos y aplicaciones que deban verse desde fuera. Siempre con el mínimo de rutas necesarias.
Tailscale para administración, acceso personal, dashboards internos, SSH, paneles de infraestructura y servicios privados.
VPN clásica o WireGuard manual como opción de control directo, acceso de emergencia o escenarios donde no quiero depender de coordinación externa.
Reverse proxy interno para ordenar servicios dentro de casa, no como excusa para publicarlos todos.
DNS interno limpio, con nombres estables y documentación mínima.
Backups y acceso de recuperación pensados aparte. Si todo mi acceso depende de una sola cuenta externa, una sola app móvil o un solo túnel, tengo un punto débil.
errores que intentaría evitar#
El primero: publicar paneles de administración porque tienen login.
El segundo: usar Cloudflare Tunnel para todo y pensar que eso equivale a seguridad.
El tercero: meter una red entera por Tailscale sin ACLs ni límites.
El cuarto: depender de DNS mágico sin una ruta alternativa.
El quinto: olvidar la experiencia de la familia. Si algo lo usa más gente, la seguridad perfecta pero incómoda acabará rodeada por atajos peores.
El sexto: no revisar nunca qué sigue expuesto. Un inventario mensual de subdominios, túneles, reglas y dispositivos VPN vale más que muchas capas exóticas.
mi conclusión#
Cloudflare Tunnel, Tailscale y VPN clásica no compiten exactamente por el mismo sitio. Se pisan un poco, pero cada una brilla en un caso distinto.
Cloudflare Tunnel me gusta para publicar sin abrir puertos. Tailscale me gusta para entrar sin publicar. WireGuard o VPN clásica me gustan como control directo y plan B.
La arquitectura sana no es la más moderna. Es la que reduce exposición, sigue siendo usable y puedes explicar dentro de seis meses sin mirar veinte notas.
En casa, eso suele significar menos servicios públicos, más acceso privado y cero heroicidades con paneles administrativos en Internet.
El homelab ya da suficiente trabajo sin convertir el router en una puerta giratoria.