Colector Vantage

1Panorama general

El Colector Vantage es un equipo autocontenido que recibe telemetría de flujos desde sensores distribuidos, la convierte en un mapa vivo de dependencias de la red y transforma ese mapa en política de segmentación. Es el flujo de trabajo de observación pasiva de un producto de mapeo de dependencias de aplicaciones (ADM), corriendo sobre hardware que usted ya tiene.

1.1Sobre esta guía

Acá se describe cómo desplegar, configurar, verificar y operar un nodo Colector. Los comandos están escritos para un servidor Linux con Docker Compose. En todo el documento valen estas convenciones:

• El texto monoespaciado, por ejemplo ADM_INGEST_PORT, corresponde a una variable, un archivo, un puerto o un comando literal.
• El $ al comienzo de una línea marca el prompt del shell. Las líneas sin ese prefijo son la salida del comando.
• Los recuadros de Nota, Cuidado y Advertencia contienen información que afecta el resultado o la seguridad.

1.2Qué es y qué no es

El Colector es un producto aparte, no un cliente del portal central de administración (Switchboard). Mantiene su propio login, su propio registro de usuarios, su propio secreto de sesión y su propia base de datos. Lo único que viaja entre ambos es una consulta periódica de máquina a máquina, la sincronización de identidades, que baja al Colector las identidades de los sensores y el paquete de confianza de la flota. El Colector nunca firma certificados y nunca abre una sesión contra el portal.

1.3Capacidades de un vistazo

2Arquitectura

2.1Componentes

Un despliegue se compone del nodo Colector, uno o más sensores, y el portal central Switchboard, dueño de la autoridad certificadora. El Colector corre un solo contenedor que expone dos puertos de escucha: uno para los administradores (login y tablero) y otro para sensores (ingesta mTLS).

Dos tipos de sensor alimentan al Colector. El sensor Vantage es la fuente principal de telemetría. El nodo Vantage Deep es un acompañante opcional para rescatar paquetes. El equipamiento de red que ya está instalado también puede exportar flujos directamente, sin instalar ningún sensor.

Un sensor Vantage le dice que una dependencia existe. Un nodo Vantage Deep guarda los paquetes, así que responde la pregunta que un mapa de flujos por sí solo no puede: muéstreme qué cruzó realmente por el cable.

          # plano de control y CA (servidor aparte)
          Switchboard :8443  ──────────────┐  sincronizacion de identidades
                                           │  (consulta, cron, cada 5 min)
                                           │  { ca_bundle_pem, probes, probe_certs }
                                           ▼
  Sensores ──mTLS :8843──►  ┌───────────────────────────────────────────┐
  (sensor Vantage,          │        Colector Vantage                   │
   nodo Vantage Deep,       │  :443   login y tablero (administradores) │
   equipos IPFIX/NetFlow)   │  :8843  ingesta mTLS de flujos            │
  Operador ──HTTPS :443──►  │  SQLite (WAL)  data/adm/adm.db            │
                            └───────────────────────────────────────────┘

2.2Camino de los datos

Los flujos en bruto nunca se guardan. En la ingesta, cada lote se pliega en aristas de dependencia, una fila por cada tupla ordenada (origen, destino, puerto, protocolo), y los flujos individuales se descartan. Eso reduce el volumen en unos cuatro órdenes de magnitud y responde derechamente lo que preguntan los operadores: qué habla con qué, por qué puerto, desde cuándo. El detalle a nivel de paquete se sirve por separado, desde el anillo de captura de un nodo Vantage Deep.

2.3Modelo de confianza

Dos puertos de escucha, dos modelos de autenticación:

3Requisitos previos

3.1El servidor

