Alternativas autoalojadas a ngrok: frp, Zrok y Inlets para la soberanía de datos

Introducción: El dilema del ingreso empresarial

En arquitecturas modernas nativas de la nube, los desarrolladores y equipos de operaciones enfrentan con frecuencia un desafío persistente: ¿cómo exponer de forma segura servicios internos, entornos de staging, dispositivos en el borde o clústeres de Kubernetes locales a redes externas o tráfico de clientes?

Durante años, herramientas gestionadas para desarrolladores como ngrok se convirtieron en el estándar predeterminado. Con una simple invocación en la línea de comandos, los ingenieros podían evitar NAT (Traducción de Direcciones de Red), negociar CGNAT (NAT de grado operador) y establecer una URL HTTPS pública mapeada directamente a un puerto local.

Sin embargo, a medida que las organizaciones escalan y las cargas de trabajo nativas de la nube maduran, la dependencia de túneles de ingreso SaaS de terceros introduce fricciones arquitectónicas y regulatorias. Cuando el tráfico interno se enruta a través de un servidor SaaS gestionado por un tercero, la infraestructura de ese proveedor se sitúa directamente en la ruta de datos — una preocupación real para arquitectos de seguridad empresarial, gestores de cumplimiento y ingenieros de infraestructura.

Los marcos de protección de datos como GDPR, HIPAA, SOC 2 Tipo II, PCI-DSS y la directiva NIS2 de la UE configuran cómo las organizaciones deben manejar los datos de carga útil, la exposición a terceros y la respuesta a incidentes — aunque, como se explica más abajo, no todos regulan lo mismo, y vale la pena ser precisos sobre qué ley hace qué antes de diseñar la arquitectura en torno a ella.

La alternativa es la soberanía de datos autoalojada: tomar control tanto del plano de control como del plano de datos para que una organización pueda eliminar la telemetría de terceros, aplicar control de acceso de confianza cero y cumplir con sus propias obligaciones de cumplimiento directamente. Esta guía describe cuatro opciones de grado de producción que impulsan ese cambio — frp (Fast Reverse Proxy), zrok (construido sobre OpenZiti), Inlets y la más reciente Pangolin — y se verifica contra la documentación y código fuente de cada proyecto a agosto de 2026.

1. La presión de cumplimiento y arquitectura hacia la soberanía de datos

Por qué los túneles SaaS complican el cumplimiento

Las plataformas de túneles gestionados SaaS operan como sistemas de proxy inverso multitenant. Cuando un agente local crea un túnel hacia una plataforma SaaS:

• Intercepción y descifrado del tráfico: TLS generalmente termina en el borde del proveedor SaaS para habilitar integraciones como inspección de solicitudes, registro de webhooks y paneles web, lo que significa que la infraestructura del proveedor mantiene brevemente datos de la aplicación descifrados en memoria.
• Control limitado de telemetría y auditoría: Las organizaciones a menudo no pueden verificar completamente dónde se almacenan los registros de tránsito o cuánto tiempo se retienen los cuerpos de solicitudes/respuestas en infraestructura que no operan.
• Riesgo en la cadena de suministro y punto único de fallo: Fallos o incidentes de seguridad en el proveedor SaaS pueden afectar la disponibilidad y confidencialidad de los puntos finales internos.

Cabe señalar que esto no es estrictamente binario — ngrok, por ejemplo, ofrece opciones de nivel empresarial como un modelo de despliegue “Trae tu propia nube” (BYOC) y ediciones privadas dedicadas que corren dentro del entorno del cliente, dirigidas exactamente a este tipo de preocupación. La autoalojación sigue siendo la respuesta más completa para equipos que quieren que tanto el plano de control como el de datos estén completamente bajo su propiedad operativa sin pagar por un nivel empresarial para llegar allí, pero no es el único camino para reducir la exposición de terceros.

[ Flujo tradicional de túnel SaaS - Riesgo de soberanía ]
Servicio local  ---  Agente de túnel local  ---  [ Nube SaaS gestionada ]  ---  Usuario/Cliente público
                                                (Terminación TLS 
                                                Exposición de la ruta de datos)

