Autoalojamiento para la Soberanía de Datos: La Transición Open-Source en Proxy Reverso

El Imperativo Empresarial: Por qué los Túneles Gestionados Ya No Son Suficientes

Exponer servicios locales a internet para pruebas, webhooks o acceso remoto es una necesidad diaria en desarrollo de software y gestión de infraestructura. Durante años, proveedores SaaS gestionados como ngrok y Cloudflare Tunnel han sido la solución predeterminada. Sin embargo, para ingenieros de infraestructura empresarial, oficiales de cumplimiento y equipos de seguridad, enrutando tráfico interno a través de un proveedor SaaS gestionado cada vez resulta más difícil de justificar bajo marcos regulatorios estrictos.

Las empresas que operan bajo GDPR, HIPAA, SOC 2 o FedRAMP enfrentan un requisito de soberanía de datos: los datos deben permanecer sujetos a las leyes y estructuras de gobernanza de la jurisdicción donde fueron recopilados. Cuando usas un proxy inverso SaaS gestionado, tus APIs internas y cargas útiles de webhook se enrutan a través de servidores controlados por terceros, a veces en una jurisdicción legal diferente a la tuya.

Esto ha impulsado un cambio hacia herramientas de túnel autoalojadas y de nivel productivo. Puertas de enlace open-source como frp (Fast Reverse Proxy), Zrok (construido sobre la red de confianza cero OpenZiti), y Inlets para Kubernetes permiten a los equipos de infraestructura mantener la puerta en casa — no solo para evitar tarifas de suscripción SaaS, sino para mantener control sobre dónde termina el tráfico y quién puede inspeccionarlo.

Este artículo analiza el estado actual de estas tres herramientas, cómo se comparan y en qué aspectos la situación de cumplimiento está realmente definida frente a las que aún están en evolución.

---

1. El Panorama de la Soberanía de Datos y Cumplimiento

El Problema con los Proxy Reverso SaaS

Herramientas como ngrok gestionado instalan un cliente ligero en tu red privada que establece un túnel saliente hacia los servidores de borde del proveedor. El proveedor genera una URL pública, y el tráfico enviado a esa URL se enruta a través de su infraestructura de vuelta a tu red. Esto es conveniente, pero conlleva consideraciones de cumplimiento:

• Residencia de datos: Si un desarrollador en Alemania prueba una API local usando un túnel gestionado cuyo servidor de borde está en EE. UU., ese enrutamiento transfronterizo necesita un mecanismo legal de transferencia. Es importante ser preciso: una transferencia transatlántica no es automáticamente ilegal. El Marco de Privacidad de Datos EU–US (DPF), adoptado en julio de 2023 por la Comisión Europea, actualmente proporciona una base de adecuación para transferencias a organizaciones certificadas en EE. UU., y sobrevivió a su primer desafío legal en el Tribunal General de la UE en septiembre de 2025. Pero la historia del DPF ha sido de invalidaciones recurrentes — reemplazó Safe Harbor (derribado en 2015) y Privacy Shield (derribado en la sentencia Schrems II en 2020) — y ahora está en apelación ante el CJEU, con incertidumbre adicional tras una sentencia de la Corte Suprema de EE. UU. en junio de 2026 sobre la independencia de los comisionados de la FTC, que la Junta Europea de Protección de Datos ha señalado como relevante para la supervisión del DPF. Para los equipos de cumplimiento, esta historia es la razón por la que algunas organizaciones optan por eliminar la cuestión transfronteriza en lugar de confiar en un marco que ha sido anulado dos veces.
• Terminación TLS en el borde: Por diseño, los proxies gestionados L7 (HTTP) terminan TLS en el borde del proveedor, descifran el tráfico para enrutarlo al túnel correcto, y luego vuelven a cifrarlo. Incluso con un proveedor confiable, esto significa que un tercero tiene las claves de tu tráfico en tránsito.
• Acoplamiento de disponibilidad: Confiar en un proveedor de túneles SaaS vincula tus flujos de trabajo de acceso remoto y pruebas de webhook a la disponibilidad de ese proveedor.
• Precios medidos a escala: La tarifa SaaS por usuario o por ancho de banda puede volverse costosa a medida que crece el uso.

