Portal Tunnel
APIs locales del cliente, sin abrir la red
Llegamos a servicios que viven en la máquina del cliente (GoManage, APIs internas, etc.) sin publicar puertos ni exponer la API a Internet. El cliente inicia la conexión; nosotros solo reenviamos peticiones por un túnel saliente.
El problema
No se puede (ni se debe) abrir puerto
Las APIs de cliente suelen estar en 127.0.0.1 o en redes cerradas.
Abrir firewall, VPN por cliente o publicar la API es caro y arriesgado.
Cada instalación es distinta
El cliente decide qué rutas publica y con qué reglas. El control de acceso se queda en su máquina, no en un proxy genérico en la nube.
Misma idea que core-remote
WebSocket saliente + relay + JSON-RPC (StreamJsonRpc), el mismo patrón que
ya usamos en core-remote / core-rts.
Cómo funciona
127.0.0.1:8810/agents/connect, consola de pruebas y registro.
- Das de alta el agente aquí y obtienes una clave (se muestra una sola vez).
- Instalas el agente en el cliente con la URL del relay (
wss://…/agents/connect) y esa clave. - El agente se conecta solo; el portal ve el estado en tiempo casi real.
- Desde la consola (o una app futura) envías método + ruta + cuerpo; la respuesta vuelve por el mismo túnel.
Qué gana cada parte
Cliente / instalación
- No abre puertos entrantes ni publica la API.
- Decide qué rutas deja pasar y para quién (reglas locales).
- Puede cortar el acceso desconectando o desactivando el agente.
Nosotros (portal / soporte / producto)
- Probamos APIs reales del cliente sin VPN ad hoc.
- Vemos agentes conectados, errores y duración de cada petición.
- Misma estrategia reutilizable para otras apps (mismo contrato que api-remote).