Cloudflare Tunnel como alternativa a la apertura de puertos

Explicación de Cloudflare Tunnel sin apertura de puertos

En una apertura de puertos clásica, un cliente externo se conecta directamente a la dirección IP pública del router o del servidor. A continuación, el router reenvía el tráfico entrante a un servicio de la red interna. Un Cloudflare Tunnel invierte este proceso de establecimiento de la conexión: el conector cloudflared Se ejecuta en la red interna accesible y establece por sí mismo conexiones salientes con Cloudflare.

Si, por ejemplo, un usuario accede a un portal de administración, Cloudflare recibe la solicitud correspondiente a su nombre de host y la reenvía al conector a través de una conexión de túnel ya existente. Este llega al servicio de destino configurado, por ejemplo: http://localhost:8080. Por lo tanto, el Origin no necesita ni una dirección IP accesible directamente desde Internet ni una excepción de entrada en el cortafuegos para este servicio.

Esto no significa que ya no haya que seguir las normas de red. El host con cloudflared Cloudflare debe poder conectarse con el exterior. Cloudflare especifica para ello el puerto 7844 a través de TCP o UDP; para ello se utilizan HTTP/2 o QUIC, respectivamente. El tráfico saliente debe estar permitido en el cortafuegos local, en el router y, si procede, a través de un proxy de la empresa. Esa es la limitación práctica que se esconde tras la afirmación „sin apertura de puertos“.

Una entrada DNS por sí sola no crea esta vía de conexión protegida. El DNS solo asigna un nombre a una dirección de destino; no inicia ninguna conexión desde la red privada ni proporciona ningún servicio local. El Conector de salida es el componente clave: conoce el servicio de destino interno y mantiene abierta la ruta hacia él, de dentro hacia fuera. La configuración de qué usuarios pueden utilizar esta ruta debe realizarse por separado.

Un túnel no es una medida de protección de acceso

Un túnel reduce la visibilidad directa en la red del origen, pero no decide por sí mismo sobre los permisos. Si se redirige un panel de administración web a través de un nombre de host público, cualquier usuario de Internet puede acceder a él sin necesidad de una aplicación Access previa. Por ello, Cloudflare recomienda configurar Access antes de la ruta del túnel en producción. El túnel es la vía de transporte, no el control de acceso.

Para un panel de administración con privilegios, debería haber una Política de acceso Permitir únicamente a personas o grupos claramente definidos. Además de los criterios «Include», «Require» y «Exclude», se dispone de acciones como «Allow», «Block», «Bypass» y «Service Auth». La autenticación multifactorial (MFA) puede exigirse a través de un proveedor de identidad conectado o como factor adicional. Una regla general para todas las cuentas de un dominio de correo electrónico suele ser demasiado amplia para las interfaces con privilegios elevados.

La capa de acceso complementa, pero no sustituye, el refuerzo de la seguridad de la aplicación. El panel de administración sigue requiriendo un inicio de sesión seguro, actualizaciones puntuales, normas de sesión adecuadas y una concesión de derechos moderada. Las cuentas de usuario locales, los roles y los derechos de administración también siguen siendo fundamentales: si un usuario obtiene acceso a la aplicación tras iniciar sesión en Access, no debe recibir automáticamente derechos administrativos más amplios en ella.

Además, hay que comprobar si la aplicación valida los tokens de acceso o si utiliza la opción de túnel prevista para la verificación de tokens. Esto vincula la aplicación a la verificación de identidad previa y reduce los riesgos derivados de una vía de acceso alternativa e involuntaria al origen. Es recomendable aplicar una estructura por capas: publicación restrictiva, verificación de identidad con autenticación multifactorial (MFA), derechos mínimos de la aplicación y un servicio de destino accesible internamente, pero no expuesto al público en general.

Clasificar HTTP, SSH, RDP y TCP

Las aplicaciones HTTP(S) y los protocolos de administración tienen distintos modelos de acceso. Una interfaz web interna se puede publicar mediante un nombre de host y protegerse frente al origen con Access. SSH, RDP y determinados servicios TCP también pueden ser accesibles a través de túneles, pero, dependiendo del método, requieren software adicional en el lado del cliente o un acceso basado en navegador. El hecho de iniciar sesión a través de la web no implica automáticamente un acceso nativo a la red.