El Enfoque “Trae Tu Propia Infraestructura” (BYOI)

Para reducir la dependencia en mecanismos de transferencia de terceros, algunas organizaciones alojan su puerta de enlace de túnel en infraestructura que controlan — desplegando el servidor de retransmisión en una región elegida, bajo su propio régimen de auditoría y control de acceso. Las tres herramientas a continuación representan diferentes enfoques a esto.

---

2. frp (Fast Reverse Proxy): El Trabajador de Metal

frp (fatedier/frp en GitHub) es un proxy inverso escrito en Go para exponer un servidor local detrás de un NAT o firewall. Es una de las herramientas de túnel autoalojadas más desplegadas: a mediados de 2026, el repositorio tiene aproximadamente 107,000 estrellas en GitHub, es usado por más de 180 proyectos dependientes públicos, y tiene licencia Apache-2.0. La versión estable actual es v0.69.1.

Arquitectura y Soberanía de Datos

frp tiene dos componentes: frps, el servidor que despliegas en infraestructura que controlas, y frpc, el cliente en la máquina interna. Como eliges dónde corre frps, controlas la jurisdicción por la que pasa el tráfico — desplegar frps en un servidor en eu-central-1 mantiene ese salto dentro de las fronteras alemanas/europeas.

Una nuance importante para lectores con enfoque en cumplimiento: el cifrado a nivel de transporte de frp entre frpc y frps es TLS por defecto desde v0.50.0, pero el cifrado y compresión a nivel de carga útil para proxies individuales (transport.useEncryption, transport.useCompression) están desactivados por defecto y deben habilitarse explícitamente por proxy. Autoalojar frp te da control jurisdiccional automáticamente; no maximiza el cifrado sin configuración.

Funciones Relevantes para Uso Empresarial

• Soporte de protocolos: TCP, UDP, HTTP, HTTPS, y STCP.
• STCP y XTCP para exposición pública cero: STCP (Secret TCP) permite registrar un servicio con frps sin abrir un puerto público — un cliente visitante autorizado debe presentar una clave precompartida para conectar. XTCP va más allá, usando NAT hole-punching basado en STUN para intentar una conexión peer-to-peer directa, retrocediendo a STCP si el tipo de NAT no lo soporta.
• Pooling y multiplexación de conexiones: frps puede mantener un grupo de conexiones preestablecidas para reducir la latencia por solicitud, y la multiplexación de flujos TCP es soportada desde v0.10.0.
• Modos de transporte KCP y QUIC, un gateway de túnel SSH (añadido en v0.53.0) que permite a los clientes conectarse vía ssh -R sin correr frpc, y una función alpha-stage VirtualNet (basada en TUN) para enrutamiento IP entre pares.
• Formato de configuración: Desde v0.52.0, frp usa TOML, YAML o JSON; el formato INI heredado está en desuso y no recibe nuevas funciones.

También vale la pena destacar que los mantenedores de frp tienen en marcha una reescritura v2 — un núcleo de proxy L4/L7 más parecido a Envoy — descrita en el README del proyecto como significativamente más compleja de lo esperado y sin fecha de lanzamiento fija.

Cuándo Elegir frp

frp es adecuado para equipos que buscan un relé flexible, agnóstico en protocolos, y completamente autoalojado, y que están cómodos gestionando su propio servidor y configuración TLS. Es un sustituto razonable de una VPN tradicional cuando necesitas acceso remoto dirigido por servicio, en lugar de conectividad de red completa.

---

3. Zrok: Red de Confianza Cero Construida sobre OpenZiti

Zrok es desarrollado por NetFoundry y construido sobre OpenZiti, la red de confianza cero open-source de NetFoundry. En lugar de reenviar puertos, Zrok establece una superposición cifrada basada en identidad entre endpoints — en el modelo de OpenZiti, no hay puertos en escucha en internet público, y el acceso se concede mediante identidad criptográfica en lugar de IP.

Un Cambio de Versión Importante: v2.0 / zrok2

