Política de firewall no EVPN: gateway centralizado versus IRB distribuído

Dois desenhos EVPN colocam o gateway do inquilino em locais diferentes, e o firewall vê tráfego diferente em cada um. Com um gateway centralizado, o tráfego entre sub-redes chega ao firewall porque é ali que o roteamento acontece. Com IRB distribuído, os switches leaf roteiam localmente e o firewall não vê nada, a menos que você o insira de propósito. Nenhum dos modelos está errado. O erro é ligar um firewall na borda e supor que o fabric entregará o tráfego a ele.

Dois modelos, dois pontos de inspeção diferentes

Nomeie primeiro os fluxos que precisam de inspeção, porque os dois modelos os tratam de forma diferente.

O tráfego dentro da mesma sub-rede é a linha que as pessoas esquecem. Dois hosts numa VLAN falam por bridging, e nesse caminho não há firewall roteado, a menos que um projeto de inspeção de camada 2 separado o intercepte. Isso vale nos dois modelos, portanto é uma lacuna de projeto e não uma comparação entre eles.

As outras três linhas são onde os modelos realmente divergem.

Gateway centralizado: inspeção simples, custo de trânsito real

Mantenha as VLANs do inquilino como serviços de camada 2 e coloque seus gateways de roteamento no firewall. O tráfego entre sub-redes viaja então até esse gateway e volta, possivelmente mesmo quando os dois hosts estão no mesmo leaf. O ponto de inspeção é inequívoco, e esse é todo o argumento do projeto. O custo é a carga de trânsito no firewall mais uma dependência central de capacidade e disponibilidade que agora você precisa projetar.

Limite a mudança aos gateways de inquilino que você pretende. Remover cada endereço VLAN é amplo demais quando gestão, underlay e interfaces da plataforma têm funções separadas. Verifique também um segundo gateway ativo, porque um que ainda roteia ao redor do firewall anula o projeto em silêncio.

Este modelo é mais fácil de explicar a um auditor. Não é automaticamente mais barato de operar.

IRB distribuído: via rápida, sem inspeção por padrão

Com gateways anycast distribuídos, cada leaf roteia o tráfego do inquilino localmente, e o RFC 9135 descreve por que isso evita o retorno por um gateway centralizado. O benefício é real e tem uma consequência direta: a inspeção não pode ser inferida de onde o firewall está conectado. Um firewall ligado a um leaf de borda vê o tráfego externo e tudo o que você redirecionar explicitamente para ele.

Insira o serviço com um mecanismo que a plataforma realmente suporte: redirecionamento baseado em políticas, um nó de serviço ou roteamento controlado entre VRF através do firewall. Faça corresponder o tráfego pretendido no seu ponto de entrada real. Uma política escrita numa interface voltada aos hosts não cobre um pacote que chega do overlay.

Leia as rotas instaladas e não a rota padrão pretendida. Um prefixo de inquilino mais específico importado diretamente pode contornar a rota padrão que aponta para o firewall, e nada na configuração parecerá errado.

A simetria é uma propriedade de roteamento, não uma garantia de inspeção

O IRB simétrico descreve como os nós provider edge de entrada e saída tratam o roteamento e a comutação para um fluxo. Não diz nada sobre se ambas as direções chegam ao mesmo dispositivo com estado. ECMP, anycast e a alta disponibilidade do firewall influenciam qual nó vê o tráfego de retorno, e o modelo de estado suportado pelo cluster decide se isso é aceitável.

Siga o caminho de retorno explicitamente para cada fluxo que lhe importa. NAT não é um substituto universal desse trabalho, e projetos que dependem dele costumam encontrar a lacuna durante um failover e não durante a construção.

Percorra um fluxo obrigatório e um fluxo deliberadamente excluído, nos dois sentidos, antes de aprovar o projeto.

Como escolher e o que testar em qualquer caso

Escolha o gateway centralizado quando a cobertura de inspeção importar mais que a capacidade de trânsito e você puder arcar com a dependência central. Escolha o IRB distribuído quando o roteamento local for o ponto, e orçamente a inserção explícita de serviço em vez de presumi-la.

Depois teste o roteamento que você realmente instalou, porque é aí que os dois projetos mais diferem:

show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefix

Inclua no teste a falha e a recuperação do nó de serviço. Uma rota de reserva que contorna a inspeção em silêncio é uma decisão diferente de uma política fail-open planejada, e normalmente apenas uma das duas é pretendida. O projeto final nomeia para onde cada classe de tráfego roteia, onde é inspecionada e o que acontece quando esse caminho de inspeção não está disponível.