metis-desk/docs/auditoria-exportacion-unifi-abeto-design.md

# Auditoría de la exportación UniFi de Abeto Design

Fecha: 18 de octubre de 2026.

Fuentes contrastadas:

- `UniFi_Inventario_20261018_141642_88f7af54-98f8-306a-a1c7-c9349722b1f6.json`, en la raíz del repositorio.
- Modelo, contratos y persistencia actuales de Assets y configuraciones de impresoras de Companies.
- Consulta de la base local, dentro de una transacción de **solo lectura**, para Abeto Design (Uecko).

No se han importado activos, modificado relaciones ni cambiado datos de la compañía.
El fichero original se conserva intacto. Por indicación del usuario, se ignoran los
errores 404 y las colecciones vacías: no se consideran incidencias ni condicionan
las recomendaciones. Este análisis distingue datos explícitos, coincidencias candidatas
e información que los registros presentes no permiten determinar.

## Dictamen

El modelo actual sirve para el alcance acordado: inventario de equipos, interfaces
con MAC/IP, conexiones entre activos y uso de impresoras mediante perfiles. Las 36
conexiones cliente → equipo de red reportadas en el fichero pueden representarse con
**Conectado a**, una vez identificados sus extremos. No hacen falta puertos ni cableado.

No conviene importar automáticamente todo el fichero. Los registros presentes no
identifican todas las interfaces ni la topología entre dispositivos de infraestructura,
y es necesario conciliar los hostnames con los activos existentes. Además,
hay ambigüedades concretas en el inventario.
La prioridad es preparar una conciliación revisable y conservar la procedencia de las
observaciones; no ampliar Metis hasta convertirlo en otro controlador de red.

## 1. Contenido y calidad de la exportación

El instante indicado en `metadata.fecha_utc` es el 18/10/2026 a las 12:16:04 UTC
(14:16:04 en Madrid). La versión declarada de UniFi Network es 10.6.106 y el sitio se
llama **Default**. La vinculación con Abeto procede del contexto proporcionado por el
usuario; ese nombre de sitio, por sí solo, no identifica una compañía ni una sede física.

| Conjunto | Registros | Observación |
| --- | ---: | --- |
| Dispositivos gestionados | 16 | 8 switches, 7 puntos de acceso y 1 UDM Pro, clasificados por los modelos y funciones exportados |
| Clientes | 36 | 24 WIRED y 12 WIRELESS |
| Redes/VLAN | 3 | Default/1, GUEST/4 y Energía/6 |
| Redes Wi-Fi | 2 | Una referencia NATIVE y otra SPECIFIC con `networkId` |
| WAN | 2 | Solo identificador y nombre |
| Políticas de firewall | 94 | 73 SYSTEM_DEFINED y 21 USER_DEFINED |
| Zonas de firewall | 6 | Incluyen referencias a redes |
| Listas de tráfico | 1 | Contiene 6 elementos |
| Perfiles RADIUS | 2 | Información resumida |
| Servidores VPN | 1 | Tipo WIREGUARD |
| Túneles VPN | 8 | 6 IPSEC y 2 OPENVPN; no incluyen toda su configuración |

Observaciones verificadas:

- Las colecciones principales son arrays dentro de un array: `datos.clientes[0]`,
  `datos.dispositivos[0]`, etc. Un lector debe normalizar esta estructura.
- Hay 52 identificadores, MAC e IP en las dos colecciones de equipos/clientes,
  sin duplicados entre ellas. Las 52 MAC tienen formato válido y todas las IP son IPv4.
  **Esto no prueba que existan 52 activos físicos diferentes**: pueden ser interfaces,
  controladoras de gestión u observaciones del mismo equipo.
- Los 36 `uplinkDeviceId` se resuelven contra los 16 dispositivos exportados.
- Todos los dispositivos gestionados figuran ONLINE. El fichero no representa un
  inventario completo de todos los equipos de la empresa ni de todos sus estados.
- Los dispositivos contienen `interfaces: ["ports"]` o `["radios"]`. Son etiquetas
  de capacidades; no hay nombres de interfaces, listas de NIC, IP por NIC ni uplinks
  de los switches/AP. Un AP con radio no permite asignar su IP de gestión a Wi-Fi.
