Control Total de Datos: Túneles de Autoalojamiento con frp, Zrok y Inlets

La conformidad de seguridad empresarial a menudo prohíbe estrictamente enrutar tráfico interno a través de servidores comerciales de terceros. Para ingenieros de infraestructura y equipos DevOps, exponer servicios locales, depurar webhooks o acceder a clústeres privados de Kubernetes son necesidades diarias. Sin embargo, confiar en túneles SaaS comerciales puede generar problemas reales de soberanía de datos y cumplimiento.

Cuando la política de seguridad de tu organización dicta que ningún byte interno puede atravesar un servidor de terceros, necesitas una alternativa a ngrok autoalojada. Aprovechando herramientas de código abierto de alto rendimiento, los equipos pueden construir túneles seguros y privados sin comprometer la velocidad ni violar marcos de cumplimiento como SOC 2, HIPAA o FedRAMP.

Este artículo cubre el caso de soberanía de datos para el tunelamiento autoalojado, y profundiza en tres soluciones: el proxy inverso de código abierto frp, la red de Zrok de confianza cero, y la familia de productos comerciales Inlets — incluyendo donde la idea de “Inlets open source gratis” en línea ya no coincide con la realidad.

1. La Necesidad de Soberanía de Datos en DevOps Moderno

La soberanía de datos se refiere a que los datos digitales están sujetos a las leyes y estructuras de gobernanza de la jurisdicción donde se recopilan y procesan. Para proxies inversos y túneles de red, eso significa mantener control sobre las rutas físicas y virtuales por donde viajan tus datos.

El problema con los túneles SaaS. Los servicios de túneles comerciales instalan un cliente ligero en tu máquina, que abre una conexión saliente a un relé centralizado, de propiedad del proveedor. Luego, el proveedor te entrega una URL pública que enruta el tráfico a través de su infraestructura y de regreso a tu servicio local. Es conveniente, pero introduce riesgos reales para equipos regulados:

• Exposición de metadatos: incluso con cifrado de extremo a extremo, los metadatos de la conexión (IPs, tiempos, tamaños de carga útil) son visibles para el proveedor.
• Riesgo de cumplimiento: sectores de salud, finanzas y gobierno a menudo no pueden legalmente enrutar datos internos a través de infraestructura multiinquilino de terceros.
• Dependencia del proveedor: tus pipelines heredan la disponibilidad y límites de tasa de un tercero.

Las alternativas autoalojadas invierten esto: tú posees el cliente, el relé y las claves de cifrado.

2. frp: El Proxy Inverso de Código Abierto de Alto Rendimiento

frp (Fast Reverse Proxy) suele ser la primera herramienta que los equipos de infraestructura usan cuando necesitan un reemplazo altamente configurable y autoalojado de ngrok. Está escrito en Go, es multiplataforma, y se divide en dos componentes: frps (el servidor, desplegado en un host público que controlas) y frpc (el cliente, ejecutándose dentro de tu red privada). El proyecto tiene alrededor de 108,000 estrellas en GitHub y sigue en desarrollo activo, con la última versión estable (v0.70.0) lanzada en julio de 2026.

Soporte de protocolos y transporte. frp maneja TCP, UDP, HTTP y HTTPS de forma nativa, por lo que puedes tunelizar SSH, RDP, MySQL o flujos TCP sin cifrado junto con tráfico web. Entre frpc y frps, también puedes elegir el protocolo de transporte — TCP estándar, KCP (un protocolo UDP que intercambia algo de overhead por resiliencia en conexiones con pérdida de paquetes), o QUIC (un transporte multiplexado UDP moderno) — importante para equipos distribuidos globalmente en redes poco confiables.

Una corrección de configuración importante: frp ha dejado atrás el antiguo formato frps.ini / frpc.ini. Desde v0.52.0, TOML (junto con YAML y JSON) es el formato de configuración soportado, INI está en desuso, y las nuevas funciones solo están disponibles en los formatos más recientes. Las configuraciones actuales lucen así:

# frpc.toml
serverAddr = "x.x.x.x"
serverPort = 7000

TLS activado por defecto. Los escritos antiguos (y el borrador del artículo) suelen mencionar configurar manualmente tls_enable = true. Desde v0.50.0, transport.tls.enable por defecto es true, por lo que el tráfico frpc-frps está cifrado desde el inicio; el campo solo importa si quieres desactivarlo explícitamente o establecer transport.tls.force = true en el servidor para rechazar clientes sin cifrado.

