La muerte del relay público: migrando a túneles localhost de Zero-Trust

Deja de transmitir tus APIs locales no autenticadas a internet. Descubre cómo los tejidos de túneles Zero-Trust requieren verificaciones criptográficas de identidad antes de que un paquete toque tu máquina.

---

Durante más de una década, desarrolladores e ingenieros de redes han confiado en herramientas de relay públicas para sortear firewalls estrictos, NAT de grado carrier (CGNAT) y restricciones en redes locales. Si necesitabas mostrar una aplicación web local a un cliente, probar un webhook de un proveedor de pagos externo, o colaborar en una base de datos local, el flujo de trabajo era simple: iniciar una herramienta como ngrok, obtener la URL pública aleatoria, y compartirla.

Sin embargo, a medida que avanzamos en 2026, la era de enviar una URL pública aleatoria a un cliente o suite de pruebas está llegando a su fin rápidamente. El panorama digital se ha vuelto demasiado hostil, y las superficies de ataque automatizadas se han vuelto demasiado sofisticadas para confiar en la seguridad por oscuridad. El paradigma legado de abrir un agujero desde internet directamente a tu localhost está siendo reemplazado por redes Zero Trust nativas en identidad.

En esta guía, exploraremos por qué el relay público está muriendo, profundizaremos en la mecánica del tunneling Zero-Trust, examinaremos por qué herramientas basadas en OpenZiti (como Zrok) se están convirtiendo en la alternativa definitiva a ngrok, y demostraremos cómo compartir localhost privado está transformando los flujos de trabajo de los desarrolladores.

---

1. La anatomía de un relay público (y por qué es obsoleto)

Para entender la revolución, primero debemos comprender el sistema legado. Las herramientas tradicionales de tunneling operan en una arquitectura de “Relay Público”.

Cuando un desarrollador ejecuta un comando para exponer un puerto local (por ejemplo, puerto 8080), un agente ligero en su máquina inicia una conexión TCP saliente a un servidor en la nube gestionado por el proveedor del tunneling. Luego, el proveedor genera un subdominio accesible públicamente (como cadena-aleatoria.tunnel-provider.com) y lo vincula a esa conexión. Todo el tráfico que llegue a esa URL pública se reenvía a través del túnel establecido directamente a la máquina local del desarrollador.

La falacia de la seguridad por oscuridad

Históricamente, los desarrolladores asumían que, dado que la URL era una cadena aleatoria, era prácticamente imposible de adivinar y, por tanto, segura. En 2026, esto es una falacia peligrosa.

Los ciberdelincuentes modernos despliegan botnets de escaneo distribuidos que monitorean en tiempo real los registros de Certificate Transparency (CT). Los registros CT son libros públicos, de solo adición, que registran cada certificado SSL/TLS emitido por autoridades de certificación confiables — un sistema originalmente diseñado para la responsabilidad de certificados, pero cada vez más explotado como herramienta de reconocimiento. Para finales de 2025, Let’s Encrypt solo emitía diez millones de certificados por día, protegiendo más de 550 millones de sitios web, haciendo que los registros CT sean una fuente extraordinariamente rica de inteligencia de amenazas y descubrimiento de superficies de ataque. El momento en que un proveedor de tunneling legado provee un certificado SSL/TLS para un nuevo subdominio aleatorio, bots automatizados pueden raspar la URL y comenzar a buscar vulnerabilidades comunes — a menudo en cuestión de minutos tras poner en línea el túnel.

En 2026, con más de 8.2 mil millones de certificados registrados en varios sistemas CT, estas bases de datos ofrecen a los atacantes una ventana sin precedentes a la infraestructura digital de cualquier organización, mucho más allá de la enumeración tradicional de subdominios. Si expones una base de datos de desarrollo no autenticada, una interfaz de depuración con ejecución remota de código (RCE) habilitada, o una API sin limitación de tasa, la ventana de exposición comienza en el instante en que se provisiona tu túnel.

El problema de confianza

Además, los túneles tradicionales operan en base a confianza centrada en la red. El firewall se evita por completo. El borde de la red — el punto donde se acepta o rechaza el tráfico — reside en los servidores del proveedor en internet, no en tu máquina. Para cuando un payload malicioso llega a tu localhost, ya ha eludido tus defensas perimetrales.

---

2. La entrada del tunneling Zero-Trust