[ Flujo de túnel autoalojado - Soberanía total de datos ]
Servicio local  ---  Agente de túnel local  ---  [ Gateway empresarial autoalojado ]  ---  Usuario/Cliente público
                                                (Bajo control total de SecOps
                                                y política de cumplimiento)

Entendiendo el panorama regulatorio

Es tentador agrupar GDPR, HIPAA, PCI-DSS, SOC 2 y NIS2 como “las razones para necesitar soberanía de datos,” pero no todos hacen el mismo trabajo, y confundirlos dificulta construir el control correcto para el requerimiento adecuado:

• GDPR es el que más directamente se preocupa por dónde fluyen y se almacenan los datos personales — las restricciones de transferencias transfronterizas y las expectativas de residencia de datos son clave.
• HIPAA regula la información de salud protegida (PHI) en contextos de salud en EE. UU. — controles de acceso, auditorías y salvaguardas para PHI en tránsito y en reposo.
• PCI-DSS regula específicamente los datos de los titulares de tarjetas — segmentación de red, cifrado en tránsito y restricción de quién (incluidos terceros) puede ver los datos.
• SOC 2 Tipo II es un marco de atestación basado en criterios de confianza en servicios (seguridad, disponibilidad, confidencialidad, etc.) en lugar de una ley; se trata de demostrar que los controles funcionan efectivamente en el tiempo, incluyendo los controles sobre proveedores.
• NIS2 (Directiva (UE) ²⁰²²⁄₂₅₅₅) es principalmente una directiva de gestión de riesgos de ciberseguridad y reporte de incidentes para entidades esenciales e importantes en la UE — exige medidas de gestión de riesgos, reporte de incidentes en 24 horas, requisitos de seguridad en la cadena de suministro y responsabilidad a nivel gerencial. No funciona como una ley de residencia de datos como GDPR, aunque sus disposiciones sobre la cadena de suministro son relevantes para riesgo de exposición a terceros, que es donde se conecta con la discusión de túneles.

La conclusión práctica es la misma en ambos casos — minimizar el número de terceros en la ruta de datos reduce la exposición en todos estos marcos simultáneamente — pero si citas una regulación específica a un equipo de cumplimiento, cita la que realmente dice lo que estás afirmando.

Definiendo la soberanía de datos en arquitecturas de borde y túneles

Para lograr una verdadera soberanía de datos en arquitecturas de acceso remoto y exposición de servicios, generalmente necesitas tres cosas:

1. Aislamiento del plano de control — políticas de autenticación, integración con proveedores de identidad y configuración de enrutamiento que funcionen completamente en tu infraestructura.
2. Aislamiento del plano de datos — el tráfico de carga útil nunca atraviesa un tercero no contratado, con cifrado de extremo a extremo desde el cliente o proxy de ingreso directamente al backend.
3. Auditabilidad y gobernanza de confianza cero — eventos de conexión, transferencias de bytes y decisiones de autorización alimentan directamente tu propio SIEM y pila de identidad.

2. Criterios de evaluación técnica para una alternativa autoalojada a ngrok

Al seleccionar una alternativa autoalojada a ngrok, considera:

• Flexibilidad de protocolo y capa — ¿Capa 7 (HTTP/1.1, HTTP/2, gRPC, WebSockets) así como capa 4 (TCP, UDP, protocolos de base de datos)?
• Integración con Zero Trust Network Access (ZTNA) — ¿depende de puertos públicos expuestos, o puede funcionar solo en salida con acceso basado en identidad?
• Capacidades nativas para Kubernetes — ¿integración con controladores de ingreso, CRDs, aprovisionamiento automatizado?
• Rendimiento y sobrecarga de multiplexación — agrupamiento de conexiones, keep-alives y latencia bajo concurrencia?
• Modelo de licencia y soporte — código abierto genuino, disponible, o comercial, y ¿existe un SLA de soporte?

3. Análisis profundo de soluciones autoalojadas

3.1 frp (Fast Reverse Proxy)

