Cloudflare Tunnel y Access para sacar los paneles admin de Internet

Con la zona ya bien blindada por la edge (WAF, rate limit, AOP, firewall por IPs de CF) seguía habiendo una pieza que no me gustaba, los paneles administrativos. El admin del blog vive detrás de la sesión de Better Auth y eso me deja tranquilo, pero el resto, el panel de Dokploy, el de Infisical, el dashboard de Umami para analítica, todos eran subdominios públicos en Cloudflare con Traefik enrutando a un servicio que servía un login. La autenticación está bien hecha en cada uno de ellos, pero el principio de mínima exposición decía otra cosa, un panel admin no debería ni siquiera responder a una petición HTTP de un visitante anónimo.

La opción evidente era Cloudflare Tunnel con Cloudflare Access delante. Hace que el VPS abra una conexión saliente al edge de Cloudflare y que el panel ni siquiera tenga DNS apuntando al origen. Antes de servir un solo byte, Access exige una identidad. Si no estás autenticado, ni llegas al login del panel.

Lo monté el 27 de abril de 2026 con tres pilotos en cascada, primero Umami, después Infisical, y al final Dokploy. Esta entrega cuenta el patrón y las trampas, que son menos obvias de lo que parece sobre todo cuando el panel también recibe webhooks externos.

Por qué Tunnel y no "abrir el puerto y poner una VPN"

Las alternativas que descarté.

• WireGuard al VPS, perfecta para uso técnico pero molesta cuando estás en el móvil de visita en casa de un amigo y solo quieres revisar un dashboard. Y si la conexión del VPS cambia de IP, hay que tocar peers.
• VPN comercial tipo Tailscale, igual de buena, pero supone meter un agente más en el VPS y mover la confianza a un tercero distinto al que ya estoy usando para todo lo demás. Como ya tengo Cloudflare delante de toda la zona, sumar Zero Trust de la misma cuenta consolida el modelo, no lo dispersa.
• WAF rules con allow-list por IP, frágil, mi IP cambia, y no protege del primer byte (CF sigue tocando el origen).
• Basic Auth en Traefik por delante del panel, suficiente para algunos casos, pero no para webhooks externos de GitHub o Telegram que también pasan por ese host. Y la identidad sigue siendo un secreto compartido, no una autenticación propiamente dicha.

El panorama completo de túneles, mesh y reverse proxy (cuándo conviene cada uno y cuándo no son sustitutos sino piezas distintas) lo dejo en SSH vs Cloudflare Tunnel vs Pangolin vs Tailscale vs Headscale vs WireGuard, qué uso para qué.

Cloudflare Tunnel con Access cumple cuatro cosas a la vez. El origen no acepta ninguna conexión entrante para esos hosts (literalmente no hay registro A público, el DNS resuelve a un CNAME interno de CF). La identidad se valida con un IdP serio (en Free, OTP por email es suficiente para mí). Las sesiones son centralizadas y revocables. Y todo se gestiona desde el mismo dashboard que ya uso para el resto de la zona.

Pieza única, un compose con cloudflared

El truco bonito de Tunnel es que necesitas exactamente un contenedor cloudflared en el VPS, da igual cuántos paneles enrutes después. Cada panel se añade desde el dashboard como Public Hostname dentro del mismo tunnel. Para que cualquier servicio del orquestador pueda ser destino, el contenedor de cloudflared tiene que estar en la red interna de Docker (en mi caso dokploy-network) y referenciar al servicio por nombre.

El compose vive como una entrada propia dentro del proyecto de infraestructura del orquestador, slug infrastructure-cf-tunnel, y es minúsculo.

services:
  cloudflared:
    image: cloudflare/cloudflared:2026.3.0
    restart: unless-stopped
    command: tunnel --no-autoupdate run
    environment:
      TUNNEL_TOKEN: ${TUNNEL_TOKEN}
    networks:
      - dokploy-network
networks:
  dokploy-network:
    external: true

