Alternativa P2P a Cloudflare Tunnels con TLS en el edge

La arquitectura de proxy inverso tradicional tiene un problema estructural: si usás Cloudflare Tunnels o ngrok, tus datos pasan por servidores de terceros antes de llegar a destino. La alternativa peer-to-peer con terminación TLS en el edge resuelve esto conectando cliente y servidor directamente a través de una VPN privada, donde los certificados se generan y terminan localmente sin que ningún intermediario pueda leer el tráfico.

Cloudflare es un servicio de infraestructura web que proporciona CDN, seguridad web y optimización de rendimiento para sitios. Fue fundado en 2009 por Matthew Prince, Lee Holloway y Michelle Zatlyn.

Los dos tradeoffs principales de los reverse proxies

Un proxy inverso estándar te pide que aceptes dos cosas al mismo tiempo: que el SSL se termine en algún servidor antes de llegar a tu red, y que tu servicio quede expuesto a internet. En la mayoría de los casos esto está bien y es lo correcto.

El problema surge cuando usás servicios cloud-brokered como Cloudflare Tunnels o ngrok. Acá viene lo bueno (o lo malo, según cómo lo mirés): estos servicios interceptan tu tráfico en la nube, descifran el SSL, y después lo reenvían por un túnel hacia tu red. Son, por definición, un man-in-the-middle. Pueden inspeccionar lo que pasa, bloquear tráfico malicioso, cachear contenido. Todo muy útil, excepto cuando tus datos no pueden ser leídos por nadie entre el cliente y el destino.

El segundo problema es la exposición. Si corrés un panel interno de un controlador de hardware legacy, un password manager self-hosted, o una base de datos médica, un proxy inverso estándar deja ese servicio visible en DNS público. Podés ponerle una página de login delante, pero el recurso sigue siendo descubrible por cualquiera con un navegador. Una vulnerabilidad no detectada queda expuesta.

Ponele que tenés un panel de administración de un switch de red legacy que solo debería ser accesible para tres personas. Con Cloudflare Tunnels, ese panel tiene una URL pública. Alguien con las herramientas correctas puede encontrarla y probar exploits. Con P2P, el panel literalmente no existe en internet.

Limitaciones de Cloudflare Tunnels y servicios cloud-brokered

Según la documentación técnica de Pangolin publicada el 28 de mayo de 2026, el modelo cloud-brokered tiene dos limitaciones estructurales que no se pueden parchar con configuración.

La primera es el acceso a los datos en tránsito. Cuando Cloudflare termina tu SSL en sus servidores, técnicamente tiene acceso a tu tráfico sin cifrar en ese punto. Para uso general esto es irrelevante. Para sectores con regulación HIPAA, datos financieros o información de salud, es un bloqueo legal. HIPAA requiere que los datos protegidos de salud (PHI) no puedan ser leídos por terceros entre cliente y destino. Un servicio que descifra tu SSL en sus propios servidores, por definición, no cumple eso.

¿Y qué dice Cloudflare al respecto? El análisis de AccountableHQ sobre compliance HIPAA de Cloudflare es claro: Cloudflare puede firmar un Business Associate Agreement (BAA), pero eso no resuelve el problema de fondo. Que exista un acuerdo legal no cambia que el tráfico pasa por sus servidores descifrado.

La segunda limitación es la visibilidad. Cualquier servicio expuesto por Cloudflare Tunnels tiene una URL pública, y esa URL puede ser indexada, escaneada o encontrada. No es un defecto de Cloudflare, es lo que hace un proxy inverso: conecta internet con tu red. Lo explicamos a fondo en gestión de secretos en edge.

Arquitectura P2P + reverse proxy en el edge: la solución

El flip arquitectónico que describe Pangolin es conceptualmente simple: en lugar de depender de DNS público y un servidor cloud que termine las conexiones, el cliente se conecta a una red privada virtual peer-to-peer que lleva el tráfico directamente al edge de tu red, donde un proxy inverso local termina el TLS.