Modo P2P (XTCP), más precisamente. La capacidad P2P de frp es del tipo proxy xtcp, no un “modo” separado. Usa NAT hole punching basado en STUN para que, una vez establecido un camino directo entre dos clientes, el flujo de datos real pase por alto frps y solo la negociación inicial pase por el servidor. No funciona con todos los tipos de NAT, así que frp permite configurar un visitante fallbackTo STCP que entra si el hole punching no completa en un tiempo — una visión más honesta que “el servidor nunca ve los datos,” ya que frps aún participa en la negociación.

Dashboard y API. El dashboard de frps ha recibido inversión constante: la versión de julio de 2026 amplió la API v2 del dashboard a clientes, proxies, vista general del servidor y vistas detalladas, añadiendo listados paginados, historial de tráfico de proxy, info del sistema del servidor y filtrado por tipo de proxy — útil para auditorías en entornos regulados.

Una reescritura de v2 en progreso, lentamente. El mantenedor ha estado trabajando en frp v2 desde hace tiempo, describiéndolo como un núcleo de proxy L4/L7 modernizado, similar a Envoy, que no será compatible con v1. A mediados de 2026, aún en desarrollo activo pero lento — el mantenedor ha sido sincero en el repositorio sobre que el alcance es mayor de lo esperado y que el desarrollo ocurre en tiempos fragmentados. No hay fecha de lanzamiento anunciada, así que no planifiques migraciones en producción todavía.

3. Zrok: La Red Zero-Trust

Mientras frp es un proxy punto a punto, muchas arquitecturas empresariales se están moviendo hacia Zero Trust Network Access (ZTNA). Aquí entra Zrok.

Construido sobre OpenZiti. Zrok es una plataforma de compartición y tunelización de código abierto de NetFoundry, basada en OpenZiti, una red overlay de confianza cero de código abierto. En lugar de simplemente reenviar puertos, Zrok asume que no hay confianza implícita: el acceso se basa en identidad, no en IP, y ni siquiera los servidores relé pueden descifrar el tráfico, ya que la cifran de extremo a extremo en toda la red OpenZiti.

Modos de compartición. Zrok soporta dos modos principales:

• Compartición pública genera una URL HTTPS accesible para cualquiera — comparable a ngrok.
• Compartición privada crea una conexión basada en tokens entre dos clientes Zrok autenticados que nunca generan un punto final público. Dependiendo del modo backend, las comparticiones privadas pueden proxy HTTP, reenviar cargas TCP/UDP (tcpTunnel/udpTunnel), exponer un proxy SOCKS5 dinámico, o incluso establecer un túnel estilo VPN host a host sobre la overlay OpenZiti.

Nunca puertos entrantes. Todas las conexiones Zrok se establecen saliendo hacia la overlay, sin cambios en firewall, reenvío de puertos o IP pública.

Hito de endurecimiento en 2026. Desde OpenZiti 1.8, las APIs del controlador pueden vincularse como servicios OpenZiti — lo que significa que la capa de gestión que gobierna toda la red ahora está sujeta a la misma verificación criptográfica de identidad, cerrando una clase de ataques que antes requerían endurecer el canal de control por separado.

Nota de versión: la versión estable actual es zrok v1.x (v1.1.11 a principios de 2026). Una “zrok2” de próxima generación está en desarrollo inicial y no se recomienda para producción aún — es importante saberlo si encuentras referencias a ella en tu investigación.

Caso de uso emergente: túneles zero-trust para agentes AI. Uno de los desarrollos más interesantes en 2026 en el ecosistema OpenZiti son proyectos comunitarios que construyen gateways de confianza cero para cargas de trabajo AI — incluyendo gateways MCP (Model Context Protocol) que agregan y exponen herramientas MCP con aislamiento por cliente y mTLS, y gateways LLM que enrutan entre proveedores con control de acceso basado en identidad. Si tu infraestructura trabaja con agentes de codificación AI o servidores MCP, este espacio merece atención junto con los casos de webhooks y túneles de desarrollo.

Autoalojable. Tanto Zrok como OpenZiti tienen licencia Apache 2.0, por lo que la opción completamente autoalojada — ejecutando tu propio controlador OpenZiti y instancia Zrok — está disponible para equipos con restricciones de cumplimiento sin tarifas recurrentes, diferente del servicio gestionado zrok.io de NetFoundry.

4. Túneles Localhost en Kubernetes: La Aproximación Nativa en la Nube

A medida que las organizaciones containerizan, surge una pregunta común: ¿cómo exponer un servicio local a un clúster Kubernetes remoto, o exponer de forma segura un servicio interno del clúster a una máquina de desarrollo local?

