Más allá de la CLI: Integrando Zero Trust directamente en el código de tu app

Durante años, la respuesta predeterminada a “¿cómo expongo un servicio local a internet?” ha sido un solo comando en la terminal: apuntar una herramienta de túnel a un puerto y obtener una URL pública. Ese flujo de trabajo es rápido, pero se basa en un compromiso arquitectónico que es fácil pasar por alto — un túnel estándar de reverse-proxy aún significa un punto de escucha accesible desde internet, detectable por escáneres en el momento en que se activa.

Para un receptor de webhook o una demo, ese riesgo es aceptable. Para un servicio que interactúa con una base de datos de producción, un panel de administración interno o un endpoint de modelo propietario, representa una superficie de ataque mayor que la que la mayoría de los equipos elegiría si tuviesen una alternativa más sencilla.

Esa es la brecha que el ecosistema OpenZiti — y la herramienta de compartición construida sobre él, zrok — busca cerrar. En lugar de tratar “URL pública” como la única forma que puede tomar un túnel, OpenZiti permite empujar la identidad y encriptación de Zero Trust en tres capas diferentes: la red, el host o la propia aplicación. Este artículo explica cómo funciona ese modelo, cómo los modos de compartición pública y privada de zrok se ajustan a él, qué cambió en la versión v2.0 de zrok, y hacia dónde apunta este ecosistema con infraestructura AI-agent y MCP en 2026.

El cambio arquitectónico: moviendo el límite de confianza

OpenZiti es una plataforma de redes Zero Trust de código abierto, licenciada bajo Apache 2.0, creada y patrocinada por NetFoundry. Su premisa es sencilla: un servicio de red no debería ser accesible solo porque un dispositivo esté en la LAN correcta o tenga una VPN activa. En una red OpenZiti, cada conexión — humana, microservicio o carga de trabajo automatizada — necesita una identidad criptográfica única (respaldada por certificados x509), y esa identidad se verifica contra una política explícita antes de establecer la conexión.

El mecanismo funciona a través de una red overlay privada — una malla de routers de borde:

• Routers de borde conforman los puntos de entrada y la capa de datos encriptados de la overlay. Los routers públicos aceptan conexiones entrantes desde internet; los routers privados pueden estar completamente dentro de una zona de confianza.
• Encriptación de extremo a extremo se aplica por defecto. Los SDKs de OpenZiti usan TLS mutuo para la conexión, junto con encriptación basada en libsodium del payload real — así el tráfico permanece ilegible incluso si un router en medio está comprometido.
• Enrutamiento inteligente recalcula las rutas en la malla según cambian las condiciones, permitiendo que la red dirija alrededor de routers degradados o sobrecargados en lugar de depender de un único salto fijo. (Una advertencia: algunos materiales de marketing presentan esto como “superar BGP,” pero la documentación de OpenZiti no hace esa afirmación específica — la selección de ruta opera en la capa overlay, sobre el enrutamiento de internet subyacente, no en competencia con él.)

Los tres niveles de despliegue

La propia documentación de OpenZiti especifica claramente que no es una sola herramienta con una única vía de integración — es una plataforma que se adopta de forma incremental, y nombra directamente tres niveles:

1. Acceso a redes Zero Trust. Un router de borde de OpenZiti se sitúa en el límite de una zona de red confiable; el tráfico autenticado entra en la overlay y sale a la red privada donde residen los servicios legacy. Sin cambios en el código ni en la app — este modelo es para organizaciones que quieren acceso Zero Trust sin modificar su infraestructura existente.

2. Acceso a host Zero Trust (Tunnelers). Un tunneler ligero de OpenZiti corre en el mismo host que el servicio objetivo — disponible para Linux, Windows, macOS, iOS y Android. El tunneler intercepta y encripta el tráfico de forma transparente; el servicio solo necesita aceptar conexiones desde localhost. Sin cambios en el código, pero el límite de confianza ahora se reduce al sistema operativo del host en lugar de toda la zona de red.

