# Construtor de debug flow do FortiOS

> Monta a sequência ordenada de `diagnose debug flow` que um FortiGate precisa para rastrear uma sessão: o reset para estado limpo, o filtro, as opções de exibição, o trace por contagem de pacotes e o enable, junto dos comandos de limpeza que importam mais que a preparação. Local e offline; gera texto e não contata nada.

- Tool: https://ronutz.com/pt-BR/tools/fortios-flow-debug-builder
- Family: Segurança e WAF

---

## O que faz

Preencha o que você quer rastrear — um endereço, opcionalmente portas, um protocolo, uma contagem de pacotes — e a ferramenta monta a sequência completa de `diagnose debug flow` para um FortiGate: o reset para estado limpo, o filtro, as opções de exibição, o trace e o enable, seguidos da limpeza. Cada linha é explicada individualmente. Gera texto e não contata nada.

## Por que um construtor, e não uma referência

`diagnose debug flow` não é um comando, é uma receita de quatro ou cinco comandos que só funcionam em conjunto. A ordem importa, a limpeza importa mais, e o conjunto é usado com frequência baixa o bastante para que quase ninguém o lembre com exatidão. É exatamente o formato de problema que um construtor determinístico resolve.

## A ordem que ela emite, e por quê

A ferramenta emite **filtro primeiro, enable por último**. O guia de administração da própria Fortinet mostra `diagnose debug enable` primeiro, antes do filtro, e **os dois funcionam** — a ferramenta diz isso nas notas em vez de escolher em silêncio. O motivo para preferir o filtro primeiro é prático: num firewall movimentado, ligar a saída antes do filtro rastreia tudo até o filtro entrar.

## Três coisas que ela sempre informa

- **A contagem é de pacotes, não de segundos.** `trace start 100` são cem pacotes, e uma interface movimentada pode esgotá-los em menos de um segundo.
- **Tráfego com offload nunca chega a esse código.** Em plataformas NP ou SP, um filtro correto pode não produzir nada enquanto o tráfego claramente flui. É o motivo mais comum de um bom trace parecer quebrado.
- **Os números de linha na saída não são estáveis entre versões.** Case pelo nome da função.

## O que ela não faz

Não pode saber a sua plataforma, o seu arranjo de VDOMs ou se a sua sessão está com offload, e não valida nada contra um equipamento. Ela se recusa a montar um trace sem filtro, porque um debug flow sem filtro num firewall de produção é a forma mais rápida de tornar um console inutilizável.

## Standards and references

- [Fortinet - Debugging the packet flow](https://docs.fortinet.com/document/fortigate/7.6.6/administration-guide/54688/debugging-the-packet-flow)

## Related reading

- [Lendo um debug flow de FortiGate](https://ronutz.com/pt-BR/learn/fortigate-debug-flow.md): A sequência diagnose debug flow é uma receita, não um comando: por que a ordem importa, por que a limpeza importa mais, o que a contagem de pacotes realmente conta, e o motivo de offload em hardware que faz um trace correto não mostrar nada.
- [Por que a sua regra do FortiGate não disparou](https://ronutz.com/pt-BR/learn/fortigate-policy-order.md): O primeiro match vence e a avaliação para, então uma regra mais ampla acima torna uma mais específica abaixo inalcançável. E as duas coisas que a Fortinet documenta e as pessoas continuam ignorando: o ID da policy não é a ordem, e cada direção precisa da sua própria policy.