El TUNNEL_TOKEN se genera en Zero Trust > Networks > Tunnels al crear el tunnel y se inyecta como variable de entorno desde la UI del orquestador. La imagen está fijada por versión (no latest) y --no-autoupdate evita que el binario se actualice por su cuenta sin que yo lo controle.

El nombre del tunnel en CF lo dejé como dokploy-vps-admin, lo cual deja claro su propósito y separa este tunnel de cualquier otro que pueda crear en el futuro para un caso distinto.

Añadir un panel nuevo, paso a paso

Una vez existe el tunnel, dar de alta un panel nuevo es siempre la misma rutina.

1. Public Hostname en el tunnel. En Zero Trust > Networks > Tunnels > dokploy-vps-admin > Public Hostname > Add a public hostname, indicas subdominio (analytics, secretos, dokploy...), dominio (tu-dominio.com), tipo HTTP y como URL el nombre del servicio en la red interna con su puerto interno. Para Umami fue umami:3000, para Infisical infisical-backend:8080, para Dokploy dokploy:3000. CF crea automáticamente un CNAME en la zona apuntando al tunnel.
2. Borrar el A o CNAME viejo si existía. Esto es crítico y tiene una trampa que cuento más abajo. Si el host ya pasaba por Traefik, antes de guardar el Public Hostname tienes que eliminar el registro DNS pre-existente, si no se queda en error.
3. Crear las Access Applications. Aquí va lo importante, no basta con una regla que pida login para todo. Para paneles que reciben webhooks externos (GitHub, Telegram, OAuth callbacks, healthchecks) hay que permitir el bypass de Access en esos paths concretos. Si no, los webhooks de tu propio orquestador acabarán recibiendo el formulario de OTP de CF como respuesta y todo se rompe en silencio.
4. Validar con curl que las rutas de bypass siguen respondiendo y que el catch-all redirige a Access.
5. Cutover de Traefik a tunnel ya está hecho desde que cambió el DNS al CNAME del tunnel. Las labels de Traefik en el compose del panel se quedan como red de seguridad. Tras 24 a 48 horas sin incidentes, las elimino con un edit del compose.

El orden de las Access Applications es lo que más cuesta

Una Application en Access es básicamente la pareja (host + path) → política. Una misma URL puede tener varias Applications, una por path, evaluadas de más específica a menos. La regla operativa que me funcionó es siempre la misma, crear primero los Bypass de los paths específicos y al final el catch-all que protege el resto. Si haces el catch-all primero y los bypass después, durante esos minutos los webhooks externos se rompen y el deploy automático del orquestador se queda parado.

Cada Bypass es una Self-Hosted Application con la política Bypass + Everyone. El catch-all es otra Self-Hosted Application con path vacío y política Allow + Emails = [email protected].

Caso 1, Umami (analítica del blog)

Umami sirve un dashboard privado pero el script público /script.js y el endpoint de tracking /api/send tienen que ser accesibles por todos los visitantes de mis sitios, sin OTP, evidentemente. Dos Bypass apps y un catch-all.