• Un servidor Linux con Docker Engine y el complemento Compose.
• Dimensionamiento chico (hasta unos 8 sensores): 4 vCPU y 8 GB de RAM. El contenedor queda topado en 6 GB.
• Disco dimensionado para el histórico de aristas en data/adm/adm.db (WAL). Por omisión se conservan 30 días de baldes horarios.
• Salida hacia Switchboard para la sincronización de identidades, y entrada desde los sensores en el puerto de ingesta.

3.2Puertos y protocolos

3.3Certificados y paquete de confianza

El Colector necesita un par de certificado y llave de servidor para ambas escuchas, montado en solo lectura, y el paquete de CA de la flota para validar los certificados de cliente de los sensores. Ese paquete lo deja la sincronización de identidades en data/fleet-ca-bundle.pem y se referencia con la variable ADM_CA_BUNDLE_FILE.

4Puesta en marcha

4.1Procedimiento

1. Dejar los certificados y la configuración

   Deje el certificado y la llave de servidor bajo certs/ e ingest-certs/. Cree sync_config.json con la URL de Switchboard y el token de sincronización.

   # sync_config.json (solo root: mantiene el token fuera de docker inspect)
   {"switchboard_url": "https://switchboard.ejemplo.net:8443", "token": "<token-de-sincronizacion>"}

2. Construir y levantar el contenedor

   $ docker compose build
   $ docker compose up -d

3. Programar la sincronización en el servidor

   Corra el script de sincronización desde el cron del servidor, no dentro del contenedor, para que escriba en el directorio data/ que está montado.

   # /etc/cron.d: cada 5 minutos
   */5 * * * * cd /opt/vantage-collector && /usr/bin/python3 sync_identity.py >> /var/log/vantage-sync.log 2>&1

4. Crear el primer administrador

   $ docker compose exec collector python -m backend.auth add admin '<contraseña>' admin

4.2Qué pasa en el primer arranque

En el primer arranque el contenedor genera un secreto de firma de sesión propio del despliegue y lo guarda en collector_secret.key, con permisos 0600. Ese valor es único del nodo y nunca se comparte con Switchboard, así que una cookie de sesión de uno jamás es válida en el otro.

5Referencia de configuración

5.1Variables de entorno

Toda la configuración de ejecución se entrega por variables de entorno en el archivo de Compose. Los valores por omisión están pensados para un despliegue chico de un solo nodo.

5.2Cuentas de usuario

Los usuarios se guardan localmente, con la contraseña cifrada con bcrypt. Hay dos roles: admin, con acceso completo, y operator. Las cuentas se administran desde el tablero, o por línea de comandos:

$ python -m backend.auth add <usuario> <contraseña> [admin|operator]

5.3Configuración del sensor

Un solo esquema es la fuente de verdad de todo lo que se le puede configurar a un sensor. El formulario del tablero, el instalador y el agente leen ese mismo esquema. La configuración se aplica desde la página del sensor en el tablero, o por API:

PATCH /api/adm/probes/<probe-id>/config      # se valida antes de guardar
POST  /api/adm/probes/<probe-id>/validate    # en seco: errores, avisos, dimensionamiento

La validación corre primero, así que el tablero no puede guardar una configuración que el agente después se negaría a ejecutar. Use la llamada validate para ver los errores, los avisos y la estimación de dimensionamiento antes de comprometer el cambio.

5.3.1 Modos de captura

Es la forma en que el tráfico espejado llega físicamente al sensor. Elija el modo que soporte su switch:

5.3.2 Regla de reparto de interfaces

En un sensor Vantage sobre Raspberry Pi los roles vienen fijos: la captura va en la interfaz 1 GbE integrada (eth0 o end0, por el camino nativo del RP1) y la gestión en la interfaz USB (enx<MAC> o eth1). La interfaz de captura corre en promiscuo, no lleva dirección y tiene los offloads apagados. Capturar por la interfaz USB queda rechazado salvo que se defina interfaces_override, que es la salida de emergencia para una placa cuya segunda interfaz integrada simplemente se llama parecido a una USB.

5.3.3 Variables principales

