Skip to content

TLSStress.Art — Para qué sirve

Lee en tu idioma: English · Português · Español

Estado del alcance (post-congelación de alcance 2026-05-10) — Ver ARCHITECTURE.md para los 37 MÓDULOs canónicos + 7 Test Kinds + arquitectura de safety DOM/CPOS/PIE-PA. ADRs 0014, 0019-0025 cubren adiciones post-Freeze. Web Agent Cluster for NGFW TLS Inspection performance test — un banco de pruebas open-source para medir la capacidad real de inspección TLS de Firewalls de Próxima Generación (NGFWs) bajo carga HTTP/2 y HTTP/3.

Autor: André Luiz Gallon · Licencia: PolyForm Noncommercial 1.0.0 + Appendix A · Audiencia: empleados de Cisco y partners certificados

1. Por qué existe este software

Cuando una empresa necesita probar la capacidad de inspección TLS de un firewall corporativo, el mercado tiene dos extremos:

Categoría Ejemplos Limitación
Herramientas gratuitas TRex, iPerf3, wrk, Locust No generan tráfico TLS realista a escala — paquetes brutos o HTTP simple, sin JavaScript, sin handshake TLS completo, sin HTTP/3
Appliances comerciales Spirent CyberFlood, Ixia BreakingPoint, IXIA IxLoad US$ 50K–500K por chasis; hardware propietario; difíciles de automatizar en CI/CD
TLSStress.Art Este proyecto (open-source, PolyForm Noncommercial) Corre en hardware commodity (Ubuntu + k3s); navegador real (browser engine) + carga sintética (k6); HTTP/2 y HTTP/3 nativos; sin costo de licencia para la audiencia elegible

TLSStress.Art llena ese vacío: ofrece pruebas de inspección TLS con realismo de producción — navegadores reales, JavaScript, cookies, certificados válidos — sin costo de licencia y con automatización total mediante Kubernetes y GitHub Actions.

La pregunta que el producto responde: ¿cuántas conexiones TLS simultáneas soporta el firewall antes de degradar rendimiento — y cuál es el impacto comparado entre HTTP/2 y HTTP/3?

2. Cómo funciona — visión de 30 segundos

┌─────────────────────────┐
│ Robots de carga         │  browser engine (navegador real) + k6 (HTTP)
│ hasta 300 PW + 1000 synthetic-load engine  │  generan tráfico TLS contra las personas
└──────────┬──────────────┘
           │ Leg 1: HTTPS cifrado (los robots confían en el cert del firewall)
           ▼
┌─────────────────────────┐
│ FIREWALL (DUT)          │  Appliance bajo prueba — descifra, inspecciona,
│ — bajo prueba, medido   │  vuelve a cifrar cada paquete
└──────────┬──────────────┘
           │ Leg 2: HTTPS re-cifrado (firewall habla con la persona)
           ▼
┌─────────────────────────┐
│ 30 personas Caddy       │  20 Sintéticas (siempre activas) +
│ 20 Sintéticas + 10      │  10 slots Clonados (operador elige sitios
│ slots Clonados          │  públicos para clonar)
└─────────────────────────┘

         ┌─── Telemetría recolectada en paralelo (4 pilares) ────┐
         ▼                                                       ▼
   SNMP exporter        Promtail/Loki          DUT API REST       OpenTelemetry → Tempo
   (CPU/mem/IF del      (eventos de Nexus,     (config + estado   (distributed tracing
    Nexus + DUT)         NGFW, hosts UCS)       del FTD/Nexus/     opt-in en agentes)
                                                UCS/Fortinet)

Leg 1 — los robots abren conexiones HTTPS contra las direcciones de las personas. El firewall intercepta y presenta su propio certificado (operador configura los agentes para confiar en el ngfw-ca).

Leg 2 — el firewall abre una segunda conexión HTTPS contra la persona destino. El certificado es emitido por cert-manager (CA persona-ca).

4 pilares de telemetría recolectan evidencia simultáneamente — métricas (Prometheus + SNMP), eventos (syslog correlation vía Loki), estado del dispositivo (DUT API REST), y traces (Tempo) — para responder no solo "cuál fue el p99" sino también "qué pasó en el DUT cuando el p99 subió".

3. Las 30 personas

La flota de personas se divide en dos grupos:

20 Sintéticas (siempre activas)

Definidas en personas.yaml, generadas a partir de plantillas Caddy. Cada persona corre en un namespace de Kubernetes dedicado, con certificado TLS, IP fija, VLAN exclusiva (101–120) y entrada DNS dedicada.