frp es un proxy inverso maduro, de alto rendimiento, escrito en Go, mantenido por fatedier y colaboradores, diseñado para exponer servidores locales detrás de NATs y firewalls. Es una de las herramientas de túneles autoalojados más desplegadas en computación en el borde, gestión de flotas IoT y entornos empresariales híbridos, y es realmente código abierto bajo la Licencia Apache 2.0 — esa parte de la afirmación original es correcta.

                   +----------------------------------+
                   |       Nube/ VPS autoalojada     |
                   |                                  |
   Cliente  =======|   frps (Servidor FRP)            |
 (Internet)        |   - Escucha en puertos públicos   |
                   |   - Maneja TLS / multiplexación  |
                   +----------------------------------+
                                    ^
                                    | Control encriptado 
                                    | Túnel de datos (multiplexado)
                                    v
                   +----------------------------------+
                   |       Red empresarial privada   |
                   |                                  |
                   |   frpc (Cliente FRP)             |
                   |        |                         |
                   |        v                         |
                   |   App / API / DB interna         |
                   +----------------------------------+

Arquitectura. frp usa un modelo de doble binario: frps corre en un servidor público y gestiona mapeo de puertos y enrutamiento; frpc corre dentro de la red privada e inicia una conexión saliente a frps, manteniendo una conexión persistente y multiplexada.

Opciones de transporte. frp soporta más transportes que un simple relé TCP — en la configuración actual de frpc/frps, el campo transport.protocol acepta tcp, kcp (un protocolo UDP de baja latencia), quic, websocket y wss. El soporte para QUIC en particular es una adición significativa para enlaces de alta latencia o con pérdida, ya que multiplexa flujos sobre UDP sin bloqueo de línea de cabeza.

Tipos de proxy. frp aún soporta los modos importantes:

• TCP / UDP — exposición directa de capa 4 para bases de datos, SSH y sockets personalizados.
• HTTP / HTTPS — exposición de capa 7 con hosting virtual basado en dominio y reescritura de encabezados/URL.
• STCP (TCP Secreto) — requiere que el cliente que conecta pruebe una clave compartida antes de exponer tráfico, ocultando el servicio de escáneres de puertos.
• XTCP (TCP P2P) — usa negociación estilo STUN para intentar una conexión directa entre pares, evitando el servidor relé para cargas de trabajo intensivas en ancho de banda.

Novedades. frp tiene una función alpha VirtualNet, controlada por la bandera featureGates = { VirtualNet = true }, que crea una interfaz TUN y realiza enrutamiento IP entre máquinas en lugar de simple reenvío de puertos — más cercano a una red mesh ligera que a un proxy inverso clásico. Actualmente requiere permisos elevados (root/admin) y es compatible con Linux y macOS. Por separado, el mantenedor ha mencionado públicamente que frp trabaja en una v2 basada en un núcleo proxy L4/L7 más parecido a Envoy, altamente extensible, aunque explícitamente no compatible en línea con v1 y aún en desarrollo temprano — no planifiques arquitectura de producción en torno a ella todavía.

Ejemplo de configuración (formato TOML actual):

# frps.toml (servidor)
bindPort = 7000
vhostHttpsPort = 443

auth.method = "token"
auth.token = "SUPER_SECRET_ENTERPRISE_TOKEN_CHANGE_ME"

webServer.addr = "127.0.0.1"
webServer.port = 7500
webServer.user = "admin"
webServer.password = "STRONG_DASHBOARD_PASSWORD"

transport.tls.force = true

# frpc.toml (cliente)
serverAddr = "tunnel-gateway.tuempresa.com"
serverPort = 7000

auth.method = "token"
auth.token = "SUPER_SECRET_ENTERPRISE_TOKEN_CHANGE_ME"

transport.protocol = "quic"   # o "tcp", "kcp", "websocket", "wss"
transport.tls.enable = true

[[proxies]]
name = "servicio-api-interno"
type = "https"
customDomains = ["api-staging.tuempresa.com"]

Fortalezas. Ligero, binario único; sin dependencias externas; bajo consumo de recursos; enrutamiento versátil L4/L7 más P2P vía XTCP; código abierto Apache-2.0 genuino con mantenedor activo y ciclo de lanzamientos real (aunque aún en pre-v1).