La respuesta de la industria de ciberseguridad a esta vulnerabilidad es la adopción generalizada de la Arquitectura Zero Trust. Aunque Zero Trust ha sido una palabra de moda para reemplazos de VPN corporativos durante años, 2026 marca el año en que ha penetrado completamente en el ecosistema de herramientas para desarrolladores, manifestándose como tunneling Zero-Trust para los flujos de trabajo cotidianos.

Cambiando el perímetro a la identidad

En una red Zero Trust, no existe una URL pública. No hay un puerto abierto en internet. El concepto de “conectarse a una red” es reemplazado completamente por “conectarse a una identidad.”

En lugar de generar un relay público que cualquiera en internet pueda alcanzar, un túnel Zero-Trust crea un overlay privado en malla. Cuando quieres compartir un servicio local, no recibes una URL; recibes un token de autenticación criptográfica. El usuario remoto (o servicio) debe usar un agente propio, proporcionando ese token, para demostrar matemáticamente su identidad antes de que se le permita enrutar un paquete a través de la red en malla.

Si un escáner no autorizado intenta sondear el servicio, no obtiene solo un error 403 Forbidden — obtiene absolutamente nada. El servicio es funcionalmente invisible para internet. Esto se conoce como “Infraestructura Oscura.” Puertos en escucha cero significan superficie de ataque cero. Los clientes autorizados se conectan a través del overlay; todos los demás no ven nada.

---

3. OpenZiti: La estructura de redes nativas en identidad

En el corazón de esta transformación está OpenZiti, una plataforma de redes de código abierto, de confianza cero, creada y patrocinada por NetFoundry. Licenciada bajo Apache 2.0, OpenZiti no es solo una herramienta de tunneling; es una red overlay programable que hace que los servicios sean invisibles para usuarios no autorizados.

Cada conexión en una red OpenZiti — ya sea de un usuario humano, un microservicio, o un dispositivo IoT — es autenticada mediante identidad criptográfica, autorizada por un controlador de políticas centralizado, y cifrada de extremo a extremo usando estándares modernos incluyendo mTLS (Mutual Transport Layer Security).

OpenZiti funciona con aplicaciones existentes usando tunneleros ligeros (sin cambios en el código necesarios) y con nuevas aplicaciones usando SDKs integrados para el modelo de confianza cero más fuerte. Esto lo hace práctico tanto para entornos legados como para desarrollo en entornos nuevos. En 2026, su adopción crece porque la confianza cero pasa de ser un lenguaje de políticas empresariales a un diseño de infraestructura controlado por desarrolladores: equipos distribuidos, infraestructura híbrida, y tráfico máquina a máquina han hecho que la seguridad basada en perímetros sea menos efectiva que nunca.

Los tres pilares del despliegue de OpenZiti

OpenZiti soporta a organizaciones en tres fases distintas de adopción de confianza cero:

ZTNA (Zero Trust Network Access): El modelo más tradicional. Un router de borde OpenZiti se coloca dentro de una zona de red confiable. Los usuarios se conectan al router vía overlay de confianza cero, y este reenvía el tráfico a la LAN interna. Aunque mejor que una VPN, la confianza aún existe en el segmento de red local.

ZTHA (Zero Trust Host Access): En este modelo, un tunneler OpenZiti corre directamente en la máquina host que opera el servicio. El firewall del sistema operativo del host está configurado para denegar por defecto todo tráfico entrante. El servicio solo es accesible vía localhost, y el tunneler intercepta y enruta el tráfico autorizado del overlay directamente a él. Esto elimina el movimiento lateral east-west en la red. Para tunneling de desarrollador, este modelo ofrece el equilibrio ideal entre seguridad y conveniencia sin cambios en el código.

ZTAA (Zero Trust Application Access): La máxima seguridad en redes. Embebiendo un SDK de OpenZiti (disponible en Go, Python, C, Java, Node.js, y más) directamente en el código de la aplicación, la propia aplicación posee la identidad criptográfica. No se enlaza a ningún puerto de red — ni siquiera localhost. La comunicación de la aplicación se realiza completamente en el espacio de memoria de confianza cero.

La capa de gestión se autogestiona