5.3.4 El espejo del lado del switch (SPAN)

Un sensor Vantage es pasivo: el switch tiene que espejarle el tráfico. Conecte el puerto destino del SPAN a la interfaz de captura integrada del sensor.

Cisco IOS / IOS-XE (Catalyst)

monitor session 1 source interface GigabitEthernet1/0/1 - 24 both
monitor session 1 destination interface GigabitEthernet1/0/48

Cisco NX-OS (Nexus)

monitor session 1
  source interface Ethernet1/1-24 both
  destination interface Ethernet1/48
  no shut

Arista EOS

monitor session VANTAGE source Ethernet1 - 24
monitor session VANTAGE destination Ethernet48

5.3.5 Vantage Deep (pcap-node)

Un nodo Vantage Deep se configura pensando en retención, no en el reparto del espejo. Las variables que importan son pcapnode_capture_nic, pcapnode_backend (dumpcap es el motor implementado), pcapnode_retention_hours, que por omisión son 6, y pcapnode_link_gbps. No tiene ningún canal de entrada desde el Colector: consulta si hay trabajos de captura cuando manda su latido, y sube de vuelta el pcap que extrajo.

5.4Configuración de exportadores IPFIX y NetFlow

El equipamiento de red que ya exporta registros de flujo puede alimentar el mapa sin instalar ningún sensor. Habilite el colector con ADM_IPFIX=1 (revise el capítulo 9 por las implicancias de seguridad) y apunte los exportadores al UDP 4739. Los flujos quedan atribuidos a ipfix:<ip-del-exportador>, de modo que su procedencia se distingue de la de un sensor de confianza.

Cisco IOS-XE, Flexible NetFlow (Catalyst)

flow record VANTAGE-REC
 match ipv4 source address
 match ipv4 destination address
 match transport source-port
 match transport destination-port
 match ipv4 protocol
 collect counter bytes long
 collect counter packets long
 collect timestamp sys-uptime first
 collect timestamp sys-uptime last
!
flow exporter VANTAGE-EXP
 destination <ip-del-colector>
 source Loopback0
 transport udp 4739
 export-protocol ipfix            ! o netflow-v9
 template data timeout 60
!
flow monitor VANTAGE-MON
 exporter VANTAGE-EXP
 record VANTAGE-REC
 cache timeout active 60
!
interface GigabitEthernet1/0/1
 ip flow monitor VANTAGE-MON input
 ip flow monitor VANTAGE-MON output

Cisco NX-OS (Nexus)

feature netflow
!
flow record VANTAGE-REC
  match ipv4 source address
  match ipv4 destination address
  match transport source-port
  match transport destination-port
  match ip protocol
  collect counter bytes
  collect counter packets
  collect timestamp sys-uptime first
  collect timestamp sys-uptime last
!
flow exporter VANTAGE-EXP
  destination <ip-del-colector> use-vrf management
  source mgmt0
  transport udp 4739
  version 9
!
flow monitor VANTAGE-MON
  record VANTAGE-REC
  exporter VANTAGE-EXP
!
interface Ethernet1/1
  ip flow monitor VANTAGE-MON input

Arista EOS, seguimiento de flujos por hardware (IPFIX)

flow tracking hardware
   tracker VANTAGE
      exporter VANTAGE-EXP
         collector <ip-del-colector> port 4739
         local interface Management1
         template interval 60000
      record export on inactive timeout 15000
      record export on interval 60000
   no shutdown
!
interface Ethernet1
   flow tracker hardware VANTAGE

Fortinet FortiGate (FortiOS, NetFlow v9)

config system netflow
    set collector-ip <ip-del-colector>
    set collector-port 4739
    set source-ip <ip-de-gestion>
    set active-flow-timeout 60
    set inactive-flow-timeout 15
end
config system interface
    edit "port1"
        set netflow-sampler both
    next
end

HPE Comware, NetStream (FlexNetwork, serie 5900)

