Cloudflare · Redes · Seguridad
Publicar un servicio desde casa puede hacerse abriendo puertos en el router o creando un Cloudflare Tunnel. Ambos métodos resuelven el acceso remoto, pero exponen la infraestructura de formas muy diferentes.
- Cómo llega el tráfico hasta tu servidor en cada método.
- Qué puertos, IP públicas y certificados necesitas administrar.
- Ventajas, limitaciones y dependencia de terceros.
- Qué opción encaja mejor según el tipo de servicio.
Idea central
La diferencia en una frase
Con port forwarding, Internet se conecta a un puerto abierto de tu dirección pública y el router reenvía ese tráfico al servidor interno. Con Cloudflare Tunnel, cloudflared inicia conexiones salientes hacia Cloudflare y el tráfico público viaja por esas conexiones existentes hasta el servicio local.
Método tradicional
¿Qué significa abrir un puerto en el router?
La mayoría de redes domésticas usan NAT. Los dispositivos internos tienen direcciones privadas y el router comparte una dirección pública hacia Internet. Una regla de port forwarding indica que las conexiones recibidas en un puerto concreto deben enviarse a una IP y puerto dentro de la LAN.
Por ejemplo, podrías publicar un servidor HTTPS reenviando TCP 443 hacia 192.168.1.50:443.
Ese enfoque es directo y funciona con muchos protocolos, pero también significa que tu IP pública y el puerto quedan accesibles desde Internet. La seguridad depende de la aplicación, firewall, actualizaciones, autenticación y configuración TLS que tú administres.
Cloudflare Tunnel
¿Qué cambia con Cloudflare Tunnel?
Cloudflare Tunnel utiliza cloudflared dentro de tu red. El daemon abre conexiones salientes hacia Cloudflare y las mantiene disponibles. No necesitas exponer una dirección pública del servidor ni abrir un puerto de entrada para el origen.
Después puedes mapear un hostname público, como app.example.com, hacia un servicio local, por ejemplo http://localhost:3000. Cloudflare recibe la petición pública y la envía por el túnel al origen.
Cada hostname puede apuntar a un puerto o servicio local diferente detrás del mismo conector.
Seguridad
La diferencia más importante es la superficie expuesta
Con un puerto abierto existe un endpoint alcanzable directamente en tu IP pública. Los scanners de Internet pueden descubrir puertos abiertos y probar el servicio que escucha detrás de ellos.
Con Cloudflare Tunnel, el origen no necesita escuchar públicamente. Cloudflare indica que las conexiones empiezan dentro de tu red, de modo que los recursos no necesitan IP pública ni puertos inbound abiertos.
Esto reduce la exposición directa del origen, pero no convierte automáticamente una aplicación en privada. Si publicas un hostname sin autenticación, cualquiera que conozca o descubra esa URL puede intentar acceder.
Para paneles internos, administración o servicios privados, añade autenticación propia o una política de Cloudflare Access.
Conectividad
Cloudflare Tunnel puede funcionar aunque no controles la entrada
El port forwarding normalmente requiere que el router reciba conexiones desde Internet y que tú puedas configurarlo. Si el proveedor usa CGNAT, tu conexión puede no tener una dirección IPv4 pública dedicada sobre la que abrir puertos.
Cloudflare Tunnel parte de conexiones salientes. Mientras el servidor pueda conectarse a Internet y alcanzar Cloudflare, no necesita que el ISP enrute directamente conexiones nuevas desde Internet hacia tu router.
Esto hace que Tunnel sea atractivo en redes residenciales, LTE/5G y escenarios donde no tienes control completo sobre el NAT.
HTTPS
¿Quién se encarga de TLS y del dominio?
Con port forwarding, normalmente tú expones el servicio HTTPS o colocas un reverse proxy delante. Debes gestionar DNS, certificados y renovaciones o usar herramientas que automaticen esa parte.
Con una aplicación publicada mediante Cloudflare, el usuario se conecta a la infraestructura de Cloudflare mediante HTTPS y Cloudflare reenvía el tráfico hacia el origen según la Service URL configurada.
El tramo entre cloudflared y tu aplicación puede ser HTTP local o HTTPS. Si usas HTTPS en el origen, debes considerar certificados y validación del servicio local.
Rendimiento
Port forwarding es más directo; Tunnel añade una capa
Una conexión directa por port forwarding puede recorrer menos intermediarios: cliente → Internet → router → servidor. Para protocolos sensibles a latencia o alto volumen, esa simplicidad puede ser una ventaja.
Cloudflare Tunnel introduce la red de Cloudflare y el conector cloudflared. A cambio, puedes obtener integración con funciones de Cloudflare como WAF, protección DDoS y políticas de acceso para aplicaciones publicadas.
No todos los protocolos y escenarios se comportan igual. Un sitio web, panel HTTP o API encajan de forma natural en Tunnel; servicios que dependen de tráfico arbitrario, puertos específicos o descubrimiento de red pueden requerir otro enfoque.
Operación
Cloudflare Tunnel también introduce dependencias
Con port forwarding, tu ruta depende principalmente del ISP, router, DNS y servidor. Con Tunnel añades cloudflared, tu cuenta de Cloudflare y la disponibilidad de la plataforma.
Eso no es necesariamente malo, pero conviene entenderlo. Si quieres una solución completamente independiente de un proveedor intermediario, una exposición directa bien protegida puede tener más sentido.
También debes conservar de forma segura los tokens o credenciales del Tunnel y controlar quién puede modificar las rutas publicadas.
Comparativa
Cloudflare Tunnel vs port forwarding
Elección
¿Cuándo usar cada opción?
- publicas sitios web, paneles o APIs HTTP/HTTPS;
- estás detrás de CGNAT;
- no quieres abrir puertos en el router;
- quieres añadir Cloudflare Access, WAF o políticas delante del origen;
- administras varios hostnames hacia servicios locales.
- necesitas un protocolo que no encaja bien con Tunnel;
- quieres una ruta directa sin un proxy externo;
- controlas tu IP pública, firewall y certificados;
- aceptas administrar la exposición y seguridad del servicio.
Consulta nuestro tutorial Configurar Cloudflare Tunnel en Ubuntu.