Los certificados TLS se generan y se terminan localmente. Nunca salen de tu infraestructura. El cliente hace una petición HTTPS, el VPN P2P enruta esa petición directamente a tu servidor, y el proxy en el edge descifra, procesa, y responde. Todo esto ocurre sin que ningún servidor de terceros vea el contenido sin cifrar.

El servicio interno tampoco aparece en DNS público. No hay URL discoverable. No hay nada que escanear desde internet porque el punto de entrada es la VPN privada, no una dirección IP o dominio público.

Terminación TLS en el edge vs. en la nube

La diferencia técnica importa más de lo que parece a primera vista.

Con TLS termination en la nube (modelo Cloudflare): la conexión cifrada va del cliente al servidor cloud, se descifra ahí, y el contenido viaja por un túnel interno hasta tu red. El servidor cloud puede ver el tráfico en texto plano durante ese proceso.

Con TLS termination en el edge (modelo P2P): la conexión cifrada va del cliente directamente al proxy en tu red local. El contenido nunca se descifra fuera de tu infraestructura. Nadie en el camino puede leerlo porque el camino es privado.

En términos de latencia, el edge TLS tiene ventaja en redes bien configuradas porque elimina el salto extra al servidor cloud intermediario. No siempre es dramático, pero en servicios con muchas peticiones pequeñas la diferencia se acumula.

Alternativas peer-to-peer reales: Tailscale, NetBird, Nebula, Pangolin

No todas las soluciones P2P son iguales. Hay diferencias importantes en modelo de código, rendimiento y casos de uso. En pipelines de despliegue automatizados profundizamos sobre esto.

Solución	Código	Modelo	Destacado	Limitación
Tailscale	Closed-source (cliente open)	SaaS + self-host parcial	Setup en minutos, muy confiable	Coordinador en nube de Tailscale por defecto
NetBird	Open-source	SaaS + self-host completo	2-5x más rápido que Cloudflare Mesh en misma región	Documentación más técnica
Nebula	Open-source (Slack)	Self-host completo	Usado internamente por Slack, muy maduro	Setup más manual
Pangolin	Open-source	Self-host completo	P2P + reverse proxy + TLS edge integrado	Proyecto más nuevo
Zrok	Open-source	SaaS + self-host	Zero-trust, alternativa moderna a ngrok	Menos adopción que Tailscale

Según el análisis comparativo de NetBird sobre rendimiento vs. Cloudflare Mesh, NetBird logra entre 2 y 5 veces más throughput que Cloudflare Mesh cuando los nodos están en la misma región. La diferencia se reduce cuando los nodos están en regiones distintas.

Tailscale es la opción más accesible si el equipo no tiene experiencia con networking. Setup de 15 minutos, funciona en la mayoría de redes con NAT. El trade-off es que el servidor de coordinación es de Tailscale por defecto (podés autoalojar con Headscale, que es open-source).

Nebula es código abierto, lo usa Slack internamente desde hace años, y es la opción más madura para equipos que quieren control total. Requiere más configuración manual, pero es sólido.

¿Cuándo elegir cada una?

Si el equipo es pequeño y la prioridad es velocidad de setup: Tailscale. Si necesitás compliance estricto y control total sobre toda la infraestructura: NetBird o Nebula self-hosted. Si ya tenés experiencia con proxies y querés todo integrado (VPN + reverse proxy + TLS): Pangolin.

Casos de uso prácticos

HIPAA y datos médicos

Una base de datos de historiales clínicos no puede pasar por servidores de terceros sin cifrar. Con P2P + edge TLS, el médico o la aplicación se conecta a la VPN privada, hace su petición, y los datos viajan y se descifran únicamente dentro de la infraestructura del centro médico. Cumplís HIPAA sin necesitar un BAA con un proveedor cloud que de todas formas ve tu tráfico.

Paneles de hardware legacy