- Hay texto con codificación dañada: tres nombres de dispositivos, uno de cliente y
  el nombre de la red Energía. Corregir la decodificación en el origen antes de importar.
- Dos clientes tienen MAC administradas localmente. Esa característica no demuestra
  aleatorización, pero aconseja no asumir que toda MAC sea una identidad permanente.

## 2. Cobertura del modelo de Metis Desk

| Información de UniFi | Encaje actual | Condición o límite |
| --- | --- | --- |
| Switch, AP, gateway, servidor, NAS, impresora, ordenador | Activos y plantillas | Elegir la plantilla por evidencia. Las funciones de infraestructura complementan el tipo de activo |
| Nombre y modelo | Nombre y características | Guardables; los nombres de cliente pueden ser alias o incluir sufijos de MAC |
| MAC e IP de un cliente | Interfaz con direcciones | WIRED/WIRELESS permite proponer Ethernet/Wi-Fi; confirmar la correspondencia con el activo |
| IP/MAC de gestión de dispositivo UniFi | Infraestructura del activo | Guardables, pero el resumen no demuestra qué interfaz física es propietaria de ambos valores |
| Varias interfaces y varias IP | Soportado directamente | Hasta 32 interfaces por activo y 32 IP por interfaz; el fichero no contiene su inventario completo |
| Cliente → switch/AP | Relación Conectado a | 36 candidatos con extremos externos resueltos; falta conciliarlos con activos de Metis |
| Switch → switch, AP → switch o switch → gateway | El modelo lo soporta | El fichero no trae esos uplinks; no se deben inventar a partir de IP o ubicación |
| Firmware | Característica de plantilla o nota | No es un campo estándar de las plantillas de serie ni hay sincronización automática |
| ONLINE, actualización disponible, acceso DEFAULT | Observación operativa | No equivale al estado técnico, la asignación o la disponibilidad de un activo en Metis |
| `connectedAt` | Fecha de conexión observada | No equivale a compra, alta del activo ni creación de una relación en Metis |
| Qué ordenadores usan una impresora | Configuraciones de impresora por perfil | El fichero no incluye instalaciones, colas, perfiles ni actividad de impresión |
| Redes, VLAN, SSID, WAN, zonas y reglas | Sin modelo especializado equivalente | Se podrían documentar descripciones en recursos; eso no preserva su estructura ni relaciones como modelo de red |
| VPN de sitio y sus túneles | Sin modelo especializado equivalente | No confundir túneles entre redes con autorizaciones personales de acceso remoto |
| Identidad UniFi | No se almacena por decisión del usuario | Se concilia por hostname y se revisan las ambigüedades; MAC/IP se conservan como información de las interfaces |

No debe afirmarse un porcentaje único de cobertura: conservar un nombre en notas
no equivale a representar una regla de firewall, una interfaz real o una relación
consultable. Para el objetivo **qué equipo es, qué IP tiene y a qué equipo de red se
conecta**, la cobertura conceptual es suficiente; la preparación de datos e importación
siguen pendientes.

## 3. Contraste con los datos actuales de Abeto Design

La consulta previa a la documentación de infraestructura encontró **53 activos**, de los que 7 tienen plantilla Impresora
y uno Firewall. Hay tres agregados de infraestructura, tres interfaces actuales,
dos direcciones actuales, una interfaz con MAC y **cero relaciones entre activos**.
Existe una configuración de impresora, asociada a la impresora de administración;
el recuento no se interpreta como confirmación de instalación efectiva.

### Impresoras

| Cliente observado | IP | Uplink exportado | Candidato existente en Metis |
| --- | --- | --- | --- |
| KYOCERA PRODUCCIÓN | 192.168.5.201 | USW Pro 24 | Impresora de producción; coincide la IP guardada como característica |
| Kyocera ECOSYS MA3500cix | 192.168.5.151 | USW Pro 24 | Impresora de compras; coincide IP y modelo |
| KM21A26C | 192.168.5.204 | Switch Lite 8 PoE (Administración) | Posible duplicidad entre Impresora de administración y ECOSYS MA3500ci |
| D0J201401228 04:b7 | 192.168.5.50 | USW-Lite-8-PoE (Empaquetadora) | Impresora de empaquetadora; coincide IP y nombre de host sin sufijo |

