Túneles de Cloudflare

Esteban expone servicios internos a internet sin abrir puertos usando Cloudflare Tunnel (cloudflared).

vm-playground

Se quedó sin túnel propio el 2026-08-10 — tenía uno solo, vm-playground-glances (id 9513015a-60f4-4b22-8c5c-1072f0f9af33), eliminado por completo (servicio systemd, credenciales locales y el túnel en Cloudflare) al mudar sus tres hostnames a vm-main como parte del rediseño vm-producción/vm-workstation (ver hosts.md). notes.estebanalcocer.cloud (Trilium) no se migró — se dio de baja junto con el servicio, ver Trilium.

Túnel nuevo desde el 2026-08-15, único servicio de producción que corre en este host (excepción documentada en hosts.md): tunnel vm-playground (id b645f9f8-2cc9-4af9-95fd-73039c58d11f), servicio systemd cloudflared-estebanalcocer.service, config /etc/cloudflared/config-estebanalcocer.yml. El cert.pem de la cuenta estebanalcocer.cloud había sobrevivido en ~/.cloudflared/ desde el túnel anterior, así que crear este no requirió volver a autenticar la cuenta.

• dbhub.estebanalcocer.cloud → DBHub (127.0.0.1:8080)
• ehas.uk (apex, sin subdominio) → Homepage (127.0.0.1:8083), agregado 2026-08-26. Confirmado que un túnel de Cloudflare sí puede servir el apex de una zona — ver esa página para el diagnóstico erróneo (error 1034) que sugería lo contrario y por qué era inválido.

vm-main

Dos túneles corriendo en paralelo, cada uno como su propio servicio systemd — no un solo cloudflared.service genérico, porque un único proceso cloudflared tunnel run solo puede atender un túnel/config a la vez:

Servicio systemd	Túnel	Cuenta/zona	Hostnames
cloudflared-conkafecito.service	vm-main_oracle (8a10f093-...)	conkafecito.com	oci., glpi.
cloudflared-estebanalcocer.service	vm-main (25e646d4-...)	estebanalcocer.cloud (ehalsou@gmail.com) + ehas.uk (misma cuenta)	ver tabla de hostnames abajo

Hostnames actuales de cloudflared-estebanalcocer.service (todos apuntan a 127.0.0.1:<puerto> en vm-main, un solo config-estebanalcocer.yml):

Hostname	Servicio	Puerto
secrets.estebanalcocer.cloud, secrets.ehas.uk	Infisical	8082
lens.estebanalcocer.cloud, lens.ehas.uk	Glances	61208
monitor.estebanalcocer.cloud, monitor.ehas.uk, dashboard.estebanalcocer.cloud	Beszel	8090

Renombre 2026-08-16: dashboard. (Beszel) y monitor. (Glances) intercambiaron nombre — Beszel pasó a monitor., Glances pasó a lens. — y se agregó ehas.uk como dominio espejo de los tres servicios (mismo service: en el ingress, hostname extra por servicio). monitor.ehas.uk quedó fijado como dominio “canónico” de Beszel (APP_URL); dashboard.estebanalcocer.cloud se restauró como alias permanente después de que quitarlo tumbó a toda la flota de agentes de Beszel de un tirón — detalle completo del incidente y por qué los tres hostnames de Beszel quedan activos indefinidamente en Beszel § Incidente 2026-08-16. ehas.uk se administra con el mismo token de Cloudflare guardado en Infisical (CLAUDE_CODE_APPS_AND_POLICIES_DNS_ZONES, proyecto estebanalcocer.cloud, con alcance a las tres zonas de la cuenta: ehas.lat, ehas.uk, estebanalcocer.cloud) — necesario porque el cert.pem de cloudflared tunnel login para estebanalcocer.cloud no autoriza automáticamente una zona nueva de la misma cuenta; el primer intento de cloudflared tunnel route dns para ehas.uk sin ese token creó registros basura del tipo secrets.ehas.uk.estebanalcocer.cloud (el hostname anidado como subdominio de la zona sí autorizada) en vez de fallar limpio — mismo patrón de falla ya documentado en “Lección aprendida” más abajo, ahora confirmado también entre dos zonas de la misma cuenta, no solo entre cuentas distintas.