Muchos controladores industriales o de red tienen paneles web que fueron diseñados para funcionar en intranets, no en internet. Exponerlos con un proxy inverso clásico es un riesgo real. Con VPN P2P, el panel no existe en internet. Solo accede quien está en la red privada.

Password managers y herramientas internas

Vaultwarden (el self-hosted de Bitwarden) y herramientas similares son candidatos perfectos para esta arquitectura. Tenés acceso remoto seguro sin que la URL de tu gestor de contraseñas sea descubrible públicamente. (Que una URL exista no significa que sea insegura, pero limitar la superficie de exposición siempre suma.)

Implementación: el flujo básico

El proceso general tiene cuatro etapas. Los detalles varían según la herramienta que elijas. Tema relacionado: GitHub Actions frente a Jenkins.

Primero configurás la VPN peer-to-peer entre los nodos que necesitan comunicarse. Herramientas como NetBird o Tailscale manejan el NAT traversal automáticamente, lo que significa que funciona aunque ambos lados estén detrás de routers sin IP fija. Nebula requiere que configures el NAT traversal manualmente, pero te da más control.

Segundo, instalás el proxy inverso en el nodo edge (el servidor dentro de tu red que recibirá las conexiones). Nginx, Caddy o Traefik son las opciones más usadas. Caddy tiene la ventaja de generar certificados TLS automáticamente con Let’s Encrypt sin configuración extra.

Tercero, generás o configurás los certificados TLS para que terminen localmente. Con Caddy esto es casi automático. Con Nginx necesitás configurar certbot o usar certificados propios.

Cuarto, configurás el proxy para que enrute el tráfico que llega por la VPN al servicio interno correspondiente. El cliente externo ve una conexión HTTPS normal; por dentro, el tráfico viaja por la VPN privada hasta el edge, se descifra ahí, y llega al servicio.

Un punto que muchos saltan: la revocación de certificados. Si un nodo se compromete, necesitás poder revocar su certificado y su acceso a la VPN de forma independiente. Las herramientas maduras como NetBird y Nebula tienen esto integrado; con configuraciones más artesanales lo tenés que resolver vos.

Para quienes estén evaluando infraestructura de servidores para alojar el nodo coordinador o el edge proxy, donweb.com ofrece VPS en Argentina que son una opción para mantener la latencia baja si tu base de usuarios está en Latinoamérica.

Errores comunes

Creer que Cloudflare Tunnels viola HIPAA por sí solo. No es automático. Cloudflare puede firmar un BAA y tiene configuraciones de seguridad robustas. El problema específico es la terminación SSL en sus servidores para servicios donde los datos no pueden ser leídos por terceros bajo ninguna circunstancia. Para muchos casos de salud, un BAA con Cloudflare puede ser suficiente. Para otros (datos de salud mental, ciertos servicios de diagnóstico), no lo es. Hay que analizar el caso puntual, no generalizar.

Configurar la VPN P2P sin pensar en el NAT traversal. Si ambos nodos están detrás de NAT (lo más común en redes corporativas y domésticas), necesitás un servidor STUN/TURN o un servidor de coordinación que facilite el handshake inicial. Herramientas como Tailscale y NetBird lo manejan solas; si armás algo desde cero con WireGuard puro, este es el punto donde la mayoría se tranca. Para más detalles técnicos, mirá distribución global en edge.

Tratar los certificados edge como si fueran permanentes. Los certificados TLS tienen fecha de vencimiento. En un setup cloud-brokered, el proveedor los renueva por vos. En un setup edge propio, necesitás automatizar la renovación. Caddy lo hace automáticamente; con Nginx y certbot tenés que configurar el cron job de renovación y monitorearlo.

Preguntas Frecuentes

¿Qué alternativa a Cloudflare Tunnels es más segura para datos sensibles?