Son candidatos de conciliación, no uniones confirmadas por MAC: ninguna de estas
impresoras tiene actualmente una MAC estructurada que permita confirmarlas así.

- La impresora de administración conserva `.204` como característica y tiene una
  interfaz Ethernet **sin IP**. El activo ECOSYS MA3500ci guarda `KM21A26C` como nombre
  de host. UniFi vincula precisamente ese nombre con `.204`. Revisar físicamente o
  mediante serie/MAC antes de decidir si son el mismo equipo. No borrar ni fusionar
  automáticamente: uno tiene una configuración de impresión asociada.
- KM621D07 (`.202`) sí tiene `.202` en una interfaz actual; no aparece en esta
  exportación. La etiquetadora de técnicos (`.203`) tampoco aparece. Su ausencia no
  permite concluir que estén retiradas, averiadas o desconectadas permanentemente.
- Las cuatro conexiones de la tabla son representables con Conectado a. Los switches
  correspondientes todavía no constan como tales en el inventario consultado.
- Las IP como características y las IP de interfaces coexisten. Para nuevos datos,
  usar interfaces como referencia operativa y revisar los valores anteriores, sin
  mantener dos fuentes editables para el mismo dato a largo plazo.

### UDM y otros equipos

- El UDM Pro existente **coincide por MAC** con el dispositivo Uecko de UniFi. Metis
  conserva una interfaz Local con `192.168.5.1`; la exportación presenta una IP pública.
  No es una contradicción suficiente para reemplazar la IP local. El resumen no
  identifica la interfaz WAN ni su MAC; hace falta el detalle antes de asignar esa
  IP pública a una interfaz concreta. Tampoco debe crearse un segundo activo UDM.
- Los 16 clientes con nombres normalizados coincidentes apuntan a 15 nombres de
  ordenadores existentes. La normalización usada solo ignora mayúsculas, espacios
  exteriores y sufijos finales `xx:xx`. Son candidatos, no identidades verificadas.
- Dos entradas, `DDES1-PC` y `DDES1-PC 77:df`, tienen MAC, IP y uplinks distintos y
  apuntan al mismo nombre base. Pueden corresponder a dos interfaces del mismo equipo
  o a equipos diferentes. No unirlas ni crear dos puestos sin comprobarlo.
- `idrac-…` es un candidato a controladora de gestión de servidor, no una prueba de
  un servidor físico independiente. NOVASRV02 y UECKO-DS sugieren servidor/NAS por
  nombre, pero el tipo debe confirmarse. El resto incluye dispositivos que pueden
  necesitar plantillas propias y no necesariamente un puesto de trabajo.
- Hay un cliente WIRED cuyo uplink es U6 Mesh Pro. Conservar el dato como conexión
  reportada y revisarlo; no convertirlo en Wi-Fi por el tipo del equipo aguas arriba.

## 4. Auditoría de relaciones

Las relaciones actuales tienen buenas bases para este caso:

- Extremos obligatorios de la misma compañía y prohibición de autovínculos.
- Simetría de Conectado a, que permite consultar la conexión desde ambos activos.
- Prevención de duplicados activos, también invirtiendo extremos simétricos.
- Alta repetida equivalente idempotente y retirada que conserva autor y fecha.
- Separación entre composición exclusiva del puesto y uso compartido de impresoras.

Las limitaciones para una importación repetible son concretas:

1. **Granularidad:** el vínculo identifica dos activos, no qué interfaz establece
   la conexión. Es suficiente para una impresora y un switch. Si un portátil usa
   Ethernet y Wi-Fi con uplinks diferentes, el grafo puede guardar ambos vecinos,
   pero no asignarlos de forma estructurada a sus interfaces. Si ambas interfaces
   llegan al mismo activo, Conectado a solo conserva un vínculo por tipo y extremos.
2. **Dirección:** Conectado a es simétrica. Responde a qué equipos están conectados;
   no identifica por sí sola cuál es el uplink. No cambiar su simetría: conservar la
   dirección observada en los datos de procedencia o, si aparece una necesidad de
   consulta real, introducir un tipo dirigido adicional.
