# F5 SSL Orchestrator: Topologias de Forward e Reverse Proxy > O SSL Orchestrator é o produto dedicado de visibilidade TLS da F5: ele descriptografa o tráfego uma vez e o direciona por uma cadeia de dispositivos de segurança. Suas topologias mapeiam diretamente sobre os modos genéricos de proxy, forward proxy para saída (forjando certificados) e reverse proxy para entrada (detendo-os), nas formas L3 explícita, L3 transparente e L2. Este artigo cobre os nomes das topologias, como cada uma trata os certificados, e o modelo de encadeamento de serviços que é o propósito do produto. Source: https://ronutz.com/pt-BR/learn/f5-ssl-orchestrator-topologies Updated: 2026-07-06 --- Os artigos genéricos sobre SSL forward proxy e TLS de entrada descrevem a interceptação de forma abstrata. O SSL Orchestrator (SSLO) da F5 é uma implementação concreta e construída para esse fim de ambos, sobre a plataforma BIG-IP, e sua terminologia mapeia de forma limpa sobre aquelas ideias genéricas assim que você vê a correspondência. Este texto é escrito para complementar aqueles artigos, não repeti-los, então ele assume a mecânica de forjar e terminar e foca em como o SSLO os nomeia e organiza. ## O que o SSL Orchestrator adiciona sobre uma interceptação simples Um BIG-IP com perfis client-SSL e server-SSL já pode terminar e recriptografar TLS. O SSL Orchestrator existe porque inspecionar tráfego descriptografado normalmente significa alimentá-lo a *vários* dispositivos de segurança (um firewall, um IPS, um appliance de DLP, um sandbox de malware), e fazer isso bem é mais difícil que uma única descriptografia. O SSLO descriptografa uma vez e então direciona o texto claro por uma **cadeia de serviços dinâmica**: um conjunto de serviços de segurança endereçáveis de forma independente aos quais o tráfego pode ser roteado com base em política. A documentação da F5 enfatiza o contraste com uma daisy chain tradicional, onde o tráfego entra num dispositivo, sai para o próximo, e assim por diante; uma cadeia de serviços dinâmica deixa os dispositivos serem alvos de forma independente, e os serviços podem ser de tipos diferentes, Camada 2 inline, Camada 3 inline (next-hop roteado), HTTP explícito/transparente, ICAP, ou TAP somente-recepção. Descriptografar-uma-vez-inspecionar-muitos é a razão de existir do produto. ## A regra do certificado que divide tudo Conforme o próprio guia de arquitetura da F5, a linha divisória é direta: o forward proxy do SSL Orchestrator funciona forjando novos certificados para os clientes com base no certificado recebido do servidor, e o reverse proxy funciona enviando seu próprio certificado ao cliente. Essa única frase é toda a distinção forward-versus-reverse dos artigos genéricos, dita nos termos da F5. O forward proxy (saída) reemite um certificado de servidor ao cliente, assinado pela CA da organização em que seus dispositivos gerenciados confiam; o reverse proxy (entrada) apresenta o certificado real do servidor porque a organização é dona daquele servidor. Todo o resto de uma topologia decorre de qual lado dessa linha ela está. ## As topologias de saída (forward proxy) O SSLO apresenta a interceptação de saída em três formatos, e os nomes se alinham com o eixo genérico explícito/transparente: **L3 Explicit Proxy** é o forward proxy explícito tradicional. A topologia define um IP e porta de escuta que os clientes são configurados a usar (à mão, PAC ou WPAD), e fala o protocolo de proxy explícito, incluindo o método HTTP CONNECT para HTTPS. Um detalhe útil de implementação: a topologia de proxy explícito do SSLO constrói dois virtual servers, o VIP de proxy explícito em si, e um VIP de túnel TCP ao qual a configuração SSL, a política de segurança e as cadeias de serviços de fato se conectam; o tráfego do cliente chega ao VIP explícito e dá a volta pelo VIP de túnel. Como a autenticação acontece na camada de conexão do proxy, uma política de autenticação (uma política de acesso SWG-Explicit emitindo um desafio HTTP 407) se conecta ao VIP explícito, separadamente da política de segurança. **L3 Outbound** é o forward proxy transparente tradicional. Não há endereço de proxy configurado; o tráfego é roteado ao self-IP do BIG-IP como um next hop (por gateway do cliente, roteamento baseado em política, WCCP ou roteamento dinâmico), e o cliente desconhece. Regras de interceptação (listeners curinga em TCP, UDP e outros protocolos) capturam os fluxos. **L2 Outbound** embute o mesmo comportamento de forward proxy numa arquitetura de "virtual wire" de Camada 2, onde o BIG-IP é bump-in-the-wire em vez de um salto roteado; o tratamento do certificado (reemitir ao cliente) é idêntico, apenas a inserção na rede difere. ## As topologias de entrada (reverse proxy) **L3 Inbound** é uma configuração de "gateway" de reverse proxy: o SSLO fica na frente de aplicações (ou na frente de outro ADC) com um listener curinga, encaminhando o tráfego descriptografado para dentro e recriptografando na saída, já que o caminho de entrada precisa recriptografar para alcançar os servidores reais. No modo Gateway a topologia é um ponto de roteamento com um destino curinga e sem tradução de endereços; o modo Application habilita a tradução de endereços para aplicações individuais. Existe uma forma L2 Inbound apenas como gateway. **Existing Application** é o padrão a conhecer quando um BIG-IP LTM (ou APM) já fica na frente da aplicação e já faz sua própria terminação client-SSL/server-SSL e balanceamento de carga. Essa topologia adiciona apenas os serviços de segurança, a cadeia de serviços e a política de segurança (que se manifesta como uma política per-request do Access) e os conecta ao virtual existente, em vez de construir novos virtual servers e SSL. É como o SSLO acopla inspeção a uma configuração de entrega de aplicações que já está no lugar. ## Dois detalhes que vale levar Primeiro, o TLS mútuo através de um SSLO em reverse proxy precisa de tratamento especial, porque o dispositivo do meio não detém a chave do cliente. A resposta da F5 é o **Client Certificate Constrained Delegation (C3D)**: o SSLO completa o mTLS com o cliente, então forja um certificado de cliente equivalente (com uma chave que ele controla) para apresentar ao servidor. Onde isso não é desejado, as configurações SSL oferecem uma opção "Bypass on Client Cert Failure" que detecta a requisição de certificado de cliente do servidor e faz auto-bypass da descriptografia para aquele fluxo, a mesma resolução de "isentar destinos de TLS mútuo" que os artigos genéricos descrevem. Segundo, implantações do SSLO geram um grande número de objetos TMOS com um esquema de nomenclatura sistemático (por exemplo `-t-`/`-u-` marcando objetos TCP/UDP e `-4-`/`-6-` marcando IPv4/IPv6), e é por isso que ler uma configuração do SSLO é mais fácil quando você sabe que é um arranjo gerado por máquina de virtual servers, perfis SSL e pools comuns do BIG-IP, em vez de uma caixa preta monolítica.