Zrok lanzó una versión significativa v2.0 en marzo de 2026. Si has visto tutoriales antiguos de Zrok, la sintaxis de comandos ha cambiado:

• El binario ahora es zrok2, no zrok. Se pueden instalar lado a lado — v2 usa su propio directorio de entorno (~/.zrok2), su propio prefijo de variables de entorno (ZROK2_*), y sus propias unidades systemd, por lo que actualizar no altera una instalación v1 existente.
• El compartimiento reservado fue reemplazado por un modelo de espacio de nombres/nombrado. Los comandos antiguos zrok reserve / zrok release / zrok share reserved desaparecieron; zrok2 create share y zrok2 delete share ahora gestionan comparticiones públicas y privadas, con una bandera --share-token en zrok2 share private para un token de vanidad persistente.
• Se añadió un nuevo comando zrok2 access dynamicProxy, que recibe actualizaciones de mapeo de nombres directamente del controlador en lugar de analizar el encabezado Host.

Compartición Pública vs. Privada

Zrok soporta dos modos de compartición:

1. Compartición pública (zrok2 share public <target>) genera una URL HTTPS pública — útil para integraciones de terceros como Stripe o webhooks de GitHub que necesitan un endpoint público convencional.
2. Compartición privada (zrok2 share private <target>) genera un token de compartición en lugar de una URL. Un colaborador o pipeline CI/CD ejecuta zrok2 access private <token> para acceder al servicio. Nunca se crea un registro DNS público ni un puerto abierto, y el tráfico se transporta de extremo a extremo sobre la red OpenZiti entre los endpoints — un router que relaya tráfico para sortear NAT estricto no puede descifrarlo, ya que las claves de cifrado solo están en los endpoints.

Zrok también soporta un modo de permisos “cerrado” (--closed, añadido en v0.4.26 y heredado en v2) que restringe una compartición a entornos propiedad de la cuenta que la creó, además de una opción --access-grant para permitir cuentas adicionales específicas.

Alojado vs. Autoalojado y Precios

Zrok tiene licencia Apache-2.0 y puede autoalojarse en Linux, Docker o Kubernetes, o usarse como servicio gestionado en zrok.io (rebrandeado comercialmente como “zrokNET” en la página de precios de NetFoundry, con una capa gratuita que ofrece 5 GB/día, 25 entornos, 50 backends de compartición y 50 frontends de acceso privado al momento de escribir). El autoalojamiento elimina los límites de uso, pero requiere desplegar tu propio controlador OpenZiti — un esfuerzo operacional mayor que desplegar un servidor frp.

Cuándo Elegir Zrok

Zrok es adecuado para organizaciones que desean control de acceso basado en identidad, sin que las comparticiones privadas toquen el internet público en absoluto. Debido a que es una base de código más nueva y en evolución activa que frp, los equipos deben planear la migración de v1 a v2 si empiezan desde cero o actualizan una implementación existente.

---

4. Inlets: La Línea de Productos de Túneles para Kubernetes

Inlets fue creado por Alex Ellis, también fundador de OpenFaaS. Está dirigido a equipos que necesitan exponer servicios desde clusters sin IP pública — Kubernetes en metal, clusters Raspberry Pi, o sitios en el edge — creando un túnel saliente desde el cluster privado a un “nodo de salida” ligero en una región de nube pública de su elección.

Corrección de Licencia: Inlets No Es un Túnel Open-Source

Es importante distinguir esto claramente: el binario inlets-pro es software comercial de código cerrado. Según las FAQ del proyecto, solo inlets-operator y inletsctl — las herramientas de orquestación que provisionan VMs de nodo de salida y configuran el túnel — tienen licencia MIT. El binario inlets-pro que transporta tráfico requiere una licencia de pago (personal, comercial o empresarial) emitida por OpenFaaS Ltd., bajo un EULA comercial, y no funcionará sin ella. El proyecto original open-source inlets (solo HTTP, sin automatización TLS) aún existe en la historia del proyecto, pero ha sido efectivamente reemplazado por inlets-pro y no es la vía activa.