ip netstream export version 9
ip netstream export host <ip-del-colector> 4739
ip netstream export source interface M-GigabitEthernet0/0/0
!
interface Ten-GigabitEthernet1/0/1
 ip netstream inbound
 ip netstream outbound

HPE y Aruba, plataformas basadas en sFlow

6Verificación

6.1Chequeo de salud

El Colector expone un endpoint de vida sin autenticación. Devuelve HTTP 200 cuando la ingesta está escuchando, o cuando está deshabilitada a propósito, y HTTP 503 cuando la escucha mTLS está habilitada pero no logró partir, que es exactamente la condición que produce un paquete de CA faltante.

$ curl -sk https://localhost:443/healthz
{"ok":true,"ingest":{"enabled":true,"listening":true,"port":8843,
 "client_certs_required":true}}

El servicio de Compose conecta ese endpoint al chequeo de salud del contenedor, así que el runtime reporta el contenedor como unhealthy cada vez que los sensores no pueden entregar flujos:

$ docker inspect --format '{{.State.Health.Status}}' vantage-collector
healthy

6.2Ingesta de sensores

Confirme en el log del contenedor que la escucha partió y que exige certificados de cliente:

$ docker compose logs collector | grep mTLS
[adm_ingest_mtls] INFO ingest mTLS listening on :8843 (client certificates required)

6.3Sincronización de identidades

Una corrida exitosa informa lo que bajó y el tamaño del paquete:

$ tail -n1 /var/log/vantage-sync.log
identity-sync ok: 12 probes, 12 certs, bundle 3805 bytes

7Administración

7.1Respaldo y exportación

Un respaldo captura exactamente lo que este nodo posee: su adm.db, su registro de usuarios y el paquete de confianza que bajó por sincronización. Deja fuera, a propósito, el secreto de sesión y todo el material de llaves privadas: un respaldo robado no sirve para falsificar una sesión ni un certificado. Los respaldos se descargan, o se empujan a un servidor remoto por SCP o TFTP desde la página de respaldo.

7.2Ciclo de vida de un sensor

Los sensores se registran, se enrolan y rotan sus certificados en Switchboard, que es donde está la CA. Las identidades resultantes y el estado de revocación llegan al Colector por la sincronización de identidades. Para dar de baja un sensor, revóquelo en Switchboard: el Colector deja de aceptar su certificado después de la siguiente sincronización.

7.3Dar de alta un sensor sin Switchboard

El enrolamiento y la firma se hacen normalmente en Switchboard (capítulo 1.2). Un Colector desplegado por su cuenta no tiene la CA de Switchboard, pero igual puede dar de alta sensores Vantage de dos maneras, las dos desde la página Onboarding del tablero, o por API. En ambas, la llave privada del sensor nunca sale del sensor: lo único que viaja es un CSR que se firma, o un certificado ya firmado que se registra.

Opción A: la CA del propio Colector (recomendada)

El Colector actúa como su propia CA y firma los CSR de los sensores directamente, sin ninguna CA externa que operar.

1. Inicializar la CA, una sola vez

   Queda creada y aceptada en la ingesta de forma automática.

   POST /api/ca/init

2. Crear el sensor

   En Sensores. Con ADM_STANDALONE=1, que es lo que trae el equipo, los campos que solo aplican a Switchboard no son obligatorios.

3. Generar el CSR en el sensor

   openssl req -newkey rsa:2048 -nodes -keyout sensor.key \
     -out sensor.csr -subj "/CN=<probe-id>"

4. Firmar y registrar el CSR

   POST /api/sensors/<probe-id>/issue    {"csr_pem": "<PEM del CSR>"}

   Devuelve el certificado firmado. El sensor presenta sensor.key junto con ese certificado y queda aceptado en la ingesta mTLS.

Opción B: usted aporta la CA

Si ya opera una CA, firme el CSR con ella fuera de línea y registre el resultado.