Desventajas. Sin gestión de identidad/acceso integrada — asegurar rutas L7 para OIDC/OAuth2 aún requiere combinar frp con Nginx, Traefik, Caddy o un proxy OAuth2 delante. La función VirtualNet está en fase alpha y no debe usarse en producción todavía.

3.2 zrok (Zero Trust, construido sobre OpenZiti)

zrok es un proyecto de código abierto mantenido por NetFoundry, construido sobre OpenZiti, el proyecto de red de superposición de confianza cero de NetFoundry. Tanto zrok como la infraestructura base de OpenZiti son realmente de código abierto bajo la Licencia Apache 2.0 — confirmado directamente en la documentación de NetFoundry, no solo en marketing. NetFoundry vende un conjunto de gestión licenciado y soporte empresarial para equipos que quieren operar OpenZiti a escala, pero la infraestructura en sí no tiene costo de licencia para autoalojamiento.

                                +---------------------------+
                                |      Infraestructura OpenZiti |
                                |   (Controlador autoalojado |
                                |      y enrutadores Ziti)     |
                                +---------------------------+
                                        /           \
                 Control saliente y   /             \ Control saliente y
                 canal de datos       /               \ canal de datos
                                     v                 v
+-------------------------------+   +----------------------------------+
|   Dispositivo cliente / usuario |   | Entorno de servicio privado     |
|                                |   |                                  |
| acceso zrok (mTLS efímero)     |===| compartición zrok (Punto oscuro) |
| Sin ataque de red entrante    |   | Sin puertos abiertos en firewall |
| Superficie                     |   | Microsegmentación nativa       |
+-------------------------------+   +----------------------------------+

El modelo. zrok elimina puertos abiertos en firewall entrantes. Tanto el lado de compartición (tu API o app privada) como el cliente consumidor establecen conexiones salientes, seguras con mTLS, hacia la infraestructura OpenZiti — el acceso se mediatiza por identidad, no por IP ni por puerto abierto.

Modos de compartición. zrok soporta varios modos de backend, no solo proxy HTTP simple: el modo proxy reenvía a una dirección objetivo, el modo web sirve un directorio como sitio estático, y el modo drive expone un directorio como unidad de red virtual vía WebDAV, con un comando zrok copy para sincronización unidireccional.

Autoalojamiento, descrito con precisión. Una implementación autoalojada en producción no es solo “ejecutar un par de contenedores Docker” — las guías actuales describen cómo montar un controlador y enrutador OpenZiti, luego el controlador zrok, uno o más frontends zrok y un puente de métricas, respaldados por PostgreSQL, RabbitMQ e InfluxDB. Es un sistema real de múltiples componentes, que es exactamente la compensación operativa que la tabla de licencias del borrador original ya (correctamente) señalaba.

Una nuance de seguridad importante. Por defecto, los compartidos de zrok — públicos y privados — usan el modo de permiso llamado “abierto”: cualquier usuario de tu instancia zrok que conozca el token de compartición puede acceder a él. La bandera --closed en zrok share (acompañada de --access-grant <email>) restringe un compartido privado a identidades explícitamente autorizadas. Si despliegas zrok específicamente por su historia de confianza cero, los compartidos --closed con permisos explícitos son la configuración que realmente cumple esa promesa — el modo predeterminado es más permisivo de lo que “confianza cero” implica a primera vista.

Ejemplo corregido de CLI. Los comandos del borrador original estaban cerca, pero usaban un formato de token no representativo y una bandera --bind innecesaria en el cliente. Una versión más precisa:

# 1. Apunta la CLI a tu instancia autoalojada y autentícate
zrok login --api-endpoint https://zrok.tuempresa-interna.net <api-token>

# 2. Comparte un servicio local en privado, restringido a cuentas nombradas
zrok share private --headless --closed --access-grant teammate@tuempresa.com 127.0.0.1:9090

# La salida incluye un token de compartición, por ejemplo: wr3hpf2z5fiy

# 3. En una máquina autorizada, accede al compartido privado
zrok access private wr3hpf2z5fiy