Exponer recursos internos del clúster (una API de staging, un panel privado) generalmente requiere configuración de Ingress, servicios LoadBalancer y registros DNS públicos. Para depuración rápida, los equipos suelen usar kubectl port-forward, que es frágil para conexiones prolongadas o compartición externa. Esa es la brecha que tanto frp (con manifiestos Kubernetes manuales) como herramientas específicas como Inlets intentan llenar.

5. Inlets vs. frp: Elegir el Túnel Adecuado — y una Corrección

Al comparar opciones de túneles Kubernetes autoalojados, “inlets vs frp” aparece con frecuencia. Ambas herramientas evitan NAT y dependencia SaaS, pero sus modelos de negocio se han separado más de lo que muchas comparaciones antiguas reconocen.

La corrección: el proyecto open source original “inlets” (la versión OSS gratuita) ha sido discontinuado y no recibe actualizaciones — el código sigue disponible en GitHub en estado sin mantenimiento. Fue reemplazado por inlets Pro, que es solo comercial. Ya no existe una opción gratuita de código abierto para Inlets como la hay para frp o Zrok. Si evalúas “gratuito vs. pagado” en túneles autoalojados, Inlets debe considerarse “pagado” sin más.

La familia actual de productos Inlets, desarrollada por OpenFaaS Ltd:

• inlets Pro — el cliente y servidor de túnel HTTP/TCP principal, para individuos y pequeños equipos.
• Inlets Uplink — una capa de control nativa de Kubernetes, autoalojada, dirigida a SaaS y proveedores de servicios que necesitan acceder a entornos de clientes (bases de datos privadas, APIs internas) sin montar una VPN completa por cliente. Es un patrón de conectividad B2B más que una forma específica de exponer un servidor API de Kubernetes — el cliente Uplink establece una conexión saliente TLS-sobre-websocket desde la red privada del cliente a un endpoint que controlas, y por defecto mantiene la capa de datos privada al clúster a menos que explícitamente la expongas.
• Inlets Cloud — una opción completamente gestionada.

Precios verificados actuales (de inlets.dev/pricing): Personal $25/mes (5 túneles), Comercial $50/mes (2 túneles + $25/mes cada adicional), Uplink $250/mes por clúster Kubernetes (10 túneles + $25/mes cada adicional). Facturación anual con descuento. Es una cifra más ajustada y actual que el rango vago “$25-$50/mes” que se repetía en publicaciones antiguas.

Integración con Kubernetes. El inlets-operator usa un recurso personalizado Tunnel y observa Servicios de tipo LoadBalancer, provisionando automáticamente una VM en la nube para correr un servidor inlets Pro y asignarle su IP pública — un patrón útil para clusters caseros o bare-metal sin LoadBalancer nativo.

Dónde frp aún gana en flexibilidad y costo. frp no tiene un operador Kubernetes nativo, por lo que ejecutar frpc en-cluster requiere crear tus propios manifiestos Deployment, ConfigMap y Service. Lo que obtienes a cambio es un proxy inverso completamente gratuito, flexible en protocolos — incluyendo KCP y QUIC para redes con alta pérdida de paquetes — sin costo de licencia a cualquier escala.

El veredicto, actualizado: si buscas un producto comercial soportado, nativo en Kubernetes, con aprovisionamiento automático, Inlets (ahora Inlets Pro/Uplink) es la opción más lista para usar, a los precios arriba. Si necesitas un proxy inverso gratuito, flexible en protocolos y totalmente autogestionado, frp sigue siendo insuperable en precio. Lo que ha cambiado es que esto ya no es una decisión “gratuito vs. pagado” del mismo producto — es DIY y gratuito versus comercial y gestionado.

6. Implementación en el Mundo Real: Garantizando la Soberanía

Paso 1: Asegura la jurisdicción del nodo relé. Ya sea que ejecutes frps o un controlador OpenZiti para Zrok, el relé debe estar en infraestructura bajo la jurisdicción legal de tu organización — por ejemplo, una empresa de tecnología sanitaria europea alojando su relé en una región de la UE para evitar cruzar fronteras.

Paso 2: Implementa cifrado de extremo a extremo. Con frp, TLS entre frpc y frps está habilitado por defecto desde v0.50.0 (transport.tls.enable), y en versiones recientes ya no necesitas cifrado por proxy adicional. Con Zrok, el cifrado de extremo a extremo está integrado en la red OpenZiti, por lo que los datos están protegidos criptográficamente desde que salen del cliente fuente hasta que llegan al destino — y, según el cambio de OpenZiti 1.8, la capa de control que gestiona esa red también cumple con el mismo estándar.