Un desarrollo importante a principios de 2026: comenzando con OpenZiti 1.8, las APIs del controlador pueden enlazarse como servicios OpenZiti. La misma confianza cero embebida en la app que asegura tus aplicaciones ahora asegura también la capa de gestión. Esto es un hito arquitectónico relevante — significa que el canal de control que rige toda la estructura de red está sujeto a la misma verificación de identidad criptográfica que las cargas de trabajo que administra, cerrando una clase de vectores de ataque que antes requerían endurecimiento separado.

---

4. Zrok: La herramienta de tunneling nativa en OpenZiti para desarrolladores

Mientras OpenZiti proporciona la base de nivel empresarial, configurar toda una malla en overlay requiere infraestructura. Aquí es donde entra Zrok. Construido directamente sobre la estructura de OpenZiti y desarrollado por NetFoundry, Zrok está diseñado específicamente para ser la herramienta de tunneling definitiva orientada a desarrolladores en este nuevo paradigma.

Zrok toma las capacidades complejas y potentes de OpenZiti y las empaqueta en una experiencia CLI sencilla y sin fricciones, pensada para desarrolladores, testers y equipos de operaciones.

Comparticiones públicas vs. comparticiones privadas

Zrok reconoce que hay momentos en los que debes tener una URL pública — por ejemplo, cuando un proveedor de webhook externo como GitHub, Stripe, o Twilio requiere un endpoint HTTPS estándar. Para estos escenarios, Zrok ofrece zrok share public, que provisiona una URL pública segura y efímera. La infraestructura de OpenZiti de Zrok asegura que, para comparticiones privadas, no se cree ningún endpoint público: la conexión existe solo entre participantes autenticados en la red en malla.

Pero, la verdadera potencia de Zrok radica en su función insignia: compartición privada localhost.

Mecánica de la compartición privada localhost

Cuando un desarrollador inicia una compartición privada:

zrok share private localhost:8080

Zrok no expone el servicio a internet. En su lugar, el agente local de Zrok establece una conexión saliente con la malla OpenZiti y genera un token de compartición criptográfico único (por ejemplo, share_token_xyz123).

El desarrollador transmite este token de forma segura al destinatario, quien ejecuta:

zrok access private share_token_xyz123

Su agente local se autentica en la red en malla usando el token, enlaza dinámicamente un puerto local en su máquina (por ejemplo, localhost:9191), y establece una conexión cifrada de extremo a extremo con la máquina original del desarrollador. Cuando el destinatario navega a http://localhost:9191, el tráfico se enruta sin problemas a través de la malla Zero-Trust.

El resultado:

• No se abrieron puertos en el firewall
• No se crearon registros DNS públicos
• Ningún escáner automatizado pudo detectar la transacción
• La superficie de ataque es efectivamente cero

Modos de backend

La compartición privada de Zrok soporta varios modos de backend para diferentes flujos de trabajo:

• tcpTunnel — túneles TCP específicos entre hosts; ideal para acceder a un servicio remoto (ejemplo: SSH: zrok share private --backend-mode tcpTunnel localhost:22)
• udpTunnel — túnel UDP completo para aplicaciones en tiempo real
• socks — crea un proxy SOCKS5 para reenvío dinámico de puertos a múltiples destinos a través de una sola compartición, útil para acceder a múltiples servicios en una red remota
• drive — convierte cualquier directorio local en un servidor de archivos seguro y compartible sobre la malla en confianza cero; comparte logs, binarios o activos directamente desde tu disco duro sin intermediarios de almacenamiento en la nube

e Nota sobre modo VPN: Una función anterior --backend-mode vpn fue introducida para tunneling VPN de host a host, pero fue eliminada en v1.1.11 por conflictos de dependencias con las librerías principales de zrok. El equipo de Zrok está explorando reintroducir la funcionalidad VPN como una herramienta independiente (zrok-vpn). Mientras tanto, los modos tcpTunnel y socks cubren la mayoría de los casos de uso que el modo VPN abordaba.

Dominios personalizados

Zrok ahora soporta dominios personalizados, permitiendo a las organizaciones provisionar comparticiones bajo su propio dominio (<token>.your.domain.co) en lugar de un subdominio genérico del proveedor. Esto es importante para equipos que necesitan endpoints consistentes y de marca para pruebas de integración, manteniendo el modelo de seguridad en confianza cero.

---

5. Más allá de HTTP: Túneles efímeros y protocolos avanzados

Los túneles legacy estaban altamente optimizados para tráfico web HTTP/HTTPS. El desarrollo moderno en 2026 requiere mucha más flexibilidad.

