Si ayer hablamos de Tailscale para acceso privado a tu homelab, hoy toca el otro lado: exponer servicios a Internet. Porque hay cosas que quieres que sean públicas: una web personal, un Gitea para colaborar con gente, un dashboard de analytics.
La forma clásica es la pesadilla conocida: abrir puertos en el router, configurar DDNS porque tu IP cambia, obtener certificados SSL con Let’s Encrypt, renovarlos cada 3 meses, y rezar para que nadie te haga un port scan y encuentre algo que no debería.
Cloudflare Tunnels elimina todo eso. Y cuando digo todo, es todo.
Cómo funciona#
La idea es elegante en su simplicidad: en vez de abrir tu red hacia Internet, tu servidor abre una conexión saliente hacia Cloudflare. El tráfico de Internet llega a Cloudflare, pasa por el túnel cifrado, y llega a tu servidor. Todo sin que tu router exponga nada.
| |
Tu IP pública real queda completamente oculta. Si alguien hace un DNS lookup de tu dominio, ve las IPs de Cloudflare, no la tuya. Esto solo ya es una mejora de seguridad enorme.
Lo que tengo expuesto#
Mi tunnel corre como contenedor Docker en Unraid y gestiona el tráfico de 6 subdominios:
| |
Seis servicios públicos. Todos con HTTPS. Todos protegidos por Cloudflare. Cero puertos abiertos en mi router.
La web que estás leyendo ahora mismo llega a ti a través de un Cloudflare Tunnel que termina en un LXC de Proxmox con nginx en mi casa.
Setup paso a paso#
1. Dominio + Cloudflare#
Necesitas un dominio con los nameservers apuntando a Cloudflare. Si ya lo tienes, perfecto. Si no, un dominio .com cuesta 10€/año y Cloudflare es uno de los registradores más baratos.
La cuenta de Cloudflare es gratuita. Sí, gratis. No necesitas plan de pago para tunnels.
2. Crear el tunnel#
Ve al dashboard de Cloudflare → Zero Trust → Networks → Tunnels → Create a tunnel.
Dale un nombre. Cloudflare te dará un token. Es una cadena larga que identifica tu tunnel.
3. Instalar cloudflared#
En Docker (lo que uso yo):
| |
En Unraid, Community Applications tiene un template para cloudflared. Pegas el token, arrancas, y funciona.
En Linux directamente:
| |
4. Configurar rutas#
En el dashboard del tunnel, añades las rutas. Cada ruta es un subdominio que apunta a un servicio local:
| |
Cloudflare crea automáticamente el registro DNS CNAME. No tienes que tocar nada en la configuración de DNS.
El primer servicio me llevó 5 minutos. Los siguientes, 30 segundos cada uno.
Lo que nadie te dice#
La latencia es irrelevante para webs#
“Pero si el tráfico pasa por Cloudflare, ¿no añade latencia?” Sí, técnicamente. Unos 5-10ms extra. Que en la práctica no notas absolutamente nada.
De hecho, para visitantes lejanos, Cloudflare mejora la latencia porque cachea contenido estático en su CDN global. Un visitante desde Argentina accediendo a mi web en España recibe los assets estáticos desde un edge de Cloudflare en Buenos Aires, no desde mi servidor.
El cacheo es un regalo#
Cloudflare cachea automáticamente archivos estáticos (CSS, JS, imágenes). Mi web en Hugo genera HTML estático, así que la mayoría de requests ni siquiera llegan a mi servidor. Cloudflare las sirve directamente desde su CDN.
Esto significa que aunque mi conexión de casa sea modesta (300Mbps de subida), la web aguanta picos de tráfico sin despeinarse porque Cloudflare absorbe la carga.
No todo vale para tunnels#
Cloudflare tiene Terms of Service que conviene leer. Lo relevante para homelabs:
- Puedes servir webs, APIs, dashboards, Gitea, analytics, y cualquier aplicación web.
- No deberías servir streaming de vídeo pesado (Plex/Jellyfin) por el tunnel con el plan gratuito. Cloudflare lo dice explícitamente: no usar como CDN de vídeo.
- Puedes servir imágenes y archivos pequeños sin problema.
Para Plex, la solución es Tailscale (acceso directo, sin pasar por Cloudflare).
Cloudflare Access: autenticación sin código#
Para servicios que quieres que sean accesibles desde Internet pero no públicos (un Portainer, un panel de admin), Cloudflare Access pone una página de login delante.
La configuras en Zero Trust → Access → Applications. Puedes autenticar con Google, GitHub, email con código OTP… sin tocar una línea de código en tu servicio.
Yo lo uso para el deployador: solo yo puedo acceder a deploy.tudominio.com. El resto del mundo ve una pantalla de login de Cloudflare.
Cloudflare Tunnels vs alternativas#
vs ngrok#
ngrok hace algo similar pero con limitaciones: URLs aleatorias en el plan gratuito, límite de conexiones, sin dominio propio gratis. Cloudflare Tunnels es superior en todos los aspectos para uso permanente.
ngrok es útil para demos rápidas de 5 minutos. Cloudflare Tunnels es para producción.
vs Tailscale Funnel#
Tailscale Funnel también expone servicios a Internet sin abrir puertos. La diferencia principal: Cloudflare te da tu propio dominio, CDN, cacheo, protección DDoS, y Access. Tailscale Funnel es más limitado pero no requiere un dominio.
Para servicios públicos serios, Cloudflare gana. Para compartir algo rápido con un colega, Tailscale Funnel es más ágil.
vs Caddy/Traefik + port forwarding#
Esto es lo que hacía antes. Caddy como reverse proxy con Let’s Encrypt automático, port forwarding en el router. Funcionaba, pero:
- Mi IP era pública y escaneable
- Tenía puertos 80 y 443 abiertos permanentemente
- Sin protección DDoS
- Si mi IP cambiaba, había un gap hasta que el DDNS se actualizaba
- Los certificados fallaban a veces y tenía que renovar manualmente
Con Cloudflare Tunnels, todos esos problemas desaparecen. Literalmente.
Mi configuración completa#
Para los que quieren ver cómo queda en la práctica:
| |
Eso es todo. Un contenedor. Una línea de comando. Y las rutas se configuran en el dashboard web de Cloudflare.
Cuando quiero añadir un servicio nuevo, voy al dashboard, añado una ruta (30 segundos), y funciona. Sin reiniciar nada, sin tocar ficheros de configuración.
Conclusión#
Cloudflare Tunnels ha cambiado fundamentalmente cómo expongo servicios de mi homelab. Lo que antes era un proceso tedioso y algo arriesgado (abrir puertos, configurar SSL, mantener DDNS) ahora es trivial y seguro.
La combinación Tailscale + Cloudflare Tunnels cubre el 100% de los escenarios de acceso a un homelab. Privado y público, sin abrir un solo puerto, con cifrado de extremo a extremo en ambos casos.
Si tienes un homelab y todavía tienes puertos abiertos en tu router, es hora de cambiar. Tardas 10 minutos en configurar un tunnel. Tardas mucho más en arreglar lo que pasa cuando alguien entra por un puerto que dejaste abierto.
Mi router tiene exactamente cero puertos abiertos y sirve 6 servicios públicos a Internet. Si me lo hubieras dicho hace tres años, no me lo habría creído.