Fortalezas. Modelo verdaderamente de confianza cero con mTLS nativo y microsegmentación; licencia Apache-2.0 en todos los niveles; modos de backend más allá de HTTP (archivos, WebDAV); permisos por compartido para control de acceso más granular que un secreto compartido simple.

Desventajas. Mayor complejidad operativa que un proxy inverso de binario único — implica montar y operar un sistema distribuido (controlador, enrutador(es), frontend(s), broker de mensajes, almacenamiento de métricas), no solo un relé. El modo de permisos predeterminado es más abierto que el marco de confianza cero a menos que se configure explícitamente para restringir.

3.3 Inlets

Aquí fue donde la corrección más grande era necesaria. Inlets Pro no es código abierto. El proyecto original, “inlets OSS” (v1/v2), sí era gratuito y de código abierto, pero su propio repositorio de GitHub ahora lo describe como reemplazado y que ya no recibe actualizaciones. El producto activamente mantenido — inlets Pro, desarrollado por Alex Ellis (fundador de OpenFaaS) — es un binario cerrado bajo un Acuerdo de Licencia de Usuario Final comercial: necesitas una clave de licencia pagada o una suscripción en Gumroad para ejecutarlo, y el código fuente no se publica. Las herramientas circundantes, inlets-operator (que aprovisiona automáticamente VMs de salida para servicios LoadBalancer en Kubernetes) y inletsctl (una CLI para crear servidores de salida), son utilidades separadas de código abierto, pero el motor del túnel que orquestan es software comercial, no “doble licencia de código abierto.”

+-------------------------------------------------------------------------+
|                  VPS en nube pública / Gateway en borde                   |
|                                                                         |
|   +-----------------------------------------------------------------+   |
|   | nodo de salida inlets-pro (recibe tráfico público)             |   |
|   | Escucha en puertos 80 / 443                                      |   |
|   +-----------------------------------------------------------------+   |
+-------------------------------------------------------------------------+
                                    ^
                                    | Control seguro y túnel de datos
                                    | WebSockets cifrados / TLS
                                    v
+-------------------------------------------------------------------------+
|                 Clúster Kubernetes empresarial privado                  |
|                                                                         |
|   +-----------------------------------------------------------------+   |
|   | inlets-operator (autoaprovisiona nodos de salida)                |   |
|   +-----------------------------------------------------------------+   |
|                                   |                                     |
|   +-------------------------------+---------------------------------+   |
|   | cliente inlets-pro (multiplexa tráfico de túnel)               |   |
|   +-----------------------------------------------------------------+   |
|                                   |                                     |
|                                   v                                     |
|   +-----------------------------------------------------------------+   |
|   | Ingress-Nginx / Traefik / Envoy (Servicio ClusterIP)             |   |
|   +-----------------------------------------------------------------+   |
+-------------------------------------------------------------------------+

Qué hace bien. inlets Pro transmite TCP de capa 4 en WebSockets cifrados, importante para controladores de ingreso en Kubernetes que necesitan ver TCP en crudo para inspeccionar TLS SNI, manejar mTLS o automatizar cert-manager. inlets-operator observa objetos Service de tipo LoadBalancer en un clúster sin balanceador de carga en la nube, aprovisiona una VM pequeña en un proveedor compatible y configura automáticamente el túnel — realmente útil para Kubernetes en bare-metal, en-prem o en borde.

apiVersion: v1
kind: Service
metadata:
  name: ingress-nginx-controller
  namespace: ingress-nginx
  annotations:
    dev.inlets.operator/provider: "digitalocean"
    dev.inlets.operator/region: "ams3"
    dev.inlets.operator/plan: "s-1vcpu-1gb"
spec:
  type: LoadBalancer
  ports:
    - name: http
      port: 80
      targetPort: http
    - name: https
      port: 443
      targetPort: https
  selector:
    app.kubernetes.io/name: ingress-nginx