3. **Procedencia y vigencia observada:** el vínculo guarda quién lo documentó y
   cuándo, pero no fuente externa, fecha de observación ni última confirmación.
   Una observación UniFi y una relación introducida manualmente no son intercambiables.
4. **Movilidad:** una asociación Wi-Fi describe una observación temporal. Una nueva
   conexión no autoriza a retirar vínculos manuales ni a interpretar como bajas los
   equipos ausentes en una captura parcial.
5. **Semántica:** no hay restricciones por plantilla ni detección de ciclos. Esto
   no bloquea el caso acordado; el importador debe validar compatibilidad y mostrar
   casos ambiguos antes de proponer relaciones.

Conectado a no debe utilizarse para expresar «utiliza esta impresora»: ese uso
corresponde a las configuraciones por perfil. Tampoco estar en la misma red demuestra
que un equipo imprima en una impresora o consuma un servicio de un NAS.

## 5. Recomendación de evolución

Orden propuesto, sin implementar cambios de dominio en esta auditoría:

1. **Normalizar los datos presentes:** aplanar los arrays y revisar la codificación
   de los nombres. No es necesario repetir la exportación ni resolver los 404 para
   aprovechar los equipos, IP/MAC y conexiones que ya contiene.
2. **Conciliar antes de escribir:** pantalla de propuesta con activos existentes,
   altas nuevas y conflictos. Revisar especialmente UDM, administración y DDES1-PC.
   Tratar MAC/IP/nombre como evidencias con distinta fuerza, no como claves infalibles.
3. **Conciliación por hostname:** por decisión posterior del usuario no se guardan
   identificadores UniFi. Normalizar mayúsculas, espacios y sufijos de presentación
   identificados; conservar los nombres de los activos existentes. Los nombres
   repetidos o referencias que pueden señalar un duplicado requieren revisión.
   Los dos U6 Mesh Pro se distinguen con sus IP, según la elección del usuario.
4. **Procedencia de las conexiones:** guardar fecha de observación y origen,
   distinguir información manual/importada y mostrar qué va a cambiar. Una relación
   de importación con la interfaz local puede resolver Ethernet/Wi-Fi sin modelar
   puertos del switch. Evitar sustituir fechas de auditoría por `connectedAt`.
5. **Importación mínima:** equipos aprobados, MAC/IP verificadas y las 36 conexiones
   candidatas. Sin sobrescribir valores manuales conflictivos ni inferir retiradas.
   Dejar redes/VLAN detalladas, firewall, RADIUS y VPN en UniFi por ahora.

No se recomienda crear otra entidad paralela de equipo de red, guardar el JSON
completo como modelo de negocio ni convertir las redes, SSID y reglas en activos
físicos. Si más adelante se necesitan redes o servicios lógicos consultables, definir
un modelo acotado y relacional con consumidores reales, separado de la telemetría.

## Referencias de implementación revisadas

- [Infraestructura: contrato y límites](../modules/assets/src/api/domain/infrastructure-values.ts).
- [Activo: datos y características](../modules/assets/src/api/domain/asset-values.ts).
- [Plantillas de serie](../modules/assets/src/api/domain/asset-catalog-seed.ts).
- [Semántica de relación](../modules/assets/src/api/domain/value-objects/asset-relationship-values.vo.ts).
- [Contrato HTTP de relaciones](../modules/assets/src/common/relationships.ts).
- [Configuración de impresoras por perfil](../modules/companies/src/api/domain/printer-configuration-values.ts).
- [Documentación de infraestructura](infraestructura-informatica.md).
- [Reglas de relaciones entre activos](relaciones-entre-activos.md).

## Documentación posterior a la auditoría

El usuario autorizó documentar la infraestructura a partir de los registros presentes.
Se mantuvo el criterio de no guardar identidades UniFi. El resultado y los casos
pendientes se recogen en [Documentación de infraestructura de Abeto Design](documentacion-infraestructura-abeto-design.md).
Los recuentos del apartado 3 describen el estado previo a esa carga.