Para SSH con el terminal local habitual, se puede utilizar en el lado del cliente cloudflared Establecer la conexión junto con Access. Además, Cloudflare documenta el SSH renderizado por el navegador como una vía de acceso independiente. Ambas variantes difieren en cuanto al flujo de trabajo del cliente, la configuración local de SSH y el manejo; por lo tanto, no son intercambiables de forma generalizada. Las afirmaciones sobre modelos de infraestructura o certificados más avanzados solo deben incluirse en una planificación si se ha comprobado por separado la documentación actual y pertinente al respecto.

Un terminal SSH renderizado en el navegador puede resultar práctico para la asistencia técnica o para un acceso de emergencia urgente, cuando no se dispone de un cliente SSH local preparado. No obstante, antes de su uso, es necesario evaluar los requisitos de auditoría, los procedimientos operativos, los métodos de claves locales y las transferencias de archivos. El RDP y otros servicios TCP también deben analizarse caso por caso, en lugar de tratarlos de forma generalizada como si se tratara de una interfaz web.

Tunnel no es un sustituto completo para cualquier conexión de red. No es compatible con protocolos iniciados por el servidor, como VoIP o SIP; además, las sesiones TCP de larga duración y sensibles a las interrupciones requieren una comprobación de idoneidad. Además, en el caso de SSH, RDP y TCP, el Origin no ve la IP original del cliente, sino el conector. En HTTP, una aplicación puede CF-Connecting-IP evaluar. Las listas de permitidos basadas en direcciones IP y los registros forenses deben tener en cuenta este límite.

Asignar varios servicios de forma segura

Un archivo Ingress local asigna cada nombre de host publicado a un único destino interno. Es recomendable utilizar nombres distintos para el panel de administración y SSH: de este modo, los permisos, los registros y los cambios posteriores quedan claramente diferenciados entre sí. Cloudflared evalúa las reglas de arriba abajo; la primera regla que coincida determina el destino.

El siguiente ejemplo es una plantilla de configuración para un túnel gestionado localmente. Utiliza deliberadamente example.invalid y no contiene ni datos de acceso ni un dominio real. El servicio web se limita a localhost:8080 accesible; las conexiones SSH se redirigen al servicio SSH local.

tunnel: <TUNNEL-UUID>
credentials-file: /etc/cloudflared/<TUNNEL-UUID>.json

ingress:
  - hostname: admin.example.invalid
    service: http://localhost:8080
  - hostname: ssh.example.invalid
    service: ssh://localhost:22
  - service: http_status:404

La última regla es la siguiente: Regla general. Es necesaria para los archivos locales de Ingress y aquí se encarga de http_status:404 para garantizar que un nombre de host desconocido no acabe por error en el primer servicio interno o en cualquier otro. Un reenvío estándar general supondría un riesgo innecesario, especialmente en el caso de destinos administrativos.

El archivo define únicamente la ruta desde el túnel hasta Origin. No configura entradas DNS ni protege los nombres mediante Cloudflare Access. Por lo tanto, antes de establecer una ruta en producción, es necesario configurar por separado el nombre de host y la política de acceso. Además, a nivel local, los puertos de destino solo deben ser accesibles allí donde Cloudflare los necesite realmente.

Antes de iniciar el proceso, se puede comprobar el orden sin modificar la configuración. El primer comando valida la configuración de Ingress; el segundo muestra qué regla se aplicaría a la dirección indicada.

cloudflared tunnel ingress validate
cloudflared tunnel ingress rule https://admin.example.invalid

Seleccionar de forma selectiva los accesos SSH

El acceso SSH a través de un túnel no es una vía de acceso única. La variante adecuada depende de si los administradores siguen utilizando su terminal local o si, en caso de avería, tienen que trabajar sin un cliente preparado. Los modelos disponibles se diferencian en cuanto al cliente, la identidad y el procedimiento de uso; la configuración concreta de SSHD y la gestión de derechos locales son independientes de ello.

Para un equipo pequeño que trabaja habitualmente con herramientas locales conocidas, a menudo resulta adecuado el uso de Cloudflare del lado del cliente: el puerto SSH sigue siendo interno, mientras que Access establece una capa adicional de identidad antes de establecer la conexión. Sin embargo, esto no es lo mismo que una gestión centralizada de todos los permisos SSH.

El acceso a través del navegador debe considerarse un proceso independiente. Puede resultar útil en casos de asistencia técnica o de acceso no planificado, ya que no requiere tener configurado un cliente SSH. Sin embargo, no es un método de administración mejor en todos los casos: las transferencias de archivos, los procesos habituales con claves locales y los requisitos de auditoría pueden hacer que un cliente de terminal o un acceso privado resulten más adecuados.

Independientemente de la ruta, las capas de protección locales se mantienen. Cuentas de Linux, Reglas de sudo, la configuración del SSHD y los permisos del sistema de destino siguen determinando lo que puede hacer un usuario que haya iniciado sesión correctamente. El túnel no sustituye ni a estas reglas ni a una asignación limitada de permisos.

Para los servicios publicados que no sean HTTP, puede ser necesario utilizar Cloudflared en el lado del cliente; además, SSH ofrece acceso a través del navegador. Por lo tanto, RDP y otros servicios TCP no deben planificarse precipitadamente siguiendo el modelo de SSH, sino teniendo en cuenta sus respectivos requisitos de cliente y de funcionamiento.

Túnel, VPN, bastión o apertura de puertos

La elección no solo se refiere a si un puerto está abierto, sino también al alcance deseado del acceso. Cloudflare Tunnel es especialmente adecuado para unos pocos servicios claramente definidos. Por el contrario, quien necesite acceder a muchos sistemas internos y segmentos de red suele necesitar un modelo de acceso a la red privada en lugar de un conjunto de publicaciones individuales.

La apertura clásica de puertos no es, en principio, incorrecta. Puede ser adecuada para un servicio público deliberadamente abierto, en el que la protección de las aplicaciones, el funcionamiento del cortafuegos y la accesibilidad pública se gestionan de forma específica. A diferencia de esto, en el túnel, el conector establece la conexión desde la red interna; no es necesario acceder directamente al origen desde Internet.

Para un único panel de administración o un pequeño conjunto de objetivos de mantenimiento, una publicación basada en servicios con acceso basado en la identidad suele ser más fácil de delimitar que un túnel de red completo. Esto no exime de comprobar el protocolo: no se admiten los protocolos iniciados por el servidor, y las sesiones TCP largas y sensibles a las interrupciones pueden requerir otros modelos de conectividad.

Una VPN sigue siendo útil cuando los empleados necesitan varias aplicaciones privadas, rangos de direcciones o dependencias internas. Por el contrario, un servidor bastión concentra los accesos SSH en un único punto de entrada, que a su vez debe estar cuidadosamente protegido y gestionado. Un proxy inverso, por su parte, es una capa para la terminación TLS y la entrega de aplicaciones; no responde por sí solo a la pregunta de cómo se accede al origen privado. Las funciones de proxy, servidor de aplicaciones y gestor de procesos también pueden integrarse en el Comparación entre NGINX Unit y PHP-FPM Compréndelo.

Por lo tanto, la decisión práctica comienza con una delimitación: ¿qué personas necesitan acceso a qué servicio y con qué cliente? Cuanto más limitada sea esta respuesta, más fácil resultará gestionar un túnel con nombres de host y reglas precisos. Sin embargo, unas necesidades de red amplias, protocolos especiales o requisitos elevados en cuanto a la estabilidad de las sesiones abogan por una evaluación específica.

Garantizar la seguridad de los túneles durante su funcionamiento

Un túnel activo no consiste en una única conexión puntual. Cloudflare documenta, para cada túnel «cloudflared», cuatro conexiones salientes de larga duración con al menos dos de sus propios centros de datos. Por lo tanto, si falla una ruta de conexión concreta, las solicitudes pueden dirigirse a través de otra ruta existente. Esto reduce las dependencias en la ruta entre el conector y Cloudflare, aunque no garantiza por sí mismo una alta disponibilidad del servicio interno.

En el caso de aplicaciones críticas, varias instancias de cloudflared pueden utilizar el mismo túnel como réplicas. Esto crea rutas adicionales desde la red de Cloudflare hasta la red privada, pero no sustituye ni a una aplicación redundante ni a una estrategia de bases de datos o de servidores. Por ejemplo, si el único servidor con el panel de administración no está disponible, los conectores adicionales en ese u otros servidores solo serán de ayuda si realmente pueden acceder al servicio de destino que funciona correctamente. Ruta de conexión Por lo tanto, la disponibilidad de los servicios debe planificarse por separado.

Si se desea comprobar de forma selectiva varios orígenes, evitarlos en caso de fallos o distribuirlos según unas reglas, es necesario un equilibrio de carga adicional con comprobaciones de estado y redireccionamiento del tráfico. Un túnel por sí solo no toma estas decisiones en profundidad. Además, la arquitectura debería establecer cómo se restablece el servicio de destino tras una interrupción y si se sigue necesitando acceso administrativo durante la interrupción.

La disponibilidad no se limita al software. Si el conector y el sistema de destino se encuentran en una sala técnica propia, el suministro eléctrico, la refrigeración, la calidad del aire y las inspecciones periódicas también deben formar parte del plan de funcionamiento. Los riesgos ambientales adicionales que pueden surgir en este contexto se ponen de manifiesto al analizar la Ventilación de una sala de servidores en el sótano. Estas medidas no sustituyen a las réplicas, pero evitan que todas las rutas de conexión previstas fracasen debido a la misma dependencia de la infraestructura local.

Las actualizaciones de cloudflared deben realizarse durante una ventana de mantenimiento programada: provocan un reinicio y, por lo tanto, pueden afectar al tráfico que se esté gestionando en ese momento. Cloudflare propone el equilibrio de carga o el uso de varias instancias de cloudflared como opciones para realizar actualizaciones sin interrupciones. El método de actualización más adecuado depende del tipo de instalación y del entorno operativo, y debe documentarse antes de la ventana de mantenimiento.

Para cada actualización, documenta la versión instalada, el host responsable, una ruta alternativa y una prueba de accesibilidad para el servicio de destino. Tras el reinicio, comprueba no solo el estado del túnel, sino también si la regla de Ingress definida llega al servicio esperado y si la capa de acceso prevista sigue siendo válida. De este modo, el conector, el servicio de destino y la ruta de autorización se mantienen como tareas operativas independientes y trazables.

Detectar a tiempo los errores típicos de configuración

Antes de la puesta en marcha, hay que empezar a buscar errores en el conector: el host debe poder conectarse a Cloudflare desde el puerto 7844 mediante TCP o UDP. Es previsible que falte una apertura de puerto entrante, pero no un cortafuegos de salida que bloquee de forma generalizada. Solo cuando cloudflared pueda establecer las conexiones salientes, merecerá la pena examinar el DNS, los nombres de host y las reglas de acceso a nivel de aplicación.

1. Comprobar la accesibilidad local: El servicio mencionado en la regla de Ingress debe ser accesible desde el host «cloudflared» a través del punto final local o interno especificado.
2. Sincronizar el DNS y Ingress: el nombre de host público debe coincidir con la ruta del túnel prevista; el orden de las reglas debe hacer que el servicio concreto se aplique antes que las reglas más generales.
3. Probar la regla «catch-all»: una regla final con http_status:404 evita que los nombres de host no previstos se reenvíen a un servicio predeterminado.
4. Configurar Access antes de su puesta en producción: solo entonces se podrá comprobar de forma controlada la ruta externa con una cuenta autorizada y otra no autorizada.

Un error de seguridad habitual es establecer una ruta demasiado amplia: en lugar de permitir el acceso únicamente a un panel de administración o a un servicio SSH concreto, se permite el acceso a un ámbito de red más amplio. Igualmente arriesgadas son las reglas generales sobre dominios de correo electrónico para interfaces con privilegios. En el caso de los accesos de administración, se debe garantizar que los grupos sean reducidos y verificables, que los criterios de requisito sean adecuados y que la autenticación multifactorial (MFA) refleje el círculo real de personas autorizadas. Autorización mínima Esto también implica no agrupar innecesariamente nombres de host y servicios de destino distintos.

La configuración de túneles y de permisos resuelve tareas diferentes. La regla de Ingress determina hacia dónde se dirige una conexión ya establecida; Access decide quién se autentica y autoriza antes de ello. Sin una aplicación Access adecuada, un nombre de host HTTP publicado puede ser accesible desde Internet. Por lo tanto, las cuentas locales, las reglas de «sudo», la configuración de SSHD y el refuerzo de la seguridad de la aplicación siguen siendo, por ello, puntos de verificación independientes.

El límite de la IP de origen es importante para los registros y las auditorías: en el caso de SSH, RDP y otros accesos TCP, el origen no ve la IP original del cliente, sino el contexto del conector. Las listas de permitidos basadas en IP en el sistema de destino no constituyen una asignación fiable de usuarios para este fin. Las aplicaciones HTTP pueden evaluar el encabezado CF-Connecting-IP, siempre que su registro y su cadena de confianza lo tengan en cuenta de forma deliberada.

Elegir la solución de acceso adecuada

Cloudflare Tunnel es adecuado para un único panel de administración web cuando se desea que se pueda acceder al servicio a través de un nombre de host claro, sin necesidad de proporcionar una IP de origen pública ni permitir el tráfico entrante. La configuración más adecuada consiste en un destino específico, precedido de una aplicación de acceso con un grupo de identidades reducido y autenticación multifactorial (MFA). Este procedimiento protege la ruta de red, pero no sustituye ni a la gestión segura de sesiones ni a la verificación de permisos en el panel de administración.

Un pequeño equipo de administración acostumbrado a trabajar con la terminal puede utilizar SSH a través de Cloudflared y Access en el lado del cliente. El SSH renderizado por el navegador resulta especialmente adecuado como acceso preparado para emergencias o asistencia técnica. Ambas opciones tienen diferentes requisitos en cuanto a clientes y manejo; la transferencia de archivos, los flujos de trabajo y los requisitos de auditoría deben ajustarse al método elegido. La elección de modelos más avanzados para los permisos SSH centralizados solo debe realizarse basándose en su documentación específica y actualizada.

Quien necesite muchos servicios internos, segmentos completos o una amplia comunicación este-oeste debería valorar un acceso a la red privada, como una VPN, o un modelo de conectividad diseñado específicamente para ello. Un único túnel publicado no sustituye automáticamente a todas las cargas de trabajo de VPN. El túnel no es adecuado para protocolos iniciados por el servidor, como VoIP o SIP; asimismo, las sesiones TCP de larga duración y sensibles a las interrupciones requieren un análisis del protocolo concreto y de las posibles consecuencias de una reconexión.

La apertura clásica de puertos puede ser aceptable cuando un servicio se ofrece deliberadamente de forma pública y el cortafuegos, la protección del origen y la autenticación de aplicaciones se gestionan adecuadamente. Un servidor bastión agrupa los accesos SSH, pero sigue siendo en sí mismo un punto de entrada que debe protegerse con especial cuidado. Un proxy inverso, por su parte, es una capa para la terminación TLS y la entrega de aplicaciones; no responde por sí solo a la pregunta de cómo se puede acceder al origen privado.

El estándar mínimo de productividad es el siguiente: el menor alcance de objetivos necesario, reglas basadas en la identidad, autenticación multifactorial (MFA) para roles con privilegios, configuración probada de Ingress y «catch-all», proceso de actualización planificado y recuperación documentada. Plan de recuperación Incluye, como mínimo, las responsabilidades, las rutas alternativas y la comprobación de si el servicio de destino y el conector vuelven a estar accesibles tras el mantenimiento. Los túneles reducen la superficie de exposición de la red, pero no sustituyen al refuerzo de la seguridad de las aplicaciones, a los permisos locales ni a la supervisión operativa continua.