Paso 3: Acceso granular basado en identidad. Usando el modo de compartición privada de Zrok, los equipos pueden conceder acceso a una identidad Zrok autenticada específica en lugar de un enlace público compartible. Si alguien deja la empresa, revocar su identidad en el controlador OpenZiti corta inmediatamente todos los túneles internos a los que tenía acceso — control de acceso basado en identidad, no en enlace filtrable.

7. Conclusión: Recupera el Control de Tu Red

La conveniencia de los túneles comerciales es innegable, pero para equipos con restricciones regulatorias reales, la conveniencia no supera la soberanía de datos. Enrutar código propietario, bases de datos internas o avances de productos no lanzados a través de infraestructura compartida de un proveedor es un riesgo evitable.

frp sigue siendo la navaja suiza gratuita y flexible en protocolos para la traversa de redes, ahora con configuración basada en TOML más moderna, TLS activado por defecto y inversión continua en el dashboard. Zrok, basado en OpenZiti, es la opción más fuerte para compartición zero-trust basada en identidad — pública o privada — sin abrir puertos entrantes, y cada vez más presente en túneles zero-trust para cargas de trabajo AI y MCP. Inlets vale la pena si buscas un túnel nativo en Kubernetes, soportado comercialmente, y estás dispuesto a pagar — pero debes saber que la era del “Inlets open source gratis” terminó; lo que hay hoy es la línea de productos Pro/Uplink/Cloud en los precios indicados.

Recuperar el control de tu red significa poseer todo el ciclo de vida de tu tráfico — y entender con precisión qué cuesta cada herramienta en dinero o en esfuerzo operativo para lograrlo.

---

Registro de Cambios

Correcciones y adiciones basadas en las fuentes principales actuales (gofrp.org, github.com/fatedier/frp, github.com/openziti/zrok, inlets.dev, docs.inlets.dev), julio de 2026:

• Eliminado todo el contenido de SEO/metadata y el formato de título largo del borrador original; reestructurado en Markdown limpio con encabezados adecuados.
• Corregido formato de configuración de frp: reemplazadas las configuraciones INI (frps.ini/frpc.ini) por el formato TOML actual; notado que INI está en desuso desde frp v0.52.0.
• Corregido el tema de TLS: transport.tls.enable ahora por defecto es true desde frp v0.50.0, en lugar de requerir tls_enable = true manual.
• Aclaración sobre P2P/XTCP: se especifica que frps aún participa en la negociación STUN para NAT hole punching, aunque los datos se transfieran directamente una vez establecido el camino, y que existe fallback STCP para NATs donde falla el hole punching.
• Actualizado detalles de versión/lanzamiento de frp: confirmada la versión estable v0.70.0 (julio 2026) y el proceso en curso de reescritura v2.
• Corregido la descripción de compartición privada en Zrok: especifica que es basada en tokens entre clientes autenticados, y listados los modos backend reales (proxy, tcpTunnel/udpTunnel, socks, vpn) en lugar de una descripción genérica.
• Añadido el detalle de endurecimiento en OpenZiti 1.8 (2026), que no estaba en el borrador original.
• Añadido nota de versión sobre zrok v1.1.11 vs. “zrok2” en desarrollo.
• Incluido un nuevo apartado sobre gateways MCP/LLM zero-trust en OpenZiti/Zrok — un desarrollo nuevo y relevante en 2026 no cubierto en el borrador original.
• Corrección mayor en la sección de Inlets: el borrador original sugería que Inlets tiene un núcleo open source gratuito con un complemento de pago “Inlets Pro”. En realidad, el proyecto OSS gratuito de Inlets fue discontinuado y no recibe mantenimiento, y actualmente Inlets es solo comercial (Inlets Pro / Uplink / Cloud).
• Reemplazado el rango vago “$25–$50/mes” por cifras verificadas actuales: Personal $25/mes (5 túneles), Comercial $50/mes (2 túneles + $25/mes cada adicional), Uplink $250/mes por clúster (10 túneles + $25/mes cada adicional).
• Refinado la descripción de Inlets Uplink: es un patrón B2B/SaaS para conectar clientes a sus entornos privados, no específicamente para exponer un control de Kubernetes.
• Actualizado el apartado de conclusión para reflejar el marco corregido de gratuito vs. comercial en los tres casos.