3. Acceso a la aplicación (SDKs). La postura más fuerte, y la que realmente trata este artículo. Se integra un SDK de OpenZiti directamente en el código cliente o servidor. La app misma mantiene la identidad criptográfica y realiza la encriptación en proceso — no hay ningún puerto de escucha, ni siquiera en loopback. El servicio está “oscuro”: nada que escanear, nada que sondear, porque no hay nada escuchando.

Los SDKs están disponibles en siete lenguajes: Go, C, Python, Node.js, Java/Kotlin, Swift y C#/.NET (confirmado directamente contra los repos de SDK de openziti/ziti y en cada lenguaje). También hay un SDK en JavaScript para navegador (parte del proyecto “browZer”) para servir apps web Zero Trust sin necesidad de instalar un cliente, una categoría que la mayoría de las herramientas de túnel con CLI no abordan realmente.

La mayoría de los equipos empieza usando tunnelers para servicios existentes — se despliega en minutos sin cambios en el código — y pasa a SDKs embebidos en la app para trabajos nuevos, de alta seguridad o en entornos greenfield, donde el esfuerzo adicional de integración reduce significativamente la superficie de ataque.

zrok: La capa de compartición construida sobre OpenZiti

Configurar identidades y routers de borde manualmente es trabajo de infraestructura real, algo que la mayoría de desarrolladores quiere evitar solo para compartir un servidor local con un compañero. zrok existe para eliminar esa fricción — es una herramienta de compartición peer-to-peer de código abierto, “ziti-native”, que provee una overlay basada en identidades en lugar de un relay en la nube, manteniendo la experiencia de “obtener una URL pública” con un solo comando.

Comparación de funciones

Función	Proxy en la nube tradicional (ej. ngrok)	zrok (malla OpenZiti)
Arquitectura centralizada	Relay HTTP/TCP centralizado	Overlay distribuido, basado en identidades y Zero Trust
Licencia	Propietaria, cerrada	Open-source (Apache 2.0), auto-hospedable
Puertos entrantes	Expone un endpoint mediante un listener público	Solo conexiones salientes; sin puerto entrante en tu máquina
Compartición de recursos	Principalmente endpoints HTTP	HTTP/TCP/UDP, más compartición de archivos y unidades de red WebDAV
Nivel gratuito (servicio gestionado)	Varía según proveedor y plan	5 GB/día transferencia, hasta 25 entornos, 50 backends compartidos, 50 frontends privados
Fricción en la primera visita	Intersticial anti-phishing en cuentas gratuitas no verificadas	Igual — zrok muestra una advertencia similar en cuentas no verificadas, que se puede eliminar verificando con una tarjeta sin costo

Esa última fila vale destacarla: zrok no está exento de la fricción que a veces se asocia solo con ngrok. Ambas herramientas muestran una advertencia en la primera visita para proteger contra abusos de phishing en URLs efímeras de nivel gratuito.

URLs públicas vs. compartición privada peer-to-peer

zrok soporta el flujo de trabajo familiar de URLs públicas — zrok share public http://localhost:3000 te da una URL HTTPS como https://your-share.share.zrok.io, útil para probar un webhook de Stripe o GitHub, o para demo de una interfaz a un cliente no técnico.

El diferenciador es compartición privada, que nunca crea una URL pública ni un registro DNS:

1. El host ejecuta zrok share private http://localhost:8080 y recibe un token de acceso efímero y único — no una URL.
2. Ese token se envía fuera de banda, por un canal de confianza (chat encriptado, gestor de secretos).
3. El destinatario ejecuta zrok access private <token> en su máquina.
4. zrok inicia un proxy local en el lado del destinatario (por ejemplo, http://localhost:9090) que túnela hacia el servicio del host a través de la overlay verificada por identidad.

Al no crearse frontend público ni registro DNS para una compartición privada, realmente no hay nada que un escáner o bot pueda encontrar — la conexión solo existe entre dos endpoints autenticados.

zrok también ofrece un SDK propio, basado en el SDK de OpenZiti en Go, para que los equipos puedan integrar la compartición en sus propias herramientas en lugar de usar la CLI:

// cargar un entorno zrok habilitado
root, err := environment.LoadRoot()

// solicitar una compartición privada para un recurso local
shr, err := sdk.CreateShare(root, &sdk.ShareRequest{
    BackendMode: sdk.TcpTunnelBackendMode,
    ShareMode:   sdk.PrivateShareMode,
})

// aceptar conexiones para ese recurso
listener, err := sdk.NewListener(shr.Token, root)

zrok v2.0: ¿Qué cambió realmente?

zrok lanzó una versión importante v2.0 en 2026, y dado que muchos tutoriales y scripts existentes aún usan sintaxis v1, vale ser precisos sobre qué es diferente:

• El binario ahora es zrok2, no zrok. Esto fue una elección deliberada para que v1 y v2 puedan correr en paralelo sin interferencias, sin forzar una migración. v2 usa su propio directorio de entorno (~/.zrok2 en lugar de ~/.zrok), su propio prefijo de variables de entorno (ZROK2_* en lugar de ZROK_* — por ejemplo, ZROK2_API_ENDPOINT, ZROK2_ADMIN_TOKEN), y paquetes y unidades systemd separadas (zrok2, zrok2-agent, configuración en /etc/zrok2). Puedes habilitar un entorno v2 limpio con zrok2 enable sin afectar la configuración v1 existente.
• Las comparticiones reservadas fueron reemplazadas por un modelo de espacio de nombres/nombres. Los comandos antiguos zrok reserve / zrok release / zrok share reserved desaparecieron. En su lugar, zrok2 create share y zrok2 delete share gestionan comparticiones públicas y privadas, y zrok2 modify name -r puede promover una compartición efímera a una persistente en tiempo real — ya no es necesario eliminar una compartición solo para hacer su nombre permanente.
• El modo backend VPN fue eliminado. Versiones anteriores de zrok (y algunos tutoriales, incluyendo el borrador de este artículo) mencionaban la opción --backend-mode vpn para compartir en modo VPN host-to-host. Esa capacidad fue retirada en v2 debido a conflictos con las librerías TUN que dependían, no solo para reforzar el enrutamiento Zero Trust.

Instalación y primeros pasos

En macOS y Linux, la fórmula actual de Homebrew para la línea v2 es:

brew install zrok2

(La fórmula original v1, zrok, todavía existe y funciona si la necesitas.) En Windows, la forma más confiable es descargar la versión actual directamente desde la página de lanzamientos de zrok en GitHub — no pudimos verificar un bucket oficial de Scoop mantenido para el binario v2 en el momento, así que en lugar de eso, te dirigimos a la página de lanzamientos.

Una vez instalado:

zrok2 invite      # registrarse en el servicio gratuito zrok.io (sin token de invitación separado)
zrok2 enable       # vincular tu dispositivo a tu entorno zrok
zrok2 share public localhost:3000

Para equipos que necesitan soberanía total de datos — entornos regulados que gestionan HIPAA, GDPR o SOC 2 — zrok es completamente auto-hospedable. La pila Docker Compose auto-hospedada no es solo un contenedor: ejecuta un ziti-controller y ziti-router para la capa de control/datos de OpenZiti, postgresql para la base de datos de zrok, rabbitmq para actualizaciones de mapeo frontend, zrok2-controller y zrok2-frontend para la API y proxy de compartición pública, además de opcionalmente caddy (terminación TLS) y servicios de métricas con influxdb. Es infraestructura significativamente mayor que “descargar un binario”, importante de saber si planeas desplegar en tu propia infraestructura.

Aplicaciones del mundo real

Automatización de webhooks sin reglas de firewall entrantes

Usando el SDK de Node.js de OpenZiti, equipos han creado flujos de trabajo en GitHub Actions donde un pipeline CI/CD puede activar de forma segura un script de build o despliegue en un servidor interno — sin que el equipo de red abra puertos entrantes ni gestione reglas NAT.

Compartición peer-to-peer de archivos y unidades

Debido a que zrok resuelve el problema de “quién tiene la dirección” de la misma forma que la compartición de servicios, es ideal para compartir archivos ad hoc y montar carpetas compartidas como unidades WebDAV directamente en la overlay, sin montar un servidor dedicado de compartición.

Infraestructura Zero Trust para agentes AI y MCP

Esta es la parte del ecosistema que más ha avanzado, y donde muchas publicaciones anteriores (incluyendo borradores anteriores de este blog) ya están desactualizadas. A mediados y finales de 2026, NetFoundry ha patrocinado un pequeño clúster de proyectos con licencia Apache 2.0, diseñados específicamente para ello — y vale ser preciso sobre qué hace cada uno, porque sus ámbitos se superponen de formas fáciles de confundir:

openziti/llm-gateway es un proxy API compatible con OpenAI. Su propia documentación describe enrutamiento nativo a OpenAI, Anthropic y cualquier backend compatible con OpenAI — Ollama, vLLM, llama-server, SGLang, y servidores de inferencia auto-hospedados similares. (Una corrección: algunos artículos anteriores, incluyendo una versión previa de este, lo describían como enrutando nativamente a AWS Bedrock y Google Vertex AI. El repositorio del proyecto no afirma soporte nativo para esas plataformas — puedes acceder a un endpoint compatible con OpenAI a través de un backend “cualquier compatible”, pero no hay un adaptador dedicado.) Realiza enrutamiento semántico mediante una cascada de tres capas — heurísticas de palabras clave, similitud de embeddings, y un clasificador LLM como respaldo — para seleccionar automáticamente un modelo cuando el cliente no especifica uno, además de balanceo de carga ponderado con verificaciones de salud en un pool de servidores de inferencia. Es un binario en Go sin base de datos ni cola de mensajes, y puede exponerse opcionalmente a través de zrok para que un gateway en NAT o en red aislada sea accesible sin abrir un puerto.

openziti/mcp-gateway proporciona a asistentes AI acceso Zero Trust a servidores MCP. En sus versiones recientes, está compuesto por tres componentes (el proyecto llama a esto “la Tríada”): mcp-tools conecta un cliente MCP a una compartición zrok remota o un túnel Agora; mcp-gateway agrupa múltiples backends de servidores de herramientas en una única conexión con espacio de nombres (los comandos de herramientas de un servidor de archivos y un servidor GitHub aparecen como fs:read_file y github:create_issue en el mismo endpoint, con filtros de permitir/denegar por herramienta); y mcp-bridge expone un único servidor MCP local en la red. Los backends pueden ser procesos locales stdio o servidores MCP remotos HTTP(S)/SSE, las comparticiones ahora pueden ser persistentes (el gateway puede reiniciar sin cambiar su token), y soporta transporte HTTP Streamable y stdio para clientes que necesitan un endpoint HTTP simple.

ziti-mcp-server es un proyecto distinto de mcp-gateway, a pesar del nombre — envuelve la API de gestión de OpenZiti, exponiendo unos 200 tools que cubren identidades, servicios, routers de borde y políticas como herramientas MCP. Eso permite que un agente en Claude Desktop, Cursor, o un cliente similar, provisione routers y gestione políticas de red de forma conversacional, en lugar de agregar otros MCP servers.

openziti/agora es la adición más reciente y no formaba parte del panorama hace unos meses: un overlay Zero Trust pre-1.0, diseñado para comunicación entre agentes (A2A), compatible con el protocolo A2A y añadiendo la capa de identidad, descubrimiento y políticas de OpenZiti debajo. mcp-gateway ya puede usarlo como transporte alternativo a zrok, sirviendo herramientas sobre túneles “Layer 1” de Agora y publicándose en un catálogo para descubrimiento.

Lo que une estos cuatro proyectos es el mismo argumento de este artículo sobre túneles: un endpoint MCP o un gateway de inferencia puede compartirse igual que un backend HTTP privado — autenticado, encriptado, y sin nada escuchando en una IP pública que un escáner pueda detectar.

La conclusión

La conveniencia de escribir un solo comando y obtener una URL pública no desaparecerá, y para muchas tareas diarias sigue siendo la herramienta adecuada. Pero “conveniencia” y “expuesto a internet” no tienen que ser un compromiso igual. El modelo en capas de OpenZiti — acceso a nivel de red sin cambios en el código, túneles a nivel de host sin cambios, o SDKs embebidos en la app para la postura más fuerte — permite a un equipo decidir cuánto de ese compromiso realmente quiere asumir, servicio por servicio, en lugar de aceptar un único patrón por todo.

zrok es la vía rápida para hacer accesibles los dos primeros niveles en minutos; los SDKs están para los servicios donde “oscuro por defecto” vale la pena el esfuerzo adicional de integración.

---

Cambios recientes

Corregido: - Se reemplazó la línea vaga “lanzamiento importante de zrok v2 introdujo el binario zrok2” por los cambios reales y documentados de v2.0: renombre del binario/entorno/variables (~/.zrok2, ZROK2_*), el modelo de espacio de nombres/nombres en lugar de comparticiones reservadas, y — la verdadera razón del comentario en borrador sobre “eliminación de modos legacy VPN” — que el modo VPN fue retirado por conflictos con librerías TUN, no solo para reforzar el enrutamiento Zero Trust. - Se corrigió la lista de proveedores de openziti/llm-gateway. Se afirmó soporte nativo para Anthropic, AWS Bedrock y Google Vertex AI, pero el repositorio indica soporte nativo solo para OpenAI y Anthropic, y cualquier backend compatible con OpenAI (Ollama, vLLM, llama-server, SGLang). No hay soporte nativo para Bedrock, Vertex o Azure OpenAI. - Se corrigió y amplió la descripción de mcp-gateway. Se aclaró que no es la misma cosa que ziti-mcp-server, y que mcp-gateway ahora tiene tres componentes (mcp-tools, mcp-gateway, mcp-bridge) que gestionan y exponen MCP tool servers, mientras que ziti-mcp-server envuelve la API de gestión de OpenZiti con unos 200 tools. - Se suavizó la afirmación no verificada de que el enrutamiento inteligente de OpenZiti “evade BGP”; se describió en términos de recalculación de rutas en la overlay sin sobrepasar la capa de enrutamiento de internet. - Se reemplazó la instrucción no verificada scoop install zrok por una nota que no se pudo verificar un bucket oficial de Scoop para v2, y se dirigió a la página de lanzamientos en GitHub.

Añadido: - Los nombres específicos y documentados que OpenZiti usa para sus tres niveles de despliegue (Zero Trust Network Access / Zero Trust Host Access / Application Access), en lugar de términos genéricos. - Se añadió una sección sobre openziti/agora, un overlay Zero Trust pre-1.0 para comunicación A2A, que mcp-gateway puede usar como transporte alternativo. - Soporte para comparticiones persistentes y transporte HTTP Streamable en mcp-gateway en versiones posteriores. - Un ejemplo de código real del patrón de compartición privada en SDK de zrok en Go. - Desglose concreto del listado de servicios en la pila Docker Compose auto-hospedada. - Se confirmaron y mantuvieron cifras precisas del listado de lenguajes SDK, encriptación libsodium/mTLS, y límites del nivel gratuito de zrok.

Eliminado: - Frases repetitivas y keyword-stuffing, en línea con la limpieza de otros artículos en este blog.

Fuentes verificadas: - Repos y README de openziti/ziti y openziti/zrok, changelog y notas de lanzamiento; blog de OpenZiti; documentación de NetFoundry; página de precios de zrok; repos SDK de varios lenguajes; repos de openziti/llm-gateway, openziti/mcp-gateway y openziti/agora; artículo previo del blog comparando ngrok y zrok (instatunnel.substack.com, julio 2026).