Esto no descarta a Inlets en una discusión de soberanía de datos — aún eliges dónde vive el nodo de salida, y el tráfico puede cifrarse de extremo a extremo sin que el proveedor tenga las claves — pero sí significa que Inlets se acerca más al modelo comercial de ngrok que al open-source completo de frp o Zrok. Si “sin relación con proveedor y sin costo de licencia” es un requisito estricto, Inlets no lo cumple; si “autoalojar nodo de salida en una jurisdicción controlada” es la prioridad, sí.

Soberanía de Datos y Arquitectura

Como eliges la región en la nube del nodo de salida, controlas dónde termina geográficamente el tráfico. Inlets soporta túneles L4 (TCP) y L7 (HTTP); con inlets-pro en modo L4, la terminación TLS sucede dentro de tu cluster (por ejemplo, en un controlador de ingreso interno), en lugar en el nodo de salida, por lo que el nodo solo retransmite bytes cifrados que no puede inspeccionar.

El Operador Inlets

inlets-operator, el operador Kubernetes con licencia MIT, supervisa objetos Service de tipo LoadBalancer. Cuando aparece uno, en lugar de provisionar un balanceador de carga en la nube costoso, inicia una VM ligera de nodo de salida en un proveedor de tu elección (DigitalOcean, Hetzner, AWS, etc., vía API), configura el túnel y lo conecta al pod interno.

La Línea de Producto Actual (2026)

Inlets ha expandido más allá de la CLI original en una pequeña familia de productos: Inlets Pro (túneles autoalojados, con licencia), Inlets Cloud (servicio gestionado con HTTPS/SSH incluido en una suscripción), y Uplink (capa de control nativa para Kubernetes dirigida a vendedores SaaS que necesitan conectar múltiples entornos de clientes a un plano de control compartido, en lugar del uso autoalojado de un solo inquilino).

Cuándo Elegir Inlets

Inlets es adecuado para equipos con fuerte enfoque en Kubernetes que desean la simplicidad operacional de un flujo automatizado de provisión de nodos de salida y están dispuestos a pagar por una licencia comercial por esa conveniencia y soporte. Los equipos que priorizan evitar costos de licencia de proveedor, probablemente prefieran frp o Zrok.

---

5. La Nueva Frontera: Túneles Zero-Trust para Agentes de IA y Servidores MCP

El túnel de soberanía de datos se está extendiendo cada vez más a un nuevo tipo de tráfico: agentes de IA y servidores MCP (Model Context Protocol) que acceden a herramientas internas. Esto es una innovación real de 2026, no una práctica consolidada, por lo que vale tratarlo como tal.

En marzo de 2026, NetFoundry anunció una expansión de OpenZiti hacia lo que llaman un “enclave de IA” — gateways de confianza cero específicos para tráfico de agentes y LLM:

• openziti/mcp-gateway agrega y expone herramientas MCP sobre la superposición OpenZiti (o sobre Zrok) en lugar de un proceso stdio ligado localmente o un endpoint HTTP en escucha pública. Requiere zrok v2.0.x o superior, reflejando cómo ambos proyectos ahora están estrechamente vinculados.
• Un gateway LLM complementario ofrece un proxy compatible con OpenAI con enrutamiento semántico entre proveedores (OpenAI, Anthropic, Azure OpenAI, Bedrock, Vertex AI, Ollama, y otros endpoints compatibles con OpenAI), autenticado con la misma identidad OpenZiti usada para acceso a herramientas MCP — el objetivo declarado es una identidad, una trazabilidad, en llamadas a modelos y herramientas.
• ziti-mcp-server, lanzado aproximadamente en la misma época, es un servidor MCP — expone aproximadamente 200 herramientas que cubren la API de gestión de OpenZiti a cualquier cliente compatible MCP (Claude Desktop, Cursor, etc.), permitiendo a un agente gestionar identidades, servicios y políticas en una red Ziti mediante solicitudes en lenguaje natural, autenticado de la misma forma que un operador humano.