Distribuidas en 4 arquetipos:

Arquetipo Ejemplos Cómo se genera el tráfico
skin CDN, blog, portal, news, gov, edu, gallery, stream, download, docs HTML/CSS/JS sintético; assets estáticos de alto throughput
mock api-rest, api-graphql, chat, webhook, telemetry, ads JSON/XML configurable vía YAML; simula microservicios
har-replay har-saas, har-social, har-webmail, har-media Reproduce grabaciones HAR (HTTP Archive) de sesiones reales
real-app shop (Saleor, e-commerce completo) Aplicación real con base de datos, estado, JavaScript dinámico

10 Slots Clonados (llenados por el operador)

VLANs 200–209. El operador elige un sitio público (ej.: globo.com, cnn.com), el Cloner hace crawl + snapshot del contenido estático, y la réplica pasa a servir localmente como una persona "real" con dominio *.persona.internal.

El Cloner usa tres interfaces de red distintas: OOBI (gestión), VLAN 40 (DHCP del ISP del cliente, para descargar contenido público de Internet) y una VLAN macvlan en el cluster (para servir el contenido clonado a las demás personas/agentes).

4. Los 4 pilares de telemetría

El producto no mide solo latencia. Para responder por qué una métrica cambió — un prerrequisito para que una prueba de NGFW sea válida — recolectamos evidencia de cuatro fuentes simultáneamente:

Pilar Fuente Qué captura Endpoint
1. Métricas (SNMP + Caddy + agentes) SNMP exporter, Caddy /metrics, browser-engine/synthetic-load CPU, memoria y contadores de interfaz del switch y firewall; req/s, bytes, conexiones activas, QUIC vs TCP en personas; latencia, throughput, tasa de error, handshake TLS en agentes Prometheus → Grafana
2. Eventos (Syslog correlation) Promtail (NodePort 30514) → Loki Eventos de Nexus 9000, NGFW DUT, hosts UCS. Política OOBI-only (NUNCA en plano de datos). Ingestión validada por dos NetworkPolicy a nivel del cluster Loki → Grafana Explore + dashboard "Syslog Correlation"
3. Estado del DUT (REST API) Polling worker en el pod del Dashboard Para cada DUT registrado: versión, config NTP, política de inspección SSL/TLS, estado HA, vecinos LLDP/CDP, inventario de hardware. Snapshots firmados con SHA-256 (cadena forense) Adapters DUT API REST (FTD, Nexus, UCS, Fortinet) → Postgres dut_api_snapshots
4. Traces (OpenTelemetry → Tempo) SDK opt-in en browser-engine + synthetic-load Distributed tracing por ciclo de prueba, con spans de cada handshake TLS. Cubre el camino end-to-end: agent → NGFW → persona Tempo → Grafana → Dashboard

La combinación de los cuatro permite respuestas como: "latencia p99 subió a las 14:23 → confirmado en syslog: NGFW logueó alta CPU a las 14:22 → confirmado en DUT API: política de decryption fue cambiada por otro operador 4 minutos antes → trace muestra handshake gastando 380ms vs 95ms baseline".

5. DUT API — integración multi-vendor

Adapter pattern con 4 vendors shipped (Palo Alto en el roadmap):

Vendor Adapter Auth Estado
Cisco FTD (FDM-managed) cisco-ftd.ts OAuth2 → Bearer ✅ Shipped
Cisco Nexus 9000 cisco-nexus.ts NX-API cookie (APIC-cookie) ✅ Shipped
Cisco UCS C-Series CIMC cisco-ucs-cimc.ts Basic Auth (Redfish) ✅ Shipped
Fortinet FortiGate fortinet-fortigate.ts API key Bearer (FortiOS REST v2) ✅ Shipped
Palo Alto (PAN-OS) — API key (XML API) 📋 Roadmap

Workflow del operador: 1. UI en /admin/dut-api registra un device (URL, credenciales — encriptadas con AES-256-GCM) 2. Polling worker en el Dashboard recolecta snapshots cada N minutos (configurable; default 5min) 3. Cada snapshot se convierte en una fila en dut_api_snapshots con payload JSON + SHA-256 del canonical form 4. Los snapshots aparecen en dashboards Grafana ("DUT Live State") y (en el roadmap) en los Annexes B/C/D del Test Run Report

Catálogo de 45 features mapeadas por vendor — qué adapter expone NTP config, qué expone HA state, etc. — en docs/API_FEATURE_CATALOG.{md,pt-BR,es}.md.

