Skip to content

Modos de Teste com NAT

Leia no seu idioma: English · Português · Español

Status do escopo (pós-congelamento de escopo 2026-05-10) — Ver ARCHITECTURE.md para os 37 MÓDULOs canônicos + 7 Test Kinds + arquitetura de safety DOM/CPOS/PIE-PA. ADRs 0014, 0019-0025 cobrem adições pós-Freeze.

Status: Fundação em v4.3 — ADR 0007 §16 (matriz) + §22 (orquestrador) + §26 (Anexo H + I).

Por que testar ambos os modos

A capacidade de NGFW em produção é determinada por dois custos de CPU largamente independentes: descriptografia TLS e tradução NAT. Clientes frequentemente atribuem limites de throughput ao decrypt quando o gargalo real é o NAT, ou vice-versa. Um teste que roda só a configuração de produção não consegue decompor esses dois custos.

Este test-bed exercita o NGFW em dois modos NAT:

  • nat_mode: pat — source-PAT (NAT Overload). NGFW mantém uma tabela de tradução e reescreve IP/porta source pra cada flow. Realista pra produção; pesado em CPU e memória.
  • nat_mode: disabled — encaminhamento puramente roteado. NGFW só inspeciona e encaminha; sem tradução, sem tabela xlate. Throughput máximo teórico do device sob carga de decrypt.

Cada test plan declara qual modo precisa. O DUT API (dashboard/src/lib/dut-api/) aplica a config vendor-specific correspondente antes do run começar e reverte ao final.

O que muda dentro do NGFW

Aspecto nat_mode: pat nat_mode: disabled
Escritas na tabela de tradução Sim — cada novo flow consome uma entrada xlate Nenhuma
Reescritas source/dest Reescrita IP + porta source por pacote Pass-through
Inflação do conntrack Alta — cada flow NAT'd pega uma entrada conntrack Baixa — só state de inspeção
Perfil de CPU (típico) NAT engine 15–25%, crypto 40–55%, inspeção 15–20% NAT engine 0%, crypto 50–60%, inspeção 25–30%
Penalidade de throughput 15–30% vs baseline nat_mode: disabled Baseline de referência
Modo de falha Esgotamento de pool sob estresse (resultados invalidados) Limite de conexão / backlog de inspeção

Quando escolher cada modo

Cenário Modo recomendado
Cliente comissionando NGFW novo pra capacity planning Ambos — rode o plan MATRIX (CAP-FIND-KNEE-MATRIX-2H) pra decomposição completa por quadrante
Sanity check rápido (config válida, decrypt funcionando) nat_mode: disabled (Q1 baseline) — mais rápido, menos variáveis
Teste full mirror de produção nat_mode: pat (Q4)
Isolar custo do NAT engine vs crypto engine nat_mode: disabled + decrypt: on (Q2) E nat_mode: pat + decrypt: off (Q3); comparar deltas
Testar decisão de NAT pool sizing nat_mode: pat com pool reduzido — verifica se exhaustion dispara alertas esperados

A matriz 2×2 de quadrantes

O plan MATRIX (CAP-FIND-KNEE-MATRIX-2H) orquestra quatro sub-runs de 30 minutos sequencialmente:

                         SEM NAT                  COM NAT
                  ┌───────────────────────┬───────────────────────┐
   SEM            │ Q1 Baseline           │ Q3 NAT-only           │
   DECRYPT        │ forward puro          │ isola custo NAT       │
                  ├───────────────────────┼───────────────────────┤
   COM            │ Q2 Decrypt-only       │ Q4 Produção           │
   DECRYPT        │ isola custo crypto    │ NAT + decrypt         │
                  └───────────────────────┴───────────────────────┘

O resultado é um único Test Run Report contendo Anexo I — Decomposição da Capacidade por Quadrante com aritmética de delta (NAT sozinho, decrypt sozinho, combinado, bonus de sinergia) e guidance de otimização customer-facing.

Veja dashboard/templates/annex-i-quadrant-decomposition.md.tmpl pro layout completo do anexo.

Tuning vendor-específico (per nat_pool_overload: tuned)

Quando um plan declara nat_pool_overload: tuned, o DUT API aplica esses tunings por vendor antes do run começar. Templates ficam em dashboard/src/lib/dut-api/<vendor>/templates/nat_pat.tmpl.

Cisco FTD (cdFMC / FMC)

Setting Valor tunado Por quê
xlate-timeout 180s (vs default 3600s) Devolve entradas de tradução pro pool mais rápido em runs de stress
tcp-halfclose-timer 15s (vs default 60s) Libera flows pendentes de TCP-RST/FIN rapidamente
nat-protocol-table-size máximo per-platform (e.g., 4M no FTD 4115) Maximiza capacidade do pool
nat-rule-prioritization habilitado Evita fragmentação do pool sob churn pesado

Fortinet FortiGate

Setting Valor tunado Por quê
tcp-timewait-timer 30 Libera sockets TIME_WAIT rapidamente
tcp-halfclose-timer 15 Libera closes TCP pendentes rapidamente
port-block-allocation enable Reduz pool exhaustion em CPS alto
central-snat-policy uma regra wide-net (vs muitas específicas) Reduz overhead de lookup

Palo Alto Networks (PAN-OS)