Para lectores interesados en la infraestructura de IA y túneles: este es el ejemplo más claro hasta ahora de un proveedor de túneles construyendo infraestructura específica para tráfico de agentes en lugar de reutilizar un túnel de propósito general. Es temprano — estos proyectos se lanzaron en el mismo mes que Zrok v2.0 y aún están en evolución — pero es una señal concreta de que los proveedores de túneles de confianza cero ven la conectividad agente-a-herramienta como un problema distinto, que merece herramientas dedicadas, no solo “túneles para webhooks con pasos adicionales”.

---

6. Matriz Comparativa

Característica/Requisito	frp	Zrok (OpenZiti)	Inlets
Caso de uso principal	Túneles TCP/UDP en metal, genéricos	Compartición pública y privada basada en identidad, confianza cero	Túneles Kubernetes, nativos en la nube L4/L7
Licencia	Código abierto completo (Apache-2.0)	Código abierto completo (Apache-2.0)	La orquestación (inlets-operator, inletsctl) es MIT; el binario inlets-pro es cerrado y comercial
Modelo de seguridad	Reenvío de puertos; secretos STCP/XTCP precompartidos	Superposición de confianza cero; cifrado E2EE entre endpoints en comparticiones privadas	Túnel saliente WebSocket; paso L4 con terminación TLS interna
Cifrado por defecto	TLS entre frpc/frps desde v0.50.0; cifrado de carga útil opcional por proxy	End-to-end en comparticiones privadas por diseño	Depende del modo de túnel; modo L4 mantiene TLS interno terminada
Soberanía de datos	Alta — autoalojado, región propia	Alta — autoalojado o gestionado, cifrado E2EE en comparticiones privadas	Moderada a alta — eliges la región del nodo de salida, pero dependes de un proveedor comercial
Nativo en Kubernetes	Configuración manual	Containerizable, requiere configuración	Operador nativo con provisión automática de nodos de salida
Requisito de IP pública	Requerido para frps	No requerido para comparticiones privadas	Requerido para el nodo de salida
Complejidad operacional	Moderada	Mayor — requiere un controlador OpenZiti, o migración v1→v2	Baja a moderada — automatizado vía operador

---

7. Mejores Prácticas para una Estrategia de Túneles Autoalojados

1. No asumas que autoalojar significa cifrado por defecto. Como muestra el ejemplo de frp, TLS a nivel de transporte puede estar activado por defecto, pero el cifrado y la compresión de carga útil en proxies individuales a menudo no lo están. Verifica los defaults de cada herramienta en lugar de asumir que “autoalojado” implica “máximamente cifrado”.
2. Termina TLS internamente donde la herramienta lo soporte. Usar paso TLS en modo L4/TCP (frp, inlets-pro) y terminar TLS en tu ingreso interno significa que tu servidor relé nunca tiene tráfico descifrado, reduciendo lo que un atacante obtiene si lo compromete.
3. Ubica los relés en la región que tu requisito de cumplimiento realmente especifique, y documenta por qué — esta documentación importa si un regulador o auditor pregunta cómo se justifica un flujo de datos, especialmente mientras marcos como el DPF sigan en litigio.
4. Audita el acceso regularmente. Para frp, revisa la restricción allowPorts en la configuración del servidor. Para Zrok, revisa los permisos de comparticiones cerradas y rota tokens periódicamente en lugar de tratarlos como permanentes.
5. Monitorea el tráfico del túnel como cualquier otra vía de ingreso. Alimenta logs en tu SIEM, y rastrea patrones de ancho de banda con Prometheus u OpenTelemetry — el autoalojamiento elimina un borde de proveedor, pero el túnel sigue siendo un puente a tu red privada y debe tratarse como tal.

---

Conclusión

La conveniencia de los proxies SaaS gestionados conlleva verdaderos compromisos de cumplimiento para organizaciones bajo regímenes estrictos de protección de datos — pero la situación es más matizada que “los túneles SaaS son ilegales, los autoalojados son seguros.” Las transferencias transfronterizas pueden ser legales bajo mecanismos como el DPF, y autoalojar una herramienta no implica automáticamente que el tráfico esté más cifrado que de otra forma; ambas afirmaciones requieren verificar cómo está configurada realmente cada herramienta.