Novedades desde el borrador original. El equipo de Alex Ellis ahora también ofrece Inlets Uplink, dirigido específicamente a equipos SaaS y plataformas que necesitan ejecutar múltiples túneles orientados a clientes desde un plano de control de Kubernetes — con un precio fijo mensual por plano de control más un cargo por túnel, nuevamente como licencia comercial en lugar de código abierto.

Fortalezas. Diseñado para Kubernetes, con verdadera transparencia TCP de capa 4 e integración con cert-manager; aprovisionamiento automatizado de nodos de salida en las principales nubes; una empresa detrás que ofrece soporte comercial real.

Desventajas. Es software comercial con licencia, no algo que puedas auditar, bifurcar o ejecutar sin pagar — un modelo de confianza y costo materialmente diferente a frp o zrok. Si el objetivo es “sin dependencia de terceros en absoluto,” la relación de Inlets con OpenFaaS Ltd como proveedor de software de nodos de salida vale la pena considerarla, aunque el tráfico en sí nunca abandona tu infraestructura.

3.4 Pangolin — Un nuevo participante que vale la pena conocer

Desde que el panorama de túneles ha evolucionado desde que se escribió el borrador original, vale la pena agregar una cuarta opción que no existía en su forma actual cuando se hicieron comparaciones como esta: Pangolin, una plataforma de proxy inverso con túneles autoalojada construida sobre WireGuard (a través de un cliente de espacio de usuario llamado Newt) y Traefik, con gestión de identidad y acceso integrada desde el inicio en lugar de añadida posteriormente. Se promociona directamente como una alternativa autoalojable a Cloudflare Tunnel, y ganó tracción rápidamente — sus creadores reportaron más de 12,600 estrellas en GitHub y más de 140,000 instalaciones en cinco meses desde su lanzamiento. Es de código abierto, y la empresa detrás también ofrece una capa de coordinación en la nube gestionada opcional para equipos que quieren conmutación automática sin renunciar a flujo de datos autoalojado.

Dónde encaja respecto a frp, zrok y Inlets. La propuesta de Pangolin apunta directamente a la brecha que la sección de frp señala — un túnel autoalojado con autenticación centralizada SSO, control de acceso basado en roles, TOTP y reglas de acceso por recurso listas para usar, sin necesidad de desplegar un proxy OAuth2 o una infraestructura OpenZiti adicional. Cambia parte de la pureza de zrok en confianza cero (el servidor central de Pangolin aún termina conexiones y debe ser alcanzable) por un modelo operativo mucho más simple que montar OpenZiti, y sacrifica algo del minimalismo de frp por funciones de identidad integradas que frp no tiene de forma nativa.

4. Matriz comparativa de arquitectura

Capacidad	ngrok (SaaS)	frp	zrok (OpenZiti)	Inlets Pro	Pangolin
Soberanía de datos	Limitado por defecto; edición BYOC/privada disponible en planes empresariales	Control total	Control total	Control total (el motor es software comercial)	Control total
Licencia	Propietario SaaS	Código abierto (Apache 2.0)	Código abierto (Apache 2.0)	Comercial (código cerrado, clave de licencia)	Código abierto
Soporte de capa de red	L4 y L7	L4 (TCP/UDP), L7 (HTTP/S), P2P, VirtualNet experimental a nivel IP	L4 y L7 sobre infraestructura de confianza cero; también archivos/WebDAV	TCP L4 y HTTP/WebSockets L7	WireGuard L4 y Traefik L7
Puertos de firewall entrantes	Ninguno requerido (SaaS)	Requiere puerto abierto en frps	Ninguno requerido (por defecto en modo oscuro)	Requiere puerto abierto en nodo de salida	Ninguno requerido en recursos protegidos
Integración con Kubernetes	Controlador de ingreso personalizado	Manual / Helm	Operador / SDK	inlets-operator nativo	No nativo en Kubernetes
Control de identidad/acceso	OAuth SaaS / listas blancas IP	Autenticación por token; necesita un proxy IdP externo para SSO/OIDC	Identidades mTLS nativas; modos de permisos por compartido	Autenticación por clave de licencia; TLS	SSO integrado, RBAC, TOTP
Huella de despliegue	SaaS en la nube + agente local	Binario doble (frps/frpc)	Controlador + enrutador(s) + frontend(s) + pila de métricas	VM de nodo de salida + cliente	Servidor central + Traefik + clientes Newt

