Cloudflare Tunnel: acceso remoto sin abrir puertos, pero con control

Acceder desde fuera de casa a un panel de administración, una aplicación personal o una herramienta de automatización suele empezar con una idea arriesgada: abrir un puerto en el router y apuntarlo al servidor. Funciona, pero también coloca el servicio frente a escaneos, intentos de acceso y errores de configuración.

Cloudflare Tunnel propone otro modelo. Un proceso llamado cloudflared, instalado cerca de la aplicación, establece conexiones salientes hacia la red de Cloudflare. Las solicitudes entran por un nombre de dominio y viajan por ese túnel hasta el servicio interno. El router no necesita aceptar una conexión entrante directa.

Eso reduce exposición, pero no convierte automáticamente una aplicación insegura en segura. El túnel es transporte; la identidad, los permisos, las actualizaciones y la recuperación siguen siendo responsabilidad del administrador.

Qué cambia en la arquitectura

En una publicación tradicional, el visitante conecta con la dirección pública del router, una regla NAT reenvía el tráfico y el servidor escucha el puerto. Con Tunnel, cloudflared inicia el enlace desde dentro hacia fuera. La documentación oficial indica que utiliza conexiones salientes a la red global de Cloudflare mediante HTTP/2 o QUIC, normalmente por el puerto 7844.

El flujo simplificado es:

1. El usuario abre aplicacion.ejemplo.com.

2. Cloudflare recibe la solicitud.

3. Una política de Access puede comprobar identidad y requisitos adicionales.

4. Cloudflare envía el tráfico por una conexión ya establecida por cloudflared.

5. El conector lo entrega a una dirección local, por ejemplo http://localhost:8080.

El servicio puede permanecer sin dirección IP pública y el cortafuegos puede bloquear tráfico entrante. Solo las aplicaciones descritas en la configuración del túnel quedan asociadas a rutas públicas.

Lo que necesitas antes de crear el túnel

Necesitas un dominio gestionado en Cloudflare, una cuenta con acceso a Zero Trust, un equipo que pueda ejecutar cloudflared de forma continua y una aplicación interna que ya funcione localmente. Comprueba primero el servicio desde la misma máquina:

curl http://localhost:8080

Si falla en local, el túnel no lo arreglará. Verifica dirección, puerto, protocolo y certificados antes de añadir otra capa.

Elige además un nombre de host específico, como panel.ejemplo.com. No reutilices un subdominio destinado a otro servicio. Anota quién es responsable, qué datos procesa y cómo se desactivará si algo sale mal.

Crea un túnel administrado

En el panel Zero Trust, entra en la sección de redes y conectores, crea un túnel y selecciona Cloudflared. El panel proporciona un comando de instalación con un token. Ejecútalo solo en el equipo que actuará como conector y trata ese token como un secreto: no lo publiques en capturas, repositorios o documentación compartida.

Una vez conectado, añade un nombre de host público y define el servicio local de destino. Para una aplicación HTTP sin TLS dentro de la misma máquina, podría ser http://localhost:8080. Si el origen utiliza HTTPS, valida el certificado correctamente; desactivar la verificación para silenciar un error elimina una protección importante.

Cloudflare creará o asociará el registro DNS necesario. Espera a que el conector aparezca saludable y prueba el nombre desde otra red. Un estado conectado solo demuestra que cloudflared llega a Cloudflare, no que la aplicación responda bien.

Protege con Access antes de darlo por terminado

Un nombre público puede ser descubierto. Si la aplicación no debe ser pública, crea una aplicación de Access para ese dominio y configura una política explícita. Cloudflare Access evalúa quién puede alcanzar una aplicación mediante acciones, reglas y selectores.

Evita políticas que incluyan a “todo el mundo” o a cualquier correo válido. La documentación las señala como configuraciones que permiten acceso demasiado amplio. Para un servicio personal, limita por direcciones de correo concretas o por un grupo conocido del proveedor de identidad.

Añade autenticación multifactor. Access puede exigir el MFA informado por un proveedor compatible o aplicar MFA independiente. Para una consola sensible, una llave de seguridad ofrece mayor resistencia al phishing que un código reenviado. Ajusta también la duración de sesión: una sesión de semanas reduce la utilidad del segundo factor.

Mantén la autenticación propia de la aplicación siempre que sea posible. La capa de Access protege la entrada, pero una defensa adicional reduce el impacto de una política equivocada o una ruta que quede fuera de cobertura.

Comprueba que no existe una puerta lateral

