Cloudflare Tunnel como única puerta de entrada al VPS

El problema con SSH expuesto a internet

Si tienes un VPS, probablemente tiene el puerto 22 abierto al mundo. Es el default de prácticamente todos los proveedores. Y aunque uses claves SSH en lugar de contraseñas, desactives el login de root y cambies el puerto, la realidad es que ese servicio está ahí, escuchando, recibiendo miles de intentos de conexión al día.

Fail2ban, rate limiting, port knocking — son parches sobre un problema de diseño. El enfoque correcto no es proteger un servicio expuesto, sino no exponerlo. Si estás considerando migrar tu web a un VPS, asegurar el acceso desde el principio es fundamental.

La decisión: acceso solo por Cloudflare Tunnel

Mi VPS no tiene SSH público. El puerto 22 no está abierto en el firewall. La única forma de acceder es a través de Cloudflare Tunnel, un servicio que crea una conexión saliente desde el servidor hacia la red de Cloudflare. No necesita puertos abiertos, no necesita IP pública para el acceso de gestión y funciona desde cualquier red, incluyendo redes restrictivas.

El modelo es simple:

cloudflared corre como servicio en el servidor y mantiene una conexión permanente con Cloudflare
Cuando quiero conectar por SSH, mi cliente usa cloudflared como proxy
Cloudflare autentica mi identidad antes de permitir la conexión
Solo entonces se establece la sesión SSH a través del túnel

Desde mi máquina, la configuración SSH es transparente:

Host mi-servidor
    HostName ssh.midominio.com
    User usuario
    IdentityFile ~/.ssh/mi-clave
    ProxyCommand cloudflared access ssh --hostname ssh.midominio.com

Conecto con ssh mi-servidor y el proceso de autenticación con Cloudflare ocurre automáticamente. La primera vez en cada sesión se abre el navegador para verificar identidad con Google OAuth.

Por qué no WireGuard

Antes usaba WireGuard como VPN para acceder al servidor. Funcionaba bien técnicamente, pero tenía un problema operativo que me molestaba: dependía de tener el cliente WireGuard configurado en cada dispositivo desde el que quisiera conectar.

Si estaba en un ordenador nuevo, en un móvil prestado o en una red que bloqueaba UDP, no podía acceder. WireGuard requiere que el peer esté preconfigurado — no es algo que puedas montar en dos minutos desde una máquina cualquiera.

Cloudflare Tunnel resuelve esto: solo necesitas cloudflared instalado (un binario) y un navegador para autenticarte. Funciona desde cualquier red porque usa HTTPS saliente — no hay protocolo exótico que bloquear.

La pieza clave: Cloudflare Access

El túnel solo es el transporte. La seguridad real viene de Cloudflare Access (Zero Trust), que actúa como capa de autenticación antes de que la conexión llegue al servidor.

Cada servicio protegido tiene una política de acceso definida:

SSH: solo mi cuenta de Google, autenticación obligatoria
Servicios de gestión: misma política, acceso restringido

Si alguien descubre el hostname del túnel, no puede hacer nada. Sin autenticación válida en Cloudflare, la conexión nunca llega al servidor. El VPS no tiene que rechazar nada porque nunca recibe la petición.

cloudflared como servicio del sistema, no como contenedor

Una decisión deliberada: cloudflared corre como servicio systemd directamente en el sistema operativo, no como contenedor Docker. La razón es obvia pero fácil de pasar por alto: si Docker tiene un problema, necesito poder acceder al servidor para arreglarlo. Si el acceso depende de Docker, estoy bloqueado. (Sobre la decisión de qué corre dentro de Docker y qué no, hablo más en detalle en volúmenes Docker vs bind mounts).

# cloudflared corre independiente de Docker
sudo systemctl status cloudflared

Esta separación es no negociable. El acceso al servidor nunca puede depender de los servicios que corre el servidor.

El tradeoff honesto

Nada es gratis. Este modelo tiene implicaciones:

Lo que ganas:

Superficie de ataque reducida a cero puertos abiertos para gestión
Autenticación con identidad real (Google OAuth), no solo con claves SSH
Funciona desde cualquier red sin configuración previa en el cliente
Log centralizado de todos los accesos en el dashboard de Cloudflare

Lo que complicas:

Dependencia de Cloudflare como servicio — si Cloudflare cae, no accedes (mitigado con consola de emergencia del proveedor)
Latencia ligeramente mayor que SSH directo (imperceptible en la práctica)
Necesitas una cuenta de Cloudflare y configurar Zero Trust

Lo que no negocio:

La consola del proveedor de hosting siempre está disponible como último recurso. No la uso nunca, pero sé que está ahí.
cloudflared siempre como servicio del sistema, nunca en Docker
La autenticación con proveedor de identidad es obligatoria, no opcional

Conclusión

Eliminar SSH público y WireGuard de mi servidor fue una de las mejores decisiones operativas que he tomado. No porque las alternativas sean malas — sino porque Cloudflare Tunnel + Zero Trust me da mejor seguridad con menos complejidad operativa.

Si gestionas un VPS y tu modelo de amenaza incluye “no quiero que nadie pueda ni intentar conectarse”, este enfoque funciona. El coste es cero (el plan gratuito de Cloudflare es suficiente) y la mejora en tranquilidad es real.

Una vez asegurado el acceso, el siguiente paso es tener un sistema de backups sólido. Y si todavía no tienes claro si necesitas un VPS, aquí explico la diferencia entre hosting compartido y VPS para negocios. Para una estrategia de seguridad más completa, revisa esta guía para proteger tu web de ataques.

Si quieres que alguien configure accesos seguros a tu VPS sin complicarte, puedo montar todo el stack de seguridad por ti.