Soporte nativo para TCP y UDP

La capacidad nativa de Zrok para túneles TCP y UDP es una ventaja práctica para varias disciplinas:

Juegos y medios en tiempo real: El soporte UDP permite compartir servidores de juegos, aplicaciones VoIP, y transmisiones WebRTC en privado con latencia ultra baja, sin lidiar con configuraciones complejas de reenvío de puertos en routers.

Administración de bases de datos: Un administrador puede compartir de forma segura un flujo TCP en crudo de una instancia local de PostgreSQL o Redis con un científico de datos remoto usando un token privado. Los datos permanecen cifrados de extremo a extremo, cumpliendo requisitos como HIPAA o SOC2.

IoT y desarrollo en el borde: Herramientas como NVIDIA Jetson Orin Nano (que ofrece 40 TOPS de rendimiento AI en un módulo compacto) son comunes en desarrollo de AI en el borde y robótica — pero tradicionalmente requiere proximidad física. Zrok aporta identidad criptográfica a cada dispositivo en el túnel: si un sensor se compromete, puedes revocar su acceso al instante sin tocar la configuración de red.

Efemeralidad y reducción del radio de impacto

En ciberseguridad moderna, la permanencia es enemiga. Cuanto más tiempo permanece activo un túnel, mayor es el riesgo. Zrok adopta la efemeralidad por diseño. Las comparticiones privadas están destinadas a existir solo durante la tarea específica. Una vez probado un webhook o finalizada una revisión de código, el túnel se destruye. El token criptográfico se vuelve inútil, cortando inmediatamente la conexión y minimizando el radio de impacto potencial.

---

6. Flujos de trabajo avanzados: Pentesting y hacking ético

El cambio a compartir localhost privado ha impactado profundamente a la comunidad de ciberseguridad, especialmente a los Red Teams y pentesters.

Durante un compromiso autorizado, los hackers éticos necesitan frecuentemente capturar shells reversos o recibir callbacks de payloads usando frameworks como Metasploit o BeEF. Históricamente, tenían que abrir puertos entrantes en su infraestructura de ataque o usar relays públicos — exponiendo el listener reverso a terceros no autorizados en internet.

Con Zrok, un hacker ético puede enlazar su listener a 127.0.0.1, crear una compartición privada, y generar un token temporal. Esto les permite recibir callbacks en una red en malla segura y autenticada, eludiendo reglas estrictas de firewall saliente en la red objetivo, y asegurando que ningún tercero pueda secuestrar su infraestructura de comando y control (C2). El listener es invisible para internet durante toda la operación.

---

7. Conectividad de agentes AI: un caso de uso emergente

Uno de los desarrollos más interesantes en 2026 en el ecosistema OpenZiti es la emergencia de conectividad Zero-Trust para cargas de trabajo de agentes AI. NetFoundry ha publicado un ziti-mcp-server — un servidor MCP (Model Context Protocol) que expone más de 200 herramientas de la API de gestión de Ziti. Esto significa que los agentes AI pueden gestionar identidades, servicios, routers y políticas en una red OpenZiti usando los mismos primitives de confianza cero que para todo lo demás.

OpenZiti también ha publicado un gateway de confianza cero para LLMs: un proxy compatible con OpenAI con enrutamiento semántico y balanceo de carga entre OpenAI, Anthropic, Ollama, vLLM, y otros backends. El acceso basado en identidad, las claves API virtuales, y el cifrado de extremo a extremo son aplicados mediante OpenZiti, haciendo que incluso el tráfico de inferencia AI pueda mantenerse oscuro en internet. Esto señala una tendencia más amplia: a medida que las cargas de trabajo AI comunican cada vez más a través de APIs entre máquinas distribuidas, los mismos principios de confianza cero que rigen el tunneling para desarrolladores gobernarán la conectividad AI máquina a máquina.

---

8. Soberanía de datos y auto-hospedaje

Mientras NetFoundry ofrece una versión SaaS gestionada de Zrok en zrok.io con un generoso nivel gratuito, una prioridad clave para organizaciones en industrias reguladas es la soberanía de datos.