1. Instalar el paquete de confianza de la CA

   POST /api/ca-bundle    {"bundle_pem": "<PEM del certificado de su CA>"}

2. Crear el sensor y registrar el certificado firmado

   Firme el CSR del sensor con su CA fuera de línea, y después:

   POST /api/sensors/<probe-id>/cert    {"cert_pem": "<PEM del certificado firmado>"}

En las dos opciones el número de serie del certificado se normaliza exactamente como lo lee la ingesta, así que ni las mayúsculas ni los ceros a la izquierda pueden provocar un rechazo equivocado.

Rotación y revocación

Los certificados de un sensor se administran desde el panel Onboarding → Manage sensor certificates, o por API:

GET  /api/sensors/<probe-id>/certs                  # lista series, vencimiento y estado
POST /api/sensors/<probe-id>/certs/<serial>/revoke   # revoca un certificado
POST /api/sensors/<probe-id>/revoke                 # revoca el sensor completo
POST /api/sensors/<probe-id>/reactivate             # devuelve al servicio un sensor revocado

Para rotar: emita un certificado nuevo, por la opción A o la B, confirme que el sensor lo está usando y recién entonces revoque la serie antigua. Mientras tanto el viejo y el nuevo son válidos a la vez, así que no hay ventana de corte. Para dar de baja: revoque el sensor completo. Para devolverlo al servicio: reactívelo y emita un certificado nuevo. La reactivación pasa el sensor de revoked a enrolled, pero deja los certificados antiguos revocados a propósito, de modo que un sensor retirado no pueda volver con una credencial vieja. Una serie revocada se rechaza en el siguiente saludo mTLS, y un sensor dado de baja se rechaza por completo. Todo esto opera únicamente sobre los registros de sensores del propio Colector.

8Diagnóstico

9Consideraciones de seguridad

• Integridad de la sesión. Las cookies se firman con un secreto propio del nodo, generado en el primer arranque. El archivo de llave queda en modo 0600 y se excluye de los respaldos.
• Autenticidad del sensor. La ingesta de flujos exige un certificado de cliente firmado por la CA de la flota. Es el certificado, y no el cuerpo de la petición, lo que establece la identidad del sensor. Un cuerpo que declare ser otro sensor se rechaza.
• Canal de sincronización. La sincronización verifica el certificado TLS de Switchboard contra el paquete de CA que ya bajó. Solo la primerísima sincronización de un nodo recién instalado, cuando todavía no existe ningún paquete, corre sin verificar: deja una advertencia en el log y queda superada en la corrida siguiente.
• Procedencia de IPFIX. IPFIX y NetFlow sobre UDP no llevan autenticación. Cuando se habilitan, cada arista que producen queda etiquetada como ipfix:<ip-del-exportador>, para que lo que dijo un exportador nunca se confunda con lo que observó un sensor de confianza.

10Límites y advertencias

• Medición pasiva, nada más. Una sonda de flujos observa volumen y extremos. No puede medir latencia, pérdida de paquetes ni jitter, y el mapa reporta únicamente valores que una sonda observó de verdad. Los chequeos sintéticos son la única capacidad activa y se habilitan a pedido.
• El Colector no tiene autoridad certificadora. El nodo valida certificados, pero nunca los firma. El enrolamiento, la rotación y la revocación son funciones de Switchboard, y esos endpoints no se sirven acá de manera deliberada.
• La revocación tiene latencia. El estado de revocación se propaga a la velocidad de la sincronización de identidades, que por omisión son cinco minutos.
• La captura profunda es un rol distinto. Rescatar paquetes exige un nodo Vantage Deep. Un sensor Vantage deja constancia de que una dependencia existe, no de los paquetes que cruzaron el cable.
• Un solo nodo. Esta guía cubre un equipo autónomo. Los roles de alta disponibilidad degradan de manera ordenada a un nodo único siempre activo.