Después de activar el túnel, verifica que el viejo acceso directo ya no funciona. Elimina la regla de reenvío de puertos del router si existía y confirma desde una red externa que la dirección pública no responde en ese puerto.

Revisa también interfaces alternativas. Una aplicación puede escuchar en todas las interfaces de la red local cuando solo necesita localhost. Limitar el enlace reduce exposición dentro de la propia LAN.

En el cortafuegos puedes adoptar un modelo positivo: bloquear conexiones entrantes y permitir únicamente las salientes que necesita cloudflared. Cloudflare documenta los destinos y el puerto 7844 para TCP y UDP. No copies listas de direcciones antiguas; consulta la referencia vigente y adapta las reglas al tipo de cortafuegos.

Alta disponibilidad y fallos previsibles

Si el único conector se apaga, el acceso desaparece. Para un servicio importante, ejecuta conectores adicionales del mismo túnel en máquinas o zonas de fallo diferentes. No instales dos procesos en un único equipo y lo llames redundancia: una avería eléctrica los detendría a ambos.

Prueba estos escenarios:

• detener cloudflared y observar el error recibido;

• reiniciar el equipo y confirmar que el servicio arranca automáticamente;

• detener la aplicación mientras el túnel continúa conectado;

• retirar un usuario de la política de Access;

• caducar la sesión y exigir una nueva autenticación;

• restaurar la configuración en otro equipo.

Los mensajes deben distinguir entre fallo del conector, origen no disponible y acceso denegado. Esa diferencia acelera el diagnóstico.

Registros, privacidad y dirección del cliente

Conserva registros suficientes para saber quién accedió, qué política se aplicó y si el conector perdió conexión. Define retención y protege esos registros: pueden revelar nombres de host, cuentas, horarios y rutas internas.

El origen ya no recibe siempre la conexión directamente del visitante. Para HTTP, Cloudflare indica que la dirección original se transmite mediante la cabecera CF-Connecting-IP. Solo confíes en esa cabecera cuando la solicitud haya llegado por la ruta controlada; un cliente directo podría falsificarla si conserva otra entrada al servidor.

Un túnel tampoco cifra datos que tu aplicación escriba en disco. Aplica permisos, cifrado y minimización según el contenido. El hecho de no abrir puertos no sustituye la protección de la base de datos.

Actualizaciones y recuperación

Mantén cloudflared, el sistema operativo y la aplicación actualizados. Prueba cambios en un entorno separado cuando el servicio sea crítico y conserva una forma rápida de volver a la versión anterior.

Haz copias de la configuración de la aplicación y documenta el mapeo entre hostname, túnel y servicio interno. No incluyas tokens sin protección en el respaldo. Si un token se filtra, rótalo desde el panel y vuelve a instalar los conectores afectados.

Prepara un procedimiento de emergencia: desactivar el hostname público, retirar la política, detener el conector y revocar credenciales. La seguridad también consiste en poder cerrar el acceso con rapidez.

Lista de comprobación final

• La aplicación funciona localmente antes de crear el túnel.

• No quedan puertos de entrada abiertos para el mismo servicio.

• El hostname solo apunta al origen previsto.

• Access limita usuarios concretos y exige MFA cuando corresponde.

• La autenticación interna de la aplicación permanece activa.

• El token del túnel no aparece en repositorios ni capturas.

• Los conectores arrancan tras reiniciar y existe redundancia si es necesaria.

• Los registros tienen retención y acceso restringidos.

• Hay copias verificadas y un procedimiento de revocación.

Cloudflare Tunnel elimina una exposición habitual y facilita conectar servicios sin una IP pública enrutable. Su ventaja real aparece cuando forma parte de un diseño completo: salida controlada, identidad explícita, mínimo privilegio, supervisión y recuperación. El objetivo no es que la aplicación “se vea desde Internet”, sino que únicamente las personas autorizadas puedan alcanzarla y que puedas demostrarlo.

Fuentes oficiales

• Opciones de conectividad de Cloudflare One

• Descargar e instalar cloudflared

• Tunnel con reglas de cortafuegos

• Políticas de Cloudflare Access

• Administrar políticas de Access

• Exigir autenticación multifactor

n8n desde cero: crea un resumen automático de tus fuentes RSS

Seguir blogs, avisos de seguridad y páginas técnicas suele producir el mismo problema: demasiadas pestañas y novedades repetidas. RSS ofrece una solución abierta y sencilla, pero leer varias fuentes manualmente continúa consumiendo tiempo. Con n8n podemos convertirlas en un resumen periódico sin empezar por una automatización enorme ni entregar decisiones importantes a una inteligencia artificial.

