Edge Bridge & Conectividad Local

Gran parte de los hoteles, clínicas y empresas tradicionales operan sobre sistemas de gestión antiguos (_legacy_) o servidores de escritorio instalados bajo el mostrador (MiniHotel, Fidelio, bases de datos SQL locales, terminales fiscales) que no poseen APIs públicas en la nube.

Exponer estos servidores directamente a internet abriendo puertos en el router del cliente o configurando VPNs complejas es inseguro, frágil ante caídas de IP dinámica y prohibitivo a nivel de mantenimiento.

---

Arquitectura de Conexión Inversa

RED PRIVADA DEL CLIENTE (LOCAL)                   NUBE DE ORBIS (CONTROL PLANE)
┌─────────────────────────────────────┐           ┌────────────────────────────────┐
│  Servidor PMS / SQL Local           │           │  Orbis Control Plane           │
│  [192.168.1.50:8080]                │           │  (Next.js / API Cifrada)       │
└──────────────────▲──────────────────┘           └────────────────▲───────────────┘
                   │ Sondeo HTTP interno                           │
┌──────────────────┴──────────────────┐           HTTPS Saliente   │ Envelopes v2
│  Edge Bridge Daemon (Node/Go)       ├─────────── (Outbound Only) ┘ (HMAC-SHA256)
│  • Token Hash Criptográfico         │
│  • Cola Outbox & Deduplicación      │
│  • Sonda LAN pasiva (lan.scan)      │
└─────────────────────────────────────┘

El servidor central de Orbis nunca intenta conectarse directamente hacia la IP del hotel. En su lugar, el puente local inicia todas las conexiones hacia el exterior, realizando dos operaciones continuas:

1. Push Outbox (Telemetría y Reportes): Envía lecturas de estado y eventos locales hacia /api/edge/sync.

2. Pull Commands (Instrucciones Pendientes): Consulta si existen tareas encoladas para la red local (ej. realizar un bloqueo en el PMS o escanear un nuevo puerto) hacia /api/edge/pull.

---

Firma Criptográfica de Envelopes (HMAC-SHA256 v2)

Toda comunicación entre el Edge Bridge y el control plane está blindada contra manipulación o suplantación mediante firmas criptográficas:

• Estructura del Envelope v:2: Cada mensaje empaqueta { v: 2, tenant, key, kind, at, body }.
• JSON Canónico: Los campos se normalizan en un formato JSON determinístico sin variaciones de espaciado.
• Firma HMAC: Se firma con una clave derivada del token hash del puente (sha256(token)).
• Verificación Fail-Closed: Si un mensaje llega al servidor con una firma ausente, expirada o que no coincida con el hash registrado, la petición es rechazada de inmediato con código 401 Unauthorized.

---

Protocolo de Emparejamiento Seguro (Enrollment RFC 8628)

El alta de un nuevo puente no requiere compartir contraseñas ni configurar claves a mano en la máquina local:

1. El instalador corre 'orbis-edge enroll' en la terminal del hotel.
2. El puente genera un código de vinculación temporal (ej: "ORB-7492").
3. El supervisor ingresa al panel web de Orbis y aprueba el código "ORB-7492".
4. El puente recibe una credencial de token única (Single-use Token).
5. El servidor destruye el token en texto claro y persiste exclusivamente su hash SHA-256.

Una vez completado el emparejamiento, el daemon queda vinculado irrevocablemente al _tenant_ del cliente.

---

Descubrimiento LAN Pasivo (`lan.scan`)

Cuando se instala un puente en una sede nueva, no es necesario conocer la IP exacta del PMS o del sistema de facturación:

1. El panel encola un comando lan.scan para el puente.

2. El puente ejecuta un escaneo pasivo de puertos HTTP comunes en la subred privada local (192.168.1.0/24).

3. El puente remite un informe lan.report con los servicios detectados (ej: _"Posible servidor PMS en 192.168.1.50:8080"_).

4. Confirmación Humana Obligatoria: El dueño o supervisor revisa los hallazgos en la pantalla /puentes y hace clic en Confirmar Sistema. Ningún servicio no confirmado es sondeado jamás.

---

Vigilancia Activa de Salud (`system.health`) & Incidentes

Una vez que un sistema local (como el PMS) es confirmado, el Edge Bridge aplica una política de vigilancia continua:

• Sondeos periódicos: Cada 30 a 60 segundos, el puente envía una petición HTTP liviana de diagnóstico al servidor local.
• Tolerancia a fallos: Si el servidor responde cualquier código HTTP válido, se reporta como operativo (status: UP).
• Derivación de Incidentes Automáticos:

- Incidente system_down: Si el PMS local falla dos sondeos consecutivos (por ejemplo, si se cortó la luz en la oficina o se apagó la máquina del recepcionista), Orbis deriva un incidente crítico de inmediato.

- Incidente bridge_silent: Si el propio puente deja de reportar telemetría por más de 15 minutos, el sistema alerta al dueño: _"⚠ El puente de red en Sede Centro perdió conexión a internet"_.

• Aviso Proactivo antes de perder ventas: El dueño se entera del problema técnico antes de que un huésped intente reservar y encuentre el sistema caído.