Setting Valor tunado Por quê
dynamic-ip-and-port translation timeout 180s Reciclagem agressiva
tcp half-closed timeout 15s Igual ao FTD
oversubscription habilitado com rate 4 Permite 4× mais traduções NAT concorrentes por IP público

Os valores efetivos usados em qualquer run específico são gravados no Anexo H — Performance do NAT Engine, sub-seção H.1 (vendor_template_id + vendor_template_sha256), pra que reviewers possam verificar que o tuning foi aplicado conforme documentado.

Lendo os alertas (anchors de runbook)

Os alertas Prometheus em k8s/dut/96-nat-engine-rules.yaml carregam annotations runbook_url apontando pra esse documento. Cada anchor abaixo é o runbook pro alerta correspondente.

Pool utilization warning

Disparado por NATPoolUtilizationHigh quando pool > 80% sustentado por 30s.

O que significa: NAT pool aproximando exhaustion sob carga atual.

Resposta do operador: 1. Cheque o dashboard NAT engine (Grafana → dut-nat-engine) pra trajetória — utilização subindo ou estável? 2. Se subindo e run é long-running (soak / 8h): considere parar o run e re-rodar com fleet menor. 3. Se estável em 80–90% durante todo o teste: capacity claim é válido mas o cliente deve saber que esse modelo NGFW esgotaria com carga ligeiramente maior.

Opção de tuning: baixar xlate-timeout pra 60s (Cisco FTD) ou tcp-timewait-timer pra 15s (Fortinet) — recicla entradas do pool mais rápido.

Pool exhaustion

Disparado por NATPoolExhaustion quando qualquer evento de exhaustion ocorre no último 1m.

O que significa: NGFW silenciosamente droppou pelo menos uma requisição de tradução porque o pool estava cheio. Resultados do teste invalidados — o test bed está medindo falha, não capacidade.

Resposta do operador: 1. Pare o run imediatamente se ainda ativo. 2. Anexo H do report vai marcar esse run como invalidado com a contagem de eventos de exhaustion. 3. Aumente o NAT pool size no DUT API NAT template (vendor-specific). 4. Re-rode com configuração corrigida.

Guidance de root cause: com 1000 synthetic-load agents × ~10 conexões/sec × 30 min = ~18M flows; se seu pool é < 4M entradas com xlate-timeout: 3600s, exhaustion é matematicamente inevitável. O template nat_pool_overload: tuned endereça isso — verifique que foi aplicado (Anexo H §H.1).

Translation timeout spike

Disparado por NATTranslationTimeoutSpike quando rate de timeout de tradução > 100/sec sustentado por 1m.

O que significa: Muitos flows estão sendo aged out pelo xlate-timeout em vez de fechados naturalmente (RST/FIN). Indica flows curtos segurando entradas xlate além da vida natural deles.

Resposta do operador: 1. Não invalida o run; severidade informativa. 2. Tune NAT template pro próximo run: - Cisco FTD: baixar xlate-timeout pra 60s (combina com pattern de burst do synthetic-load engine) - Fortinet: baixar tcp-halfclose-timer pra 15s (libera closes pendentes mais rápido) 3. Re-rode; espere CPS mensurável maior sem retunar agents.

Como interpretar Anexo H + I no report

Anexo H — Performance do NAT Engine (renderizado pra runs nat_mode: pat)

  • §H.1 Configuração aplicada — o template NAT + valores de tuning usados. Verifique que combina com o que você intencionou (e o que o NGFW de produção do cliente usa).
  • §H.2 Métricas runtime — pool peak utilization é o número headline. Algo acima de 80% é flag amarelo; eventos de exhaustion > 0 é flag vermelho.
  • §H.3 Correlação de capacidade — breakdown de CPU revela onde o engine está limitado. Slice de NAT >25% significa que NAT é gargalo significativo; <10% significa que NAT é essencialmente grátis pra esse NGFW.

Anexo I — Decomposição da Capacidade por Quadrante (renderizado pra runs type: matrix)

  • §I.2 Tabela de decomposição — os quatro números (NAT sozinho, decrypt sozinho, combinado, sinergia) são a resposta principal pro cliente. Sinergia próxima de zero significa NAT e decrypt são caminhos de CPU ortogonais.
  • §I.3 Pra onde vai a CPU — breakdown de CPU por quadrante. Esse é o slide que o arquiteto de rede do cliente vai screenshotar.
  • §I.4 Customer guidance — caminhos de otimização ranqueados. Use isso verbatim no briefing customer-facing.

Referência de plans

Plan identifier Modo Duração Caso de uso
CAP-FIND-KNEE-30M-Q1 nat: disabled, decrypt: off 30 min Baseline; primeiro run de qualquer engagement
CAP-FIND-KNEE-30M-Q2 nat: disabled, decrypt: on 30 min Custo de decrypt em isolamento
CAP-FIND-KNEE-30M-Q3 nat: pat, decrypt: off 30 min Custo de NAT em isolamento
CAP-FIND-KNEE-30M-Q4 nat: pat, decrypt: on 30 min Cenário de produção
CAP-FIND-KNEE-MATRIX-2H Os quatro sequencialmente 2 horas Decomposição completa por quadrante

Veja platform/test-plans/catalog.yaml pras definições canônicas.

Relacionados