Lo que es cierto es que frp, Zrok, e Inlets ofrecen a los equipos de infraestructura una forma de elegir exactamente dónde termina un túnel y, en el caso de Zrok, evitar un endpoint público por completo para comparticiones internas. De los tres, frp y Zrok son genuinamente open-source sin costo de licencia; Inlets intercambia una licencia comercial por un flujo de trabajo más automatizado en Kubernetes con soporte de proveedor. La elección depende si la prioridad es flexibilidad en protocolos (frp), control de acceso basado en identidad y confianza cero (Zrok), o automatización nativa en Kubernetes respaldada por soporte comercial (Inlets).

---

Historial de Cambios

Correcciones: - Eliminada la afirmación de que enrutar datos a través de un túnel SaaS en EE. UU. es automáticamente ilegal bajo GDPR/Schrems II. Se añadió contexto preciso sobre el Marco de Privacidad de Datos EU–US (adoptado en julio 2023, validado en septiembre 2025, apelación en curso en el CJEU, y en revisión por EDPB desde una sentencia de la Corte Suprema en junio 2026). - Corregido el marco de Inlets como “alternativa open-source a ngrok”. Solo inlets-operator y inletsctl tienen licencia MIT; el binario inlets-pro es cerrado y requiere licencia comercial bajo EULA de OpenFaaS Ltd. Esto se indica explícitamente, incluyendo en la matriz comparativa. - Actualizada la sintaxis y conceptos de Zrok: Zrok lanzó v2.0 en marzo 2026, renombrando a zrok2, reemplazando el modelo de compartición reservada por un sistema de espacio de nombres, y eliminando zrok reserve/zrok release/zrok share reserved. El borrador original usaba sintaxis v1 (zrok share private, zrok access private) sin mencionar esta transición. - Aclarado que TLS a nivel de transporte en frp está activado por defecto (desde v0.50.0), pero la encriptación y compresión de carga útil en proxies es opcional — el borrador original implicaba que solo autoalojar maximiza cifrado. - Se suavizó el lenguaje promocional como “grado militar” y similares, reemplazándolos por descripciones neutrales y fácticas.

Añadido: - Datos actuales de frp: ~107k estrellas en GitHub, licencia Apache-2.0, versión estable v0.69.1 (junio 2026), migración de formato de configuración de INI a TOML/YAML/JSON (desde v0.52.0), Gateway SSH (v0.53.0), función alpha VirtualNet (v0.62.0), y la reescritura en marcha, no lanzada, de frp v2. - Nueva sección 5 sobre infraestructura de confianza cero para agentes de IA y servidores MCP en 2026: openziti/mcp-gateway, un gateway LLM compatible con OpenAI, y ziti-mcp-server (que expone la API de gestión de OpenZiti — aproximadamente 200 herramientas — a clientes MCP), todos anunciados por NetFoundry en marzo 2026. - Detalle de línea de productos de Inlets: Inlets Cloud (gestionado) y Uplink (control nativo en Kubernetes para SaaS), además del camino autoalojado en inlets-pro. - Modo de permisos “cerrado” (--closed, --access-grant) en Zrok para restringir acceso a comparticiones privadas a cuentas específicas. - Fila de licencia añadida en la matriz comparativa para hacer visible la diferencia entre open-source y comercial.

Fuentes verificadas: github.com/fatedier/frp (README, lanzamientos), github.com/openziti/zrok (README, CHANGELOG, lanzamientos), blog.openziti.io (“Introducing zrok v2.0”), netfoundry.io/docs (visión general de zrok, comparticiones privadas, guía migración v1→v2), zrok.io/pricing, inlets.dev (páginas de producto, FAQ), github.com/inlets/inlets-pro (EULA.md), github.com/inlets/inlets-operator, prnewswire.com (anuncio de enclave IA de NetFoundry), github.com/openziti/mcp-gateway, blog.openziti.io (publicación sobre ziti-mcp-server), y análisis legal actual sobre el Marco de Privacidad de Datos EU–US (Recording Law, EuropeanMartech, Skadden, IAPP).