5. Plan de fortalecimiento de seguridad para túneles de ingreso autoalojados

Desplegar una puerta de enlace autoalojada traslada toda la gobernanza de seguridad a tu equipo interno de SecOps. Lista de verificación para producción:

+---------------------------------------------------------------------------------------------------+
|                                LISTA DE VERIFICACIÓN DE SEGURIDAD EN PRODUCCIÓN                     |
+---------------------------------------------------------------------------------------------------+
|  [1] Aplicación estricta de TLS 1.3   -- Terminar o pasar TLS 1.3; desactivar cifrados antiguos. |
|  [2] Proxy de identidad y OIDC        -- Proteger endpoints L7 públicos con OAuth2-Proxy / Keycloak. |
|  [3] Limitación de tasa y DDoS       -- Aplicar límites de conexión y control de ráfagas con eBPF/Nginx. |
|  [4] Integración de telemetría de auditoría -- Enviar registros JSON de conexiones directamente a SIEM (Splunk/Datadog). |
|  [5] Segmentación de privilegios mínimos -- Aislar procesos del agente de túnel usando Docker/AppArmor/SELinux. |
+---------------------------------------------------------------------------------------------------+

1. Aplicar OAuth2/OIDC en el nivel de puerta de enlace. Nunca exponer paneles administrativos o APIs de staging sin autenticar directamente. Combina frps o un nodo de salida inlets con OAuth2-Proxy, Authelia o Authentik respaldados por tu IdP empresarial. (zrok y Pangolin implementan la enforzamiento de identidad de forma más nativa — ver arriba.)
2. Segmentar el radio de impacto. Ejecuta los clientes de túnel en redes de contenedores aisladas o usuarios Linux no privilegiados; usa objetos NetworkPolicy en Kubernetes para evitar que un pod comprometido escanee servicios adyacentes.
3. Centralizar los registros de auditoría. Transmite los registros del ciclo de vida de conexiones — IPs origen, parámetros del handshake TLS, conteo de bytes, identificadores de tokens — a un almacén de registros inmutable o SIEM. [ Puerta de túnel ] --- [ Agente Syslog / Vector ] --- [ SIEM: Splunk / Elastic / Datadog ]

6. Recomendaciones estratégicas

• Desarrollo local, staging, flotas IoT: frp sigue siendo la vía más rápida para un túnel ligero, de costo cero, y verdaderamente de código abierto para APIs internas, sockets SSH o hardware en el borde.
• Entornos estrictamente de confianza cero / regulados donde ningún puerto entrante es aceptable: zrok, siempre que configures comparticiones --closed deliberadamente en lugar de confiar en el modo de permiso abierto por defecto, y estés dispuesto a operar la infraestructura OpenZiti en la que se basa.
• Ingreso en la nube, en-prem o híbrido con Kubernetes: Inlets Pro, con la advertencia de que estás licenciando software comercial, no adoptando una dependencia de código abierto.
• Equipos pequeños o autoalojadores que quieren acceso con SSO sin montar OpenZiti o Kubernetes: Pangolin es el más reciente y, para ese caso de uso específico, probablemente la opción de menor fricción de las cuatro.

Conclusión

La tendencia de alejarse de túneles SaaS gestionados es real, pero el razonamiento detrás de ello merece el mismo rigor que la arquitectura misma. No todos los marcos de cumplimiento dicen lo que a menudo se asume, y no toda “alternativa de código abierto” es completamente abierta — Inlets Pro siendo el ejemplo más claro aquí. frp, zrok y Pangolin son realmente de código abierto y realmente colocan toda la ruta de datos bajo tu control; Inlets Pro pone la ruta de datos bajo tu control mientras el motor en sí sigue siendo un producto de pago y cerrado. Saber cuál es cuál marca la diferencia entre un argumento de cumplimiento preciso y uno que se desmorona ante una revisión de seguridad de proveedor.

---

Fuentes