El flujo de esta guía hará cuatro cosas: se ejecutará a una hora concreta, leerá una fuente RSS, descartará elementos que no interesan y enviará una lista breve. Después añadiremos control de duplicados, gestión de errores y límites de seguridad. El objetivo no es copiar una plantilla a ciegas, sino comprender cada paso y poder verificarlo.

Qué es n8n y dónde ejecutarlo

n8n es una herramienta de automatización visual basada en nodos. Cada nodo recibe datos, realiza una operación y entrega resultados al siguiente. Puede utilizarse como servicio gestionado o instalarse en infraestructura propia. La documentación oficial ofrece opciones con npm y Docker, pero advierte que el autoalojamiento exige conocimientos de servidores, contenedores, seguridad y copias de respaldo.

Para aprender, utiliza una instancia de prueba o un entorno local que no esté expuesto directamente a Internet. Si lo instalas con Docker, conserva el volumen de datos: destruir un contenedor sin almacenamiento persistente puede llevarse configuraciones, credenciales e historial. Para producción necesitas además HTTPS, actualizaciones, autenticación y un plan de recuperación.

No introduzcas todavía cuentas personales importantes. Podemos comprobar el flujo con una fuente pública y una salida temporal antes de conectar correo, mensajería o bases de datos.

Diseña el resultado antes de los nodos

Una automatización fiable comienza definiendo qué debe producir. Nuestro resumen incluirá como máximo cinco artículos, cada uno con título, fecha y enlace. Solo aparecerán elementos de las últimas 24 horas y no se repetirá un enlace ya enviado.

También necesitamos decidir qué ocurre cuando no hay novedades: lo más razonable es no enviar nada. Un mensaje diario que dice “sin cambios” acaba convirtiéndose en ruido. En cambio, un fallo de lectura sí debe quedar registrado para poder investigarlo.

El esquema será:

1. Schedule Trigger inicia el flujo una vez al día.

2. RSS Read descarga los elementos de la fuente.

3. Filter conserva solo los recientes o relevantes.

4. Remove Duplicates evita repetir enlaces.

5. Limit deja un máximo de cinco.

6. Un nodo de correo o mensajería entrega el resumen.

Los nombres exactos pueden cambiar ligeramente entre versiones, pero el patrón permanece: disparar, leer, filtrar, limitar y entregar.

Paso 1: programa la ejecución

Crea un flujo nuevo y añade Schedule Trigger. Elige una ejecución diaria y una hora en la que el destino esté disponible. Comprueba la zona horaria de la instancia: si el servidor usa UTC y tú esperas horario peninsular, el resumen llegará desplazado y el cambio de hora puede sorprenderte.

Mientras construyes, no actives el flujo. Ejecuta los nodos manualmente. Así evitas envíos accidentales cada vez que modificas una condición.

Paso 2: lee una fuente pública

Añade RSS Read e introduce la URL de un canal que conozcas. Ejecuta solo ese nodo y examina la salida. Normalmente encontrarás campos como título, enlace, fecha de publicación y contenido. No asumas sus nombres: las fuentes RSS y Atom pueden variar.

El panel de datos permite arrastrar campos de un nodo anterior a los parámetros posteriores. n8n denomina a esto mapeo de datos. Usa el campo que contiene el enlace como identificador principal; el título puede cambiar y dos artículos distintos podrían compartir uno parecido.

Empieza con una sola fuente. Para incorporar varias, prueba cada una por separado y une los resultados después. Si conectas diez fuentes a la vez, será más difícil saber cuál entrega una fecha extraña o un documento mal formado.

Paso 3: filtra por fecha y palabras

Añade un nodo Filter. Conserva los elementos cuya fecha esté dentro del periodo elegido. Si una fuente no proporciona fecha fiable, decide explícitamente si se acepta o se descarta; no permitas que un valor vacío se interprete como una noticia nueva.

Puedes añadir palabras clave, por ejemplo “seguridad”, “automatización” o el nombre de una tecnología. Prueba mayúsculas, acentos y variaciones. Un filtro demasiado estricto puede ocultar contenido útil, por lo que conviene registrar durante unos días qué elementos descarta.

El filtrado determinista tiene una ventaja: puedes explicar por qué entró cada artículo. Si más adelante añades un modelo de IA para clasificar o resumir, mantén el enlace y el texto original, limita el tamaño de entrada y trata la respuesta como una propuesta, no como una fuente.

Paso 4: evita duplicados de verdad

El nodo Remove Duplicates puede eliminar repetidos dentro de una ejecución comparando el enlace. Sin embargo, para evitar que el resumen de mañana vuelva a incluir lo enviado hoy necesitas comparar ejecuciones o guardar identificadores en un almacén persistente.