Debido a que Zrok y su estructura subyacente de OpenZiti son completamente de código abierto (Apache 2.0), las organizaciones pueden auto-hospedar completamente la plataforma usando Docker. Implementando sus propios routers de borde OpenZiti y controladores Zrok en su infraestructura en la nube o en su centro de datos, mantienen el control total sobre los metadatos de enrutamiento, claves criptográficas, y identidades de usuarios. Ejecutar Zrok auto-hospedado vía Docker con Caddy permite la renovación automática de certificados wildcard y protege la API de Zrok y las comparticiones públicas con TLS — sin depender de relays de terceros.

La implementación auto-hospedada no tiene límites en ancho de banda o cómputo, y no permite acceso de terceros a tus datos. Esta capacidad es esencial para organizaciones en finanzas, salud, y defensa gubernamental que están legalmente prohibidas de enrutar tráfico interno a través de un relay en la nube gestionado por un proveedor multi-inquilino.

---

9. Navegando el mercado de alternativas en 2026

La demanda de tunneling seguro ha impulsado una competencia intensa. Aquí una comparación honesta de la posición de cada herramienta:

Cloudflare Tunnels (cloudflared): Un excelente servicio de tunneling HTTP de alto rendimiento que se integra con la plataforma Zero Trust de Cloudflare para políticas de acceso, logs, y protección DDoS en el borde — y es gratuito sin límites de ancho de banda. Sin embargo, requiere que tu dominio esté en el ecosistema DNS de Cloudflare, carece de soporte UDP, limita tamaños de request, y solo soporta TCP en planes de pago.

ngrok: El gigante legado. Muy pulido, con excelentes funciones de inspección de webhooks. Sigue siendo principalmente una herramienta de URL pública, convirtiéndose en un objetivo alto para escáneres automatizados. Su modelo de precios para funciones empresariales (como SSO) es elevado, y su arquitectura de relay público expone el problema de los logs CT mencionado antes.

Tailscale / WireGuard: Fantásticos para conectar dispositivos conocidos y permanentes en una malla VPN. Sin embargo, son soluciones pesadas, no optimizadas para flujos efímeros y ad-hoc de “compartir este puerto por cinco minutos” que requieren los desarrolladores. Además, necesitan instalar un cliente en cada peer con anticipación.

Bore: Solo TCP, minimalista, open-source, sin dependencia de infraestructura. Bueno para casos simples, pero carece de funciones a nivel HTTP, autenticación, y UDP.

Zrok (OpenZiti): Cierra la brecha. Ofrece la conveniencia efímera y ad-hoc de ngrok, pero con el modelo de seguridad nativo en identidad y confianza cero de una red en malla completa como Tailscale — siendo además open-source, capaz de manejar UDP/TCP y compartir archivos, y auto-hospedable. La desventaja es una curva de aprendizaje más pronunciada en la configuración inicial comparado con ngrok http 8080, especialmente si se auto-hospeda toda la infraestructura OpenZiti.

---

Conclusión: Deja de transmitir, empieza a autenticar

Internet ha cambiado fundamentalmente. Los días en que se consideraba que las redes internas eran “de confianza” y el exterior “no confiable” han quedado atrás. La confianza ya no es un atributo geográfico o de red — debe ser probada criptográficamente por la identidad del solicitante.

Al migrar a plataformas de tunneling Zero-Trust como Zrok, los desarrolladores están adoptando el futuro de la colaboración segura. La transición de URLs públicas y aleatorias a comparticiones privadas y autenticadas neutraliza efectivamente el panorama de amenazas automatizadas: sin URL pública para escanear, sin puerto para sondear, sin entrada en logs CT para recolectar. La decisión de OpenZiti 1.8 de poner también la capa de gestión bajo control de confianza cero indica que el ecosistema madura más allá de la conveniencia del desarrollador, hacia infraestructura de producción.

A medida que cargas de trabajo AI, dispositivos en el borde, y equipos distribuidos hacen que el perímetro de red sea cada vez más abstracto, la lección es la misma: cierra tus puertos entrantes, abraza la red oscura, y asegura que cada paquete que toque tu máquina sea verificado criptográficamente antes de llegar a tu aplicación.

---

Fuentes: OpenZiti Tech Blog; Documentación de NetFoundry; Comunidad Better Stack; Startupik; Have I Been Squatted CT Log Analysis (marzo 2026); Guía OSINT de Secybers (marzo 2026); Blog fxTunnel (febrero 2026); GitHub — openziti/zrok; GitHub — openziti/ziti.