• fatedier/frp — Repositorio GitHub, README y versiones
• Documentación oficial de frp (gofrp.org)
• Resumen de zrok — Documentación de NetFoundry
• zrok — Página de licencias de código abierto, Documentación de NetFoundry
• Guía de despliegue autoalojado de zrok (Linux) — Documentación de NetFoundry
• Modos de permiso de zrok — openziti/zrok GitHub
• OpenZiti — Red de Confianza Cero, Segura por Identidad
• inlets PRO — Repositorio GitHub y términos de licencia
• sitio de producto inlets.dev
• Precios de Inlets Uplink — Listado en Gumroad de OpenFaaS
• Pangolin — Repositorio GitHub
• Pangolin — Página de lanzamiento en Y Combinator
• Directiva NIS2 — Comisión Europea, Construyendo el futuro digital de Europa
• ngrok BYOC / edición privada — Listado en AWS Marketplace

---

Registro de cambios

Revisión editorial — 28 de agosto de 2026

1. Eliminado la línea de meta descripción del inicio del borrador (no forma parte del cuerpo del artículo).
2. frp: Confirmada la licencia Apache 2.0 directamente contra el repositorio fatedier/frp (el upstream correcto — no confundirse con forks no relacionados). Añadidos los protocolos de transporte soportados actualmente (quic, kcp, websocket, wss además de tcp simple), que el borrador original no mencionaba. Añadida la función alpha VirtualNet basada en TUN y una nota sobre el esfuerzo en curso de frp v2, ambos extraídos de la propia README y notas de lanzamiento del proyecto.
3. zrok: Confirmada la licencia Apache 2.0 para zrok y la infraestructura base de OpenZiti, directamente contra la documentación de NetFoundry. Reemplazada la descripción vaga de “Docker Compose o charts de Kubernetes” por la lista actual de componentes (controlador, frontend, puente de métricas, PostgreSQL, RabbitMQ, InfluxDB). Corregido el ejemplo de CLI (formato de token, bandera --closed/--access-grant) y añadido un dato relevante de seguridad que el borrador original omitió: los compartidos de zrok por defecto usan modo de permiso “abierto” accesible por cualquier usuario en la instancia, no en modo cerrado por defecto como la narrativa de confianza cero sugiere.
4. Inlets: La corrección más grande. El borrador original describía Inlets Pro como parte de una familia de código abierto con un “modelo de doble licencia.” En realidad, Inlets Pro es software comercial cerrado que requiere una clave de licencia pagada; solo el proyecto legado HTTP “inlets OSS” y las herramientas de orquestación (inlets-operator, inletsctl) son de código abierto. Actualizado la matriz comparativa y la narrativa en consecuencia, y añadido el producto más reciente Inlets Uplink con su precio actual.
5. Marco regulatorio: El borrador original implicaba que GDPR, HIPAA, SOC 2, PCI-DSS y NIS2 regulan de forma similar la residencia de datos. Añadido un apartado aclarando qué regula cada uno, en particular corrigiendo la afirmación de que NIS2 “regula estrictamente la residencia de datos” — en realidad, es principalmente una directiva de gestión de riesgos de ciberseguridad y reporte de incidentes; GDPR es la que realmente impone obligaciones de residencia.
6. Balance de ngrok: Añadida nota factual de que ngrok ofrece opciones de despliegue BYOC y edición privada en nivel empresarial, lo que modera la narrativa implícita de “SaaS significa control cero” para ese segmento.
7. Sección 3.4 (Pangolin): Un participante más reciente, de rápido crecimiento, de código abierto y con funciones de túnel/reverse proxy autoalojado (WireGuard + Traefik, SSO/RBAC integrados) que no aparecía en el borrador original, añadido para mantener la comparación actualizada y cubrir la brecha de “identidad integrada” que el propio borrador señalaba en frp.
8. Actualizada la matriz comparativa (Sección 4) y las recomendaciones estratégicas (Sección 6) para reflejar todo lo anterior, y convertida la tabla ASCII a una tabla Markdown.
9. Añadido apartado de Fuentes enlazando la documentación principal de cada afirmación corregida o añadida.