El túnel cloudflared-estebanalcocer.service es una recreación 2026-08-05 — el original con ese nombre (id a03d29ff-...) servía exclusivamente al media stack (tv., buscartv.) y se eliminó por completo junto con ese stack el 2026-08-04 (servicio systemd, registros DNS y el túnel en sí). Al reactivar Infisical se creó un túnel nuevo con el mismo nombre para el mismo rol (único túnel de vm-main en la cuenta estebanalcocer.cloud), pero id distinto. Infisical vivía antes en infisical.conkafecito.com (túnel de Conkafecito); esa ruta se retiró del ingress de cloudflared-conkafecito.service y su DNS al moverlo — el 2026-08-10 se encontró que la regla de ingress había quedado huérfana ahí pese a documentarse como retirada (el DNS sí estaba borrado, pero no la línea de ingress); se limpió al mismo tiempo que se sacaron portainer./zabbix./vault. (contenedores decomisionados, ver hosts.md).

Rediseño 2026-08-10 (producción/workstation): monitor. (Glances) y dashboard. (Beszel) se movieron acá desde el túnel de vm-playground, junto con sus contenedores. beszel-agent y glances-agent de este mismo host ya corrían nativos via systemd apuntando a la URL pública (HUB_URL=https://dashboard.estebanalcocer.cloud), así que la migración del hub fue transparente para ellos — no hizo falta tocar su config. vm-playground, al dejar de ser el host del hub de Beszel, necesitó un beszel-agent propio nuevo (antes usaba el agente local vía socket Unix del mismo compose del hub, que ya no aplica).

Registros DNS de portainer.conkafecito.com, zabbix.conkafecito.com y vault.conkafecito.com quedaron pendientes de borrado manual (cuenta Cloudflare de conkafecito.com, sin token de API en alcance para el agente) — sin ingress rule que los atienda, ya devuelven 404, pero conviene borrarlos igual la próxima vez que se entre a esa cuenta.

Cada túnel tiene su propio config-*.yml y credentials-file en /etc/cloudflared/. cert.pem en ~/.cloudflared/ sigue la sesión más reciente de cloudflared tunnel login — cuando se hizo login a la cuenta de estebanalcocer.cloud, el cert.pem de la cuenta anterior (conkafecito) se preservó automáticamente como cert-conkafecito.pem, necesario para administrar ese túnel por CLI (cloudflared tunnel --origincert <ruta> ...) después de cambiar de cuenta.

vm-personal

Túnel hub-ehalsou (id 0b5778b8-e1ff-4186-b706-6c6acbb56a8a), cuenta estebanalcocer.cloud — activo desde 2026-05-09 pero nunca documentado en esta página hasta ahora; se agrega el 2026-08-16 tras una auditoría de los registros DNS de la zona que además encontró y borró 8 subdominios huérfanos (ver hosts.md para el host).

• hub.estebanalcocer.cloud → detrás de Cloudflare Access (policy reusable “google project-vm-personal”); propósito exacto del servicio sin confirmar más allá de identificar el host.
• vault.estebanalcocer.cloud → Vaultwarden, sin Access delante (ya trae su propio login).

pop-os

Túnel propio, smart-home-t640-pop (id 29f6d085-6921-442a-9174-6e6dda957427), en vez de sumarse al de vm-playground — son máquinas distintas, cada cloudflared solo puede servir tráfico hacia servicios en su propio host:

• home.estebanalcocer.cloud → Home Assistant (localhost:8123)

Corre como servicio systemd (cloudflared service install), config en /etc/cloudflared/config.yml (no en ~/.cloudflared/, que es donde queda el cert/credenciales pero cloudflared service install corriendo con sudo no lo encuentra ahí por default).

ctunlinux

Un solo túnel, ctunlinux (id 0bf84666-69f3-4f53-b595-a36ab8956667), zona frento.com.mx (dominio de negocio de Trivasa, cuenta distinta de estebanalcocer.cloud/conkafecito.com) — mismo patrón que vm-playground: un cloudflared.service con varias reglas de ingress. Detalle completo en ctunlinux — servidor Docker de Trivasa BI.

• metabase.frento.com.mx → Metabase (localhost:3000)
• monitor.frento.com.mx → Glances, instancia standalone (127.0.0.1:61208) — no es el mismo hub que el resto de esta página; ctunlinux tiene NetBird desde 2026-08-09 pero esta instancia de Glances no se agregó a ese hub
• data.frento.com.mx → Perses, dashboard dummy de Soda + 2 con datos reales de DVT (127.0.0.1:8080)
• dash.frento.com.mx → Lightdash (127.0.0.1:8090)
• bot.frento.com.mx → varela-bot, bot de Telegram (127.0.0.1:8091)
• reportes.frento.com.mx → Streamlit reportes, ruteo por path (127.0.0.1:8501/8502/8503)
• reportesweb.frento.com.mx → agregado 2026-09-07, API REST de prueba ad-hoc (127.0.0.1:8765); ver ctunlinux para el detalle y el gotcha de quick tunnel reconfirmado ese mismo día

Esta tabla llevaba dos hostnames desactualizados que ctunlinux ya no lista: superset.frento.com.mx (decomisionado el 2026-08-09, la entrada del túnel sí se quitó en su momento) y explore.frento.com.mx (Hub Streamlit, decomisionado el 2026-08-26 — la entrada del túnel/DNS había quedado viva pese a la baja, corregido el mismo día). Corregido acá el 2026-08-26 tras notar la inconsistencia armando Homepage; bot.frento.com.mx se agregó la misma fecha, hallazgo nuevo sin registro previo.

Authentik corrió detrás de authentik.frento.com.mx hasta el 2026-08-09, cuando se decomisionó sin haber llegado a proteger ningún servicio — ver ctunlinux § Docker.

Auditoría 2026-08-15: 8 subdominios huérfanos borrados en estebanalcocer.cloud

De 21 registros DNS en la zona, 8 apuntaban a algo que ya no respondía: ubuntu-server. (CNAME a un túnel borrado por completo, ni aparecía en cloudflared tunnel list), odoo. y ssh. (mismo UbuntuSR250-tunnel, sin conexiones activas, sin ninguna mención en esta wiki), y sr250-biotime./sr250-contpaq./sr250-mpro./sr250-rds./sr250-ubuntu. (5 hostnames al túnel sr250, también sin conexiones — mismos nombres que las VMs de Hyper-V documentadas en hosts.md, pero esa tabla nunca las expone por hostname público, solo por NetBird). Los 8 se borraron vía API tras confirmar con Esteban.

Un noveno caso identificado el mismo día, sin registro DNS que borrar: la Access Application openproject-oci apuntaba a vm-op.estebanalcocer.cloud, hostname que ya no tenía ningún CNAME. Se confirmó con Esteban y se borró el 2026-08-16 (DELETE /accounts/.../access/apps/<id>) — a diferencia de los 8 casos de arriba, acá no había registro DNS que tocar, solo la Application huérfana en sí.

Mismo patrón, mismo día: la Access Application ssh-access (la más vieja de la cuenta, sin tocar desde 2026-02-22) apuntaba a ssh.estebanalcocer.cloud, uno de los 8 hostnames borrados arriba — quedó huérfana por la misma razón que openproject-oci y se borró también. Con esto, la cuenta queda con 5 Access Applications, todas activas y documentadas: trivasa, wiki, sr250 ssh, hub, y la Warp Login App (default del sistema, no asociada a un hostname propio).

vault.estebanalcocer.cloud se investigó en la misma auditoría por no estar documentada, pero resultó ser un servicio real y vivo — ver Vaultwarden, que se documentó a raíz de este hallazgo en vez de borrarse.

Seguimiento 2026-08-26: los túneles zombis en sí seguían sin borrarse

La auditoría de arriba borró los registros DNS y las Access Applications huérfanas, pero nunca los objetos de túnel subyacentes en Cloudflare — cloudflared tunnel list seguía mostrando UbuntuSR250-tunnel (8b7fe279-4b34-40fd-8a33-a6ecc377b7e0, sin conexiones desde 2026-02-22) y vm-op_tunnel (7a41e842-f35f-4989-a4cb-f2763e4f1b38, sin conexiones desde 2026-04-07). Se detectó al comparar cloudflared tunnel list contra el DNS real de las 3 zonas: ningún CNAME apuntaba ya a ninguno de los dos. Ambos se borraron con cloudflared tunnel delete <nombre> (CLI local, usa el cert.pem de la cuenta) — el token de API guardado en Infisical (CLAUDE_CODE_APPS_AND_POLICIES_DNS_ZONES) no tiene el scope de Cloudflare Tunnel, solo DNS/Access/Zones, así que DELETE /accounts/.../cfd_tunnel/<id> devuelve 1001 Not authorized con ese token — el CLI con cert es la única vía disponible desde este host para administrar túneles por su nombre/id. Quedan 5 túneles activos en la cuenta: hub-ehalsou, smart-home-t640-pop, sr250, vm-main, vm-playground.

sr250 (0cda661b-8e6f-4a8d-9e3d-dc42a055a6f6) también muestra 0 conexiones pero no se tocó — a diferencia de los dos de arriba, sí tiene DNS (sr250.estebanalcocer.cloud) y Access Application (sr250 ssh) activos y documentados; el 0 de conexiones probablemente refleja que el cloudflared del lado de sr250 (Windows) no está corriendo ahora mismo, no que el túnel esté huérfano — pendiente de investigar aparte si vuelve a salir en una auditoría futura.

Fuera de alcance en la misma pasada: portainer./zabbix./vault.conkafecito.com, ya confirmados huérfanos pero en la cuenta Cloudflare de Conkafecito, sin token ni cert en este host para esa cuenta.

Lección aprendida

Correr cloudflared tunnel route dns con el cert.pem/túnel equivocado para la zona del hostname no falla limpio: anida mal el hostname como subdominio de la zona que sí tiene ese certificado. Pasó una vez con conkafecito.com en vez de estebanalcocer.cloud, creando monitor.estebanalcocer.cloud.conkafecito.com en lugar de fallar con un error. Si vuelve a pasar, el registro mal creado se puede borrar vía la API de Cloudflare usando el token embebido en el cert.pem (es un JWT con zoneID/accountID/apiToken, decodificable con base64).

Véase también

• Glances — servicio expuesto por el túnel de vm-main desde el 2026-08-10 (antes vm-playground)
• Beszel — ídem
• Trilium — decomisionado el 2026-08-10, dejó de estar detrás de este túnel
• Media stack — servicios que expuso el túnel cloudflared-estebanalcocer original de vm-main, decomisionados el 2026-08-04 (el túnel se recreó el 2026-08-05 para Infisical)
• Infisical — servicio expuesto por el túnel cloudflared-estebanalcocer actual de vm-main
• DBHub — servicio expuesto por el túnel vm-playground nuevo (mismo nombre de servicio systemd, cloudflared-estebanalcocer, pero host y túnel distintos)
• Homepage — segundo hostname del túnel vm-playground, único caso de un túnel sirviendo el apex de una zona en vez de un subdominio
• Vaultwarden — servicio expuesto por el túnel hub-ehalsou de vm-personal, documentado por primera vez el 2026-08-16
• Home Assistant — servicio expuesto por el túnel de pop-os
• NetBird — alternativa usada para tráfico agente↔agente que no necesita ser público
• Cloudflare Access — cómo poner login delante de cualquiera de estos hostnames (o de uno que no use túnel, como la wiki)
• Claude Code remoto — visualizar outputs (Rich) desde el cel — uso de un túnel efímero (cloudflared tunnel --url) sin cuenta ni config, y por qué hay que aislarlo del config.yml de un túnel con nombre en el mismo host
• ctunlinux — detalle completo del host y todo lo que corre detrás de su túnel