Para datos que no pueden ser leídos por terceros (HIPAA, datos financieros regulados), las opciones P2P self-hosted son la única solución técnicamente correcta. NetBird y Nebula con configuración completamente autoalojada son las más usadas en entornos regulados. Tailscale con servidor de coordinación Headscale propio también califica. La clave es que ningún servidor fuera de tu infraestructura tenga acceso al tráfico sin cifrar.

¿Cómo funciona un reverse proxy peer-to-peer con certificados TLS en el edge?

El cliente externo se conecta a la VPN privada, que enruta el tráfico cifrado directamente al servidor edge en tu red. Ese servidor edge tiene el proxy inverso (Nginx, Caddy, Traefik) que termina el TLS localmente, descifra la petición, y la reenvía al servicio interno. El certificado TLS se genera y reside en tu servidor. Ningún servidor intermediario externo ve el contenido en texto plano.

¿Cuáles son las diferencias clave entre Cloudflare Tunnels, ngrok y arquitectura P2P?

Cloudflare Tunnels y ngrok son servicios cloud-brokered: el tráfico pasa por sus servidores, donde se descifra el SSL. Son fáciles de configurar y tienen protecciones integradas (WAF, DDoS). La arquitectura P2P elimina el intermediario: tráfico y descifrado ocurren en tu infraestructura, el servicio no es descubrible desde internet, y no dependés de la disponibilidad del proveedor. El trade-off es mayor complejidad de configuración.

¿Es posible tener un túnel sin exponer datos a un tercero intermediario?

Sí, y es exactamente lo que hace la arquitectura P2P con edge TLS. Con herramientas como NetBird, Nebula o Tailscale (con coordinador propio vía Headscale), el canal de comunicación entre cliente y servidor es privado. Los certificados TLS se terminan en tu infraestructura. Ningún tercero tiene acceso técnico al tráfico en tránsito.

¿Cómo implementar un proxy inverso descentralizado para cumplir HIPAA?

El requisito técnico de HIPAA relevante es que los PHI (Protected Health Information) no sean accesibles a terceros no autorizados. Con P2P + edge TLS: configurás una VPN P2P entre los clientes autorizados y el servidor, el proxy en el edge termina TLS localmente, y el tráfico nunca se descifra fuera de tu infraestructura. NetBird o Nebula self-hosted son las opciones más usadas para este caso. También necesitás logging de accesos, autenticación fuerte, y una política de revocación de certificados documentada.

Conclusión

Cloudflare Tunnels es una herramienta muy buena para la mayoría de los casos. El problema no es Cloudflare, es asumir que sirve para todos los escenarios sin revisar las implicaciones técnicas.

Si manejás datos que no pueden pasar por terceros, o si exponés servicios internos que no deberían ser visibles desde internet, la arquitectura P2P con terminación TLS en el edge es la respuesta correcta. No es más compleja por capricho: es más compleja porque hace algo que los servicios cloud-brokered no pueden hacer por diseño.

Pangolin, publicado en mayo de 2026, es una propuesta interesante porque integra la VPN P2P y el proxy inverso con edge TLS en una sola herramienta. NetBird sigue siendo la opción más madura para entornos que necesitan rendimiento y control total. Tailscale es la puerta de entrada si el equipo no tiene experiencia en networking.

¿Alguien verificó de forma independiente los benchmarks de 2-5x de NetBird vs. Cloudflare Mesh? Los datos son del propio NetBird, así que tomalos con pinzas. Pero la dirección del argumento técnico es sólida independientemente de los números exactos.

Fuentes

• Pangolin — Building a Peer-to-Peer Alternative to Cloudflare Tunnels with TLS Termination at the Edge (mayo 2026)
• NetBird — Cloudflare Mesh vs NetBird vs Tailscale: comparativa de rendimiento
• AccountableHQ — Is Cloudflare HIPAA Compliant? BAA, PHI and Security Explained
• José Manuel Ortega — SSH vs Cloudflare Tunnel vs Pangolin vs Tailscale vs Headscale vs WireGuard