• Bypass analytics.tu-dominio.com/script.js, política Bypass + Everyone.
• Bypass analytics.tu-dominio.com/api/send, política Bypass + Everyone.
• Catch-all analytics.tu-dominio.com/*, Allow + Email [email protected].

Caso 2, Infisical (gestor de secretos)

Infisical es el caso más limpio. Las apps que consumen secretos (CV, Blog, ScamDetector...) no llaman al subdominio público, llaman a la red interna de Docker, http://infisical-backend:8080. Esa ruta nunca sale a Internet ni pasa por el tunnel, así que para Infisical solo hace falta el catch-all.

• Catch-all secretos.tu-dominio.com/*, Allow + Email.

Si tu setup llama a Infisical desde fuera del VPS, esto cambia (necesitarías un Service Token específico expuesto por una API distinta), pero todas mis integraciones son intra-host.

Caso 3, Dokploy (orquestador)

El más delicado. El panel de Dokploy es lo que menos quiero exponer, pero también es lo que recibe más webhooks externos legítimos. Tres Bypass apps y un catch-all.

• Bypass /api/deploy. Cubre tres rutas distintas que cuelgan de ahí, /api/deploy/github (webhook de la GitHub App, dispara el deploy de los proyectos con auto-deploy), /api/deploy/[refreshToken] (webhooks custom por aplicación) y /api/deploy/compose/[refreshToken] (webhooks custom por compose). Tengo 8 proyectos con autoDeploy: true, romper este path supone romper todos los deploys automáticos.
• Bypass /api/providers. OAuth callbacks de GitHub, Gitea y GitLab más el webhook /api/providers/github/webhook. Si lo cierras detrás de OTP, el OAuth flow falla, porque GitHub no resuelve un challenge de Cloudflare Access.
• Bypass /api/health. Healthchecks externos. Innecesario que pidan OTP.
• Catch-all /*, Allow + Email [email protected], sesión 24 horas, IdP One-time PIN.

Los tres Bypass los creé antes de tocar el DNS para el catch-all, así durante el cutover los webhooks ya estaban contemplados. Después confirmé que el deploy de un proyecto con autoDeploy seguía funcionando con un commit de prueba y que el OAuth de GitHub abría correctamente.

Identity Provider, OTP por email es suficiente para una persona

El plan Free de Zero Trust trae One-time PIN por email de serie. No requiere configuración, no necesita IdP externo, y para una persona con un solo email autorizado es perfectamente suficiente. Llega un código de 6 dígitos al correo, lo metes y entras.

Configuré la sesión a 24 horas. Es un equilibrio razonable, durante una jornada de trabajo no me piden OTP cada cinco minutos, y al día siguiente vuelve a pedir identidad. Con 1 sola persona en la cuenta el plan Free me sobra (admite hasta 50 usuarios).

El toggle de Aplicar autenticación instantánea que aparece en la UI no aporta nada cuando solo tienes un IdP activo, porque en ese caso CF aplica instant auth implícitamente y el formulario salta directo al campo de email sin pasar por una pantalla intermedia. Lo dejé OFF en los tres paneles y funciona igual. Solo lo activaría si en el futuro añado Google SSO y quiero forzar uno por defecto.

Verificación, curl con cache buster

El test que hago tras cada migración es siempre el mismo, una pasada de curl que distingue Bypass de catch-all. El parámetro ?nocache=$(date +%s) es importante, evita que un caché intermedio devuelva un 200 antiguo y te haga creer que la regla de Access no está activa.

# Bypass paths, deben dar 200 directo del origen
curl -sI "https://analytics.tu-dominio.com/script.js?nocache=$(date +%s)"
curl -sI "https://dokploy.tu-dominio.com/api/health?nocache=$(date +%s)"

# Catch-all, debe dar 302 a Access
curl -sI "https://dokploy.tu-dominio.com/?nocache=$(date +%s)"
# Esperado, location: https://tu-cuenta.cloudflareaccess.com/...

Si el catch-all no devuelve un 302 a cloudflareaccess.com sino que sirve el HTML del panel, algo no aplicó. Lo más habitual es que el orden de las Applications no sea el correcto, o que el bypass tenga un path mal copiado.

La trampa del DNS pre-existente

Esta me costó cinco minutos de confusión la primera vez. Si el host ya tiene un registro A o CNAME en la zona (porque hasta ahora pasaba por Traefik), al guardar el Public Hostname desde el dashboard del tunnel CF te da un error con un mensaje no muy claro sobre que el registro ya existe. La solución es ir a DNS > Records y borrar el registro viejo antes de guardar el Public Hostname. Una vez lo guardas, CF crea automáticamente el CNAME hacia el tunnel.

El detalle a recordar es que durante esos pocos segundos el host queda sin DNS. Para hosts no críticos no pasa nada, para algo como Dokploy donde tienes webhooks llegando a cada momento conviene hacerlo en una ventana tranquila o, mejor, primero crear las Bypass apps con un path absurdo de prueba para asegurarte de que estás en el orden correcto del flujo Access antes de mover el DNS de verdad.

Y los webhooks de servicios externos

El otro punto que merece atención es que los webhooks externos siguen llegando al edge de Cloudflare, simplemente vía CNAME al tunnel. Es decir, GitHub llama a https://dokploy.tu-dominio.com/api/deploy/github, CF resuelve a un endpoint del tunnel, el tunnel transporta la petición al servicio interno, el servicio responde, el tunnel devuelve la respuesta a CF, CF responde a GitHub. Cero puerto abierto en el VPS. Cero IP del VPS publicada. Y cero login expuesto.

El path se evalúa contra las Access Applications, hace match con el Bypass /api/deploy, política Bypass + Everyone, así que la petición pasa sin pedir identidad. La política aplica al método igual que al path, GitHub mandará un POST con cabeceras propias y firma HMAC, eso lo valida después el servicio interno. Cloudflare Access no entra en el proceso de autenticación del propio webhook. (Si ese servicio interno hace rate limit o verifica identidad por IP del cliente, ten presente el bug silencioso de cf-connecting-ip que conté en la entrega anterior, los webhooks viajan por IPs del edge de CF y la cabecera correcta es cf-connecting-ip.)

Rollback, dos escenarios

Mientras las labels de Traefik siguen en el compose del panel y el tunnel está activo en paralelo, el rollback es trivial.

• Antes de eliminar las labels, basta con restaurar el A record en DNS y el tráfico vuelve a Traefik en menos de 60 segundos. El tunnel sigue ahí pero no se usa hasta que el DNS no apunte de nuevo a su CNAME.
• Después de eliminar las labels, hay que redesplegar el compose con las labels de vuelta y restaurar el DNS. Cinco minutos como mucho.
• Si Access bloquea por error, borrar la app catch-all desde el dashboard de Zero Trust. El panel queda accesible sin OTP durante unos minutos hasta que diagnostico, lo cual es preferible a quedarse fuera del propio panel para arreglarlo.

Por eso la fase 6 (cutover de Traefik) la dejo a 24-48h, las labels son una red de seguridad inerte que no estorba mientras el tunnel funciona, y me deja un rollback rápido durante la ventana de observación.

Coste y límites del plan Free

Cero. Zero Trust Free admite hasta 50 usuarios, con OTP por email gratuito incluido. cloudflared es outbound only, así que tampoco hay coste de tunnel, era una limitación del antiguo Argo Tunnel y CF la quitó hace años. El tunnel es resiliente al cambio de IP del VPS, si mañana cambio de proveedor de hosting y el VPS arranca con otra IP pública, los paneles siguen siendo accesibles porque el tunnel se conecta saliente al edge de CF, no depende de qué IP tiene el origen.

El único límite que sí miro es el de Applications activas por cuenta, en Free es 50. Hoy uso 7 (4 catch-alls + 3 bypass), no es estrecho.

Lo que sigue

El panel que aún no migré es el de n8n. Es el más delicado de los tres porque sus webhooks no son de un proveedor concreto, son de cualquier integración que apunte a /webhook/* o /webhook-test/*. Bypass amplio en esos prefijos y catch-all en el resto será el mismo patrón, pero quiero hacer un inventario antes de mover la pieza, no vaya a ser que alguno de mis flujos use un path no estándar.

Para el home lab, donde el tráfico es más personal y no me apetece que circule por la edge de un tercero, no extiendo Cloudflare, voy con Pangolin como pieza self-hosted. Mismo modelo de túnel saliente con identidad delante, pero con todo el camino del dato bajo mi control.

Con esto cierro la serie de migración del VPS detrás de Cloudflare. Quedan piezas operativas (vigilar IPs banneadas en CrowdSec por Telegram, automatizar la rotación del token CF, tener una segunda VPS como worker remoto) pero pertenecen a su propia historia.