6. Test Plans + Test Run Reports

Test Plan engine — 15 plans pre-configurados (catálogo en docs/TEST_PLANS.{md,pt-BR,es}.md): - Identificadores estables (string ID, no hash) para comparaciones cross-engagement - Validados por schema Zod, sincronizados a Postgres en el boot - Cada plan declara el estado esperado del NGFW (ej.: ngfw_state_required: decryption-on) - Los planes cubren: baseline H2/H3, max-CPS handshake, sustained throughput, decryption-on vs decryption-off, fallas de cert, mixed protocol, etc.

Test Run Report — Phase 1 shipped (#185): - HTML print-styled (/runs/{id}/report) con portada, página de licencia en 3 idiomas, executive summary, plan config, anexos placeholder - Footer de licencia pinned en todas las páginas - Hashes SHA-256 del report completo + plan-snapshot + per-anexo (cadena forense) - API JSON paralela: /api/test-runs/{id}/report.json

Roadmap de phases pendientes: - Phase 2 — Puppeteer server-side render → PDF real (hoy es HTML print) - Phase 3 — Annexes B/C/D wired (snapshots Nexus/NGFW/UCS embebidos en el report) - Phase 4 — Cosign signing + entrada Rekor/Sigstore (transparency log público) - Phase 5 — N-run comparison (run A vs run B), trend rollups (semanal/mensual), replay snapshot

7. Pre-flight, time-sync, validez del test bed

Pre-flight checks (engine + 5 catálogo) — antes de cada run, valida estado del lab: - ngfw-deploy-clean — sin deploy pendiente en el DUT - ngfw-decrypt-state-matches-plan — estado de decryption alineado con el plan - ntp-source-configured — todos los componentes tienen NTP definido - ngfw-ha-state-sane — par HA en estado consistente - snapshot-fresh — última colecta DUT API < threshold

Time-sync layer — reloj del lab entero sincronizado: - Script scripts/check-time-sync.sh mide skew entre componentes; alertas Prometheus disparan arriba del threshold - Cloner puede actuar como NTP relay (stratum-2) cuando la Internet del data center es restringida - Browser-clock fallback documentado e implementado: admin UI en /admin/time-sync envía el tiempo del laptop del operador vía POST /api/time-sync/set-from-browser (con acknowledgement: NOT_FORENSIC obligatorio), retorna el kubectl chronyc settime para que el operador aplique manualmente. Audit log marca forensic_grade: false automáticamente.

Test-bed validity proof — observabilidad evolution en 4 phases shipped: 1. Deployment-aware thresholds + fleet readiness (PR-1+2, #173) — alertas que conocen qué modo de deploy (single/dual/tri/multi) está activo 2. Topology-aware causal correlation (PR-3, #177) — correlaciona métricas por los nodes/personas/agents que conversan entre sí 3. SLO + multi-window multi-burn-rate alerts + anomaly detection + Tempo (PR-4, #179) 4. Always-visible license banner en Dashboard, Grafana, Prometheus (#178)

8. Compliance, forensic, protección de IP

Brand registrada y tagline oficial: - Nombre: TLSStress.Art (™ — registro en curso) - Tagline: Web Agent Cluster for NGFW TLS Inspection performance test

Licencia: PolyForm Noncommercial 1.0.0 + Appendix A — uso noncommercial únicamente, y Appendix A restringe la audiencia elegible a empleados de Cisco (y sus subsidiarias) y ingenieros pre-/post-venta de partners certificados de Cisco. Detalles en LICENSE y USAGE_POLICY.es.md.

License Acceptance Modal — primer login en el Dashboard intercepta al operador con un modal exigiendo aceptación de la licencia + USAGE_POLICY. La aceptación genera una fila en audit_log (visible en /admin/audit/license-acceptances). Política de privacidad en PRIVACY_POLICY.es.md, audit policy en AUDIT_LOG.md.

Forensic infrastructure (IP_PROTECTION.es.md): - FINGERPRINT_REGISTRY en una rama privada (private/forensic) — fingerprints intencionales en el código que prueban autoría si aparece un clon - Asset hashes manifest firmado en cada release - Tamper-check workflow dispara en PRs y en main, comparando hashes contra el manifest - Roadmap: migrar FINGERPRINT_REGISTRY a un repo separado para evitar fuga vía Access Broker

TLS Decrypt Mode Verification (#180) — probe que cruza el issuer-cert observado en la conexión contra la política de decryption esperada del plan. Garantiza que la medición refleja el modo real de operación del NGFW (sin esperar log del dispositivo).

9. Onboarding del operador

Cinco docs encadenados para que el operador llegue de cero al primer run:

Access Request   →   Clone   →   Install (Runbook)
[ACCESS_REQUEST]     [CLONE_FOR_INSTALL]   [RUNBOOK_FIRST_INSTALL]
                                              │
                                              └── alternativa: [AIRGAP_INSTALL]

Setup del mantenedor (una vez): [PRIVATE_REPO_SETUP]
  • Access Broker (ACCESS_REQUEST.es.md) — issue template + GitHub Action /approve /deny. Auto-list de domains Cisco-controlled (cisco.com, meraki.com, duo.com, webex.com, splunk.com, thousandeyes.com); flujo manual con partner ID para partners certificados.
  • Clone (CLONE_FOR_INSTALL.es.md) — 4 opciones autenticadas de git clone (HTTPS+PAT, SSH key, GitHub CLI, tarball firmado).
  • Runbook First Install (RUNBOOK_FIRST_INSTALL.es.md) — protocolo de 4 pasos: lab→DUT→smoke→measure. Tiempo presupuestado: ~2h.
  • Air-gapped install (AIRGAP_INSTALL.es.md) — alternativa para data center sin Internet (regulado / clasificado).
  • Private repo setup (PRIVATE_REPO_SETUP.es.md) — setup del mantenedor (una vez, por el dueño del repo).

10. Tuning aplicado en todas las capas

Para que los resultados reflejen el límite real del firewall — y no las limitaciones del test bed — cada componente de la plataforma fue ajustado con parámetros específicos. Scripts automatizados aplican el tuning de forma reproducible.

Componente Parámetros Impacto
Host Linux Ubuntu (DaemonSet node-tuning) rmem_max/wmem_max = 64 MB; TCP BBR + FQ; tcp_max_syn_backlog=65535; vm.swappiness=5; CPU governor performance; THP madvise; nf_conntrack_max=2M; tcp_orphan_retries=2 Crítico para QUIC/HTTP3: buffers UDP grandes evitan descarte; BBR mejora throughput en redes con variación de RTT
Webserver Caddy (por pod de persona) GOMAXPROCS vía resourceFieldRef; GOMEMLIMIT=460MiB; GOGC=200; QoS Guaranteed (CPU 2/2, Mem 512Mi/512Mi) Go usa todos los cores disponibles sin over-commit; GC menos frecuente reduce latencia de cola
Switch Nexus 9000 (script automatizado) EEE off, flow control off, MTU 9216 (jumbo frames), QoS DSCP AF41, ECMP hash con puerto UDP, ARP timeout 300s Jumbo frames aumentan throughput; EEE desactivado elimina latencia adicional; ECMP con puerto UDP distribuye QUIC correctamente
Agentes browser-engine + synthetic-load NODE_EXTRA_CA_CERTS / SSL_CERT_FILE apuntando a persona-ca; GOMAXPROCS/GOMEMLIMIT en k6; resources right-sized; topology spread; CYCLE_CONCURRENCY=3 Confianza en los certs sin advertencias; UDP 443 abierto; máxima ocupación de cores sin conflicto

Guías detalladas: docs/PERFORMANCE_TUNING_HOST.md, docs/NEXUS9K_TUNING.md, más los artefactos k8s/85-node-tuning.yaml + scripts/nexus/0[1-3]-*.nxos.

El setup completo está diseñado para ser de bajo esfuerzo: ./scripts/k8s-dut-up.sh up levanta toda la plataforma en fases automáticas.

11. Arquitectura de red

Servidor Ubuntu (k3s)
├── eth0       →  red OOBI  (mgmt, métricas, dashboard, control, Service VIPs)
└── eth1       →  trunk Nexus 9000  (VLANs de datos)
               ├── VLAN 20  (172.16.0.0/16)   →  Agentes browser-engine  (dut-pw)
               ├── VLAN 30  (172.17.0.0/16)   →  Agentes k6          (dut-k6)
               ├── VLAN 40  (DHCP del ISP)    →  Cloner ISP egress   (salida a Internet, fuera del esquema)
               ├── VLAN 99  (192.168.90.0/24) →  OOBI mgmt           (dut-mgmt, SNMP, syslog, NTP)
               │
               │   20 VLANs Sintéticas (101–120) — una por persona Caddy:
               ├── VLAN 101–120  (10.1.x.0/27)  →  shop, news, blog, docs, gallery, stream, download,
               │                                   edu, gov, cdn, api-rest, api-graphql, chat, webhook,
               │                                   telemetry, ads, har-saas, har-social, har-webmail, har-media
               │
               │   10 VLANs Clonadas (200–209) — slots dinámicos llenados por el Cloner:
               └── VLAN 200–209  (10.2.x.0/27)  →  cloned-1 .. cloned-10
                               │
                        FIREWALL (DUT) ←── inspecciona TLS en todas las VLANs
                               │
                        4 pilares de telemetría recolectan evidencia en paralelo
                        (SNMP + Syslog + DUT API + Tempo)

¿Por qué separación rigurosa OOBI ↔ plano de datos? - El plano de datos (VLANs 20, 30, 40, 101–120, 200–209) carga tráfico de prueba. Cualquier mgmt traffic aquí contamina las métricas por ciclo. - La OOBI (VLAN 99 / 192.168.90.0/24) es exclusiva para mgmt — Prometheus scrape, SNMP, syslog, NTP, kubectl, dashboard. Política syslog-oobi-only + syslog-deny-data-plane enforced a nivel del cluster por dos NetworkPolicy complementarias. - Service VIPs en OOBI (.50–.69) — Promtail :514, NTP relay :123, Dashboard :3000, Prometheus :9090, Grafana :3001, Loki :3100, SNMP-Exporter, Alertmanager, Tempo. Devices DUT apuntan a IPs fijas, no a NodePort en UCS específico.

12. 4 modos de despliegue

Modo Cuándo usarlo Guía
Single-node (1 UCS) Evaluación inicial; hardware limitado UBUNTU_K3S_SINGLENODE
Dual-node (2 UCS) UCS-1 = agentes; UCS-2 = personas + servicios + observabilidad UBUNTU_K3S_DUALNODE
Tri-node (3 UCS) UCS-1 = solo browser engine; UCS-2 = solo k6; UCS-3 = personas + servicios + obs UBUNTU_K3S_TRINODE
Multi-nodo (4 UCS dedicados) UCS-1 = 30 personas · UCS-2 = browser engine · UCS-3 = k6 · UCS-4 = Dashboard/Postgres/Grafana/Cloner. Throughput máximo, sin contención UBUNTU_K3S_MULTINODE

Los modos dual/tri/multi usan overlays Kustomize en overlays/{dual-node,tri-node,multi-node}/ que aplican nodeSelector a cada Deployment/StatefulSet. Permiten escalar browser engine hasta 300 instancias y k6 hasta 1.000 instancias sin compartir CPU/memoria con los webservers de las personas.

13. Dashboard de operación

Cockpit web (Next.js) en /. Páginas principales:

  • Visión general — estado de las 30 personas en tiempo real (ejecutando, pausada, error)
  • Personas individuales — iniciar/pausar/desaprovisionar; configurar rutas de respuesta de las personas mock (YAML inline vía API)
  • /admin/dut-api — registrar DUT devices, probar conectividad, disparar snapshot, ejecutar pre-flight
  • /admin/time-sync — admin UI para el flujo browser-clock fallback (con aceptación NOT_FORENSIC obligatoria)
  • /admin/audit/license-acceptances — viewer de las aceptaciones de licencia (audit forense)
  • Test Plans — elegir un plan, disparar un run, monitorear progreso
  • Test Runs — historial, link al HTML report (Phase 1)
  • Métricas Grafana — embedded por persona y por protocolo (HTTP/2 vs HTTP/3 vs HTTP/3-fallback-TCP)

Resumen en una frase

TLSStress.Art es un banco de pruebas open-source (PolyForm Noncommercial, audiencia Cisco) que llena el vacío entre herramientas gratuitas sin escala (TRex, iPerf) y appliances comerciales de hasta US$ 500K (Spirent, Ixia) — simulando hasta 30 sitios realistas (20 Sintéticas + 10 slots Clonados por el operador) con browser-engine/synthetic-load contra el NGFW bajo prueba, integrando 4 pilares de telemetría (SNMP del hardware + syslog correlation + DUT API REST multi-vendor para FTD/Nexus/UCS/Fortinet + OpenTelemetry tracing), con 15 test plans pre-configurados, Test Run Reports HTML/PDF firmados forensicamente, License Acceptance Modal + audit log + tamper-check, y todo optimizado desde el host Linux hasta el switch Nexus para que el cuello de botella medido sea siempre el NGFW — nunca el test bed.