Política de cortafuegos en EVPN: pasarela centralizada fronte a IRB distribuído

Dous deseños EVPN colocan a pasarela do inquilino en lugares distintos, e o cortafuegos ve tráfico diferente en cada un. Cunha pasarela centralizada, o tráfico entre subredes chega ao cortafuegos porque é alí onde se produce o encamiñamento. Con IRB distribuído, os conmutadores leaf encamiñan localmente e o cortafuegos non ve nada agás que o insiras deliberadamente. Ningún dos dous modelos é incorrecto. O incorrecto é conectar un cortafuegos na fronteira e supoñer que o fabric lle entregará o tráfico.

Dous modelos, dous puntos de inspección distintos

Nomea primeiro os fluxos que precisan inspección, porque os dous modelos os tratan de xeito distinto.

O tráfico dentro da mesma subrede é a fila que a xente esquece. Dous hosts nunha VLAN falan mediante ponte, e nese camiño non hai ningún cortafuegos encamiñado agás que o intercepte un deseño de inspección de capa 2 á parte. Iso é certo nos dous modelos, así que é un oco de deseño e non unha comparación entre eles.

As outras tres filas son onde os modelos realmente divergen.

Pasarela centralizada: inspección simple, custo real de tránsito

Mantén as VLAN do inquilino como servizos de capa 2 e coloca as súas pasarelas de encamiñamento no cortafuegos. O tráfico entre subredes viaxa entón a esa pasarela e volve, posiblemente mesmo cando ambos os hosts están no mesmo leaf. O punto de inspección é inequívoco, e ese é todo o argumento do deseño. O custo é a carga de tránsito no cortafuegos máis unha dependencia central de capacidade e dispoñibilidade que agora debes enxeñar.

Limita o cambio ás pasarelas de inquilino que pretendes. Quitar cada enderezo VLAN é demasiado amplo cando a xestión, o underlay e as interfaces da plataforma teñen cometidos separados. Comproba tamén unha segunda pasarela activa, porque unha que siga encamiñando arredor do cortafuegos anula o deseño en silencio.

Este modelo é máis doado de explicar a un auditor. Non é automaticamente máis barato de operar.

IRB distribuído: ruta rápida, sen inspección por defecto

Con pasarelas anycast distribuídas, cada leaf encamiña o tráfico do inquilino localmente, e RFC 9135 describe por que iso evita o retorno por unha pasarela centralizada. O beneficio é real e ten unha consecuencia directa: a inspección non se pode inferir de onde está conectado o cortafuegos. Un cortafuegos conectado a un leaf de borde ve o tráfico externo e todo o que redirixas explicitamente cara a el.

Insire o servizo cun mecanismo que a plataforma realmente admita: redirección baseada en políticas, un nodo de servizo ou encamiñamento controlado entre VRF a través do cortafuegos. Fai coincidir o tráfico previsto no seu punto de entrada real. Unha política escrita nunha interface orientada aos hosts non cobre un paquete que chega desde o overlay.

Le as rutas instaladas e non a ruta por defecto prevista. Un prefixo de inquilino máis específico importado directamente pode saltar a ruta por defecto que apunta ao cortafuegos, e nada na configuración parecerá incorrecto.

A simetría é unha propiedade de encamiñamento, non unha garantía de inspección

O IRB simétrico describe como os nodos provider edge de entrada e saída manexan o encamiñamento e a ponte para un fluxo. Non di nada sobre se ambas as direccións chegan ao mesmo dispositivo con estado. ECMP, anycast e a alta dispoñibilidade do cortafuegos inflúen en que nodo ve o tráfico de retorno, e o modelo de estado admitido do clúster decide se iso é aceptable.

Segue o camiño de retorno explicitamente para cada fluxo que che importe. NAT non é un substituto universal dese traballo, e os deseños que se apoian nel adoitan atopar o oco durante un failover e non durante a construción.

Percorre un fluxo obrigatorio e un fluxo excluído a propósito, en ambas as direccións, antes de aprobar o deseño.

Como elixir e que probar en calquera caso

Elixe a pasarela centralizada cando a cobertura de inspección importe máis que a capacidade de tránsito e poidas permitirche a dependencia central. Elixe IRB distribuído cando o encamiñamento local sexa o obxectivo, e orzamenta a inserción explícita de servizo en lugar de dala por suposta.

Despois proba o encamiñamento que realmente instalaches, porque é aí onde os dous deseños máis difiren:

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

Inclúe na proba o fallo e a recuperación do nodo de servizo. Unha ruta de reserva que evita a inspección en silencio é unha decisión distinta dunha política fail-open planificada, e normalmente só se pretende unha das dúas. O deseño rematado nomea onde encamiña cada clase de tráfico, onde se inspecciona e que ocorre cando esa ruta de inspección non está dispoñible.