La solución depende de la edición y del entorno: una tabla de datos, una base de datos sencilla o un registro externo pueden conservar el enlace y la fecha de envío. La regla esencial es escribir el identificador solo después de confirmar la entrega. Si lo guardas antes y el correo falla, el artículo quedará marcado como enviado aunque nadie lo haya recibido.

Aplica además una caducidad. No necesitas conservar para siempre todos los enlaces de una fuente diaria; unas semanas o meses suelen bastar. Esta limpieza reduce espacio y evita que el historial se convierta en otra tarea pendiente.

Paso 5: limita y construye el mensaje

Ordena los elementos por fecha descendente y utiliza Limit para conservar cinco. Después genera un bloque con título y enlace. Evita insertar directamente HTML procedente del RSS en un correo: podría contener estilos inesperados, imágenes remotas o contenido que no deseas reenviar.

El mensaje puede adoptar esta forma:

Novedades de hoy

1. Título del artículo
   https://ejemplo.com/articulo

2. Otro título
   https://ejemplo.com/otro

Conecta una salida de prueba y envíate un único mensaje. Verifica enlaces, orden, caracteres especiales y longitud en el teléfono. Solo entonces configura el destino definitivo.

Credenciales: menos permisos y nada de secretos pegados

n8n dispone de un sistema de credenciales para no escribir contraseñas o tokens directamente dentro de los nodos. Crea una credencial distinta para cada servicio y concede solo los permisos necesarios. Un flujo que envía mensajes no debería tener capacidad para borrar el buzón.

No publiques exportaciones de flujos sin revisarlas. Aunque n8n maneje las credenciales por separado, un archivo puede revelar URLs internas, nombres de proyectos, expresiones o ejemplos de datos. Mantén privados los repositorios que contengan configuraciones operativas.

En una instalación propia, define y conserva una clave de cifrado estable siguiendo la documentación. Si pierdes esa clave o el volumen de datos, recuperar credenciales puede resultar imposible. Incluye ambos elementos en tu estrategia de respaldo, protegidos de forma adecuada.

Errores, reintentos y trazabilidad

La vista Executions muestra ejecuciones correctas, fallidas, en espera o activas. n8n permite reintentar una ejecución con el flujo original o con la versión guardada actualmente. Antes de reintentar una entrega, comprueba si el mensaje llegó: repetir a ciegas puede generar duplicados.

Configura un flujo de error que avise por un canal diferente al destino principal. Registra la fuente, la hora y el nodo que falló, pero no incluyas tokens ni contenidos sensibles en el aviso. Establece también tiempos máximos; una petición bloqueada no debería mantener el proceso indefinidamente.

La auditoría de seguridad de n8n puede señalar credenciales sin uso, webhooks desprotegidos, ajustes ausentes, versiones antiguas y nodos de riesgo. Es una ayuda, no una garantía. Revisa especialmente los nodos que ejecutan código, acceden al sistema de archivos o instalan extensiones comunitarias.

Lista de comprobación antes de activar

• La zona horaria y la frecuencia son correctas.

• El flujo no envía nada si no hay resultados.

• Cada fuente se ha probado de forma independiente.

• Los duplicados se controlan entre ejecuciones.

• El máximo de elementos evita mensajes interminables.

• Las credenciales tienen permisos mínimos.

• Existe una ruta de error y se ha provocado un fallo de prueba.

• La instancia, el volumen y la clave de cifrado tienen respaldo.

• Los datos históricos tienen una política de eliminación.

Activa el flujo y revisa sus primeras ejecuciones. No des por terminada una automatización porque funcionó una vez. Observa qué ocurre cuando una fuente responde lentamente, cambia un campo o publica diez elementos juntos.

Una base que puede crecer sin perder control

Cuando el resumen sea estable, añade una segunda fuente, categorías o distintos destinos. También puedes incorporar una aprobación humana antes de enviar, o utilizar IA para redactar una síntesis. Hazlo después de conservar los originales y establecer límites de coste, longitud y tiempo.

El valor de n8n no está en dibujar muchos nodos, sino en hacer visible el recorrido de los datos. Un flujo pequeño con entradas conocidas, deduplicación, registros y recuperación de errores ahorra más tiempo que una cadena espectacular que nadie se atreve a modificar.

Fuentes oficiales

• Documentación oficial de n8n

• Instalación de n8n con Docker

• Mapeo de datos en la interfaz

• Ejecuciones y reintentos

• Auditoría de seguridad

• Configurar una clave de cifrado