Cloudflare Tunnel: cero puertos abiertos a internet, y los deploys siguen funcionando
Mantener un servidor en producción sin exponer ni un solo puerto al internet público suena imposible. No lo es. Aquí está cómo lo hacemos en producción con Cloudflare Tunnel — y por qué es la forma más sensata de exponer servicios web hoy.
La forma tradicional de exponer un servidor web a internet es: abrir el puerto 80 y el 443 en el firewall del servidor, configurar un certificado SSL, y rezar para que tu firewall esté correctamente configurado. Funciona. También deja dos puertas mirando al internet público las 24 horas del día, recibiendo escaneos de bots constantemente.
Hay una forma mejor. Hace tres años no era práctica; hoy lo es. Se llama Cloudflare Tunnel (técnicamente parte de Cloudflare Zero Trust) y la usamos en todos los servidores que administramos.
El cambio mental
La idea suena casi extraña al principio:
En lugar de que el visitante (o el atacante) toque la puerta de tu servidor, tu servidor toca la puerta de Cloudflare. Cloudflare recibe a los visitantes legítimos, los identifica, y luego le pasa la petición a tu servidor por la conexión que el servidor ya inició.
En la práctica eso significa que tu firewall puede bloquear todas las conexiones entrantes desde internet. Cero puertos abiertos. Aún así tu sitio web funciona perfectamente.
Cómo funciona, en simple
- Instalas un pequeño agente (
cloudflared) en tu servidor. - El agente abre una conexión cifrada hacia los servidores de Cloudflare.
- Configuras qué dominios deben llegar a este servidor.
- Los visitantes escriben tu dominio → llegan a Cloudflare → Cloudflare reenvía la petición por el túnel.
El servidor nunca acepta conexiones desde internet. Solo mantiene una conversación con Cloudflare hacia afuera. Es como si tu servidor llamara a Cloudflare por teléfono y dijera "cualquier llamada que reciban para mí, redirigeanla a esta línea".
Qué se gana
Cero puertos web abiertos
Tu firewall puede tener regla "denegar todo entrante" sin excepciones para web. Los bots que escanean internet 24/7 buscando puertos 80 y 443 abiertos no encuentran nada en tu IP. Tu servidor, para los efectos de un escaneo masivo, no existe.
Certificado SSL gestionado por Cloudflare
No tienes que renovar Let's Encrypt cada 90 días, no tienes que preocuparte por la configuración del certificado en tu servidor. Cloudflare maneja eso. El visitante ve siempre el candado verde.
Protección DDoS de fábrica
El tráfico llega primero a Cloudflare, no a ti. Si alguien intenta tirar tu sitio con un ataque masivo, Cloudflare absorbe la avalancha. Tu servidor solo ve el tráfico legítimo que pasó el filtro.
Acceso administrativo opcional sin abrir SSH
El mismo túnel puede transportar SSH (y RDP, VNC, lo que sea). Eso significa que puedes administrar el servidor sin abrir el puerto 22 a internet. Solo personas autenticadas con tu identidad corporativa (Google Workspace, Microsoft 365, GitHub) pueden establecer la conexión.
Es gratis para casos típicos
El plan gratuito de Cloudflare Tunnel cubre tráfico web ilimitado para sitios públicos. Solo pagas si necesitas funciones avanzadas como autenticación granular, análisis profundos o políticas de acceso por equipo.
Lo que NO te ahorra
Para que el panorama sea honesto: Cloudflare Tunnel no reemplaza el resto de capas de seguridad. Sigues necesitando:
- Firewall en el servidor para bloquear lo que se mete por otros caminos (red privada, otros contenedores, etc.).
- Acceso administrativo bien configurado (llaves SSH, no contraseñas).
- Backups y monitoreo del servidor mismo.
- Aplicación segura — Cloudflare no te salva de un bug de inyección SQL en tu propio código.
Lo que sí elimina es la categoría completa de "alguien escanea mi IP y encuentra un puerto vulnerable". Esa categoría representa la mayoría de los ataques automatizados contra servidores en internet.
¿Y los deploys? ¿Cómo subo cambios sin SSH abierto?
Esta es la pregunta que todos hacen. Tres opciones limpias:
Opción 1: pipeline que dispara un comando remoto
Los pipelines (GitHub Actions, Azure Pipelines, GitLab CI) pueden ejecutar comandos en tu servidor a través del propio túnel, autenticándose con un token de Cloudflare. Cero puerto SSH abierto, los pasos quedan auditados.
Opción 2: el servidor escucha eventos (pull-based)
En vez de que el pipeline empuje al servidor, el servidor escucha en una cola (Redis, Kafka) o en un webhook firmado y aplica los cambios él mismo cuando detecta uno nuevo. Útil cuando tienes muchos servidores que actualizar.
Opción 3: runner autohospedado
Un agente del CI corre dentro de tu servidor y recibe las órdenes desde la nube del proveedor. La conexión va de adentro hacia afuera, igual que cloudflared.
Las tres evitan exponer SSH al mundo y las tres son estándar de la industria hoy.
Cuándo conviene Cloudflare Tunnel y cuándo no
Conviene si:
- Tu sitio es público (web, API, blog, e-commerce).
- Quieres cero puertos abiertos al mundo.
- Necesitas protección DDoS sin pagar fortunas.
- Tienes presupuesto cero o limitado para herramientas de seguridad.
- Administras varios servidores y quieres una capa común para acceso administrativo.
Hay que pensarlo dos veces si:
- Necesitas baja latencia extrema (el tráfico va y vuelve por Cloudflare; añade unos milisegundos).
- Tienes regulaciones que exigen que el tráfico no salga de cierto país (Cloudflare opera global).
- Tu aplicación necesita IPs de origen fijas (Cloudflare cambia las suyas).
Para el 95% de los sitios web de PyMEs y startups, los pros superan masivamente los contras.
Cómo lo combinamos en nuestra arquitectura
En los servidores que administramos, el panorama queda así:
Internet
│
▼
[Cloudflare] ── filtra DDoS, bots, y maneja SSL
│
│ (túnel cifrado iniciado desde el servidor)
│
▼
[Servidor] ── firewall: cero puertos web abiertos
│
├── cloudflared (agente del túnel)
├── Nginx Proxy Manager (enruta a contenedores)
└── Servicios en Docker (cada uno solo escucha localmente)
Nadie desde internet puede tocar la IP del servidor directamente. Cualquier intento se topa con un firewall que dice "no" a todo. El tráfico legítimo entra por el túnel, autenticado por Cloudflare, y solo entonces toca tu aplicación.
En ServerStack Solutions
Esta configuración viene de fábrica en todos los planes que incluyen administración de servidor. No tienes que entender los detalles — la arquitectura está, funciona, y si quieres mirar el dashboard de Cloudflare para ver el tráfico que se filtra, te damos acceso.
Solicita una evaluación de tu exposición actual. Te decimos qué puertos tienes abiertos hoy, cuáles deberían cerrarse y qué se gana si lo migramos a este modelo.
Relacionado: Caso real: servidor blindado sin puertos expuestos · SSH cerrado, deploys abiertos · Arquitectura segura completa.
Preguntas frecuentes
¿Cloudflare Tunnel es realmente gratis?
Para tráfico web público y casos típicos, sí. El plan gratuito permite túneles ilimitados, dominios ilimitados y tráfico web sin tope práctico. Empiezas a pagar si necesitas autenticación SSO para acceso administrativo (Cloudflare Access, ~3 USD por usuario al mes), análisis profundos de tráfico, o políticas avanzadas para equipos. Para una PyME que solo quiere proteger su sitio público, no hay costo.
¿Es lo mismo que Tailscale o WireGuard?
Resuelven problemas relacionados pero distintos. Tailscale y WireGuard crean redes privadas entre dispositivos autenticados — útiles para acceso administrativo entre equipo distribuido. Cloudflare Tunnel se especializa en exponer servicios públicos (tu sitio web) a través de un túnel sin abrir puertos. En servidores que administramos a veces usamos los dos: Cloudflare Tunnel para el tráfico público y Tailscale para que el equipo administre el servidor sin SSH abierto.
¿Qué pasa si Cloudflare se cae?
Si Cloudflare tiene una caída global, tu sitio queda inaccesible temporalmente. La probabilidad es baja (Cloudflare tiene una de las redes más estables del mundo) pero no es cero. La defensa es tener un plan de fallback documentado: en caso de caída prolongada, abrir temporalmente el puerto 443 directo y apuntar el DNS al servidor mientras se restablece. Eso es operativo, no continuo.
¿Funciona con cualquier proveedor cloud?
Sí. Cloudflare Tunnel es agnóstico al proveedor. Funciona en AWS, DigitalOcean, Hostinger, Contabo, GCP, Azure, en una Raspberry Pi en tu casa, donde sea que puedas correr el agente. Solo necesita conexión a internet saliente — eso es todo.