Política de cortafuegos en EVPN: puerta de enlace centralizada frente a IRB distribuido
Las puertas de enlace centralizadas encaminan el tráfico de los inquilinos por el cortafuegos, el IRB distribuido no. Compare dónde inspecciona cada uno y qué necesita la ruta rápida.
Dos diseños EVPN colocan la puerta de enlace del inquilino en lugares distintos, y el cortafuegos ve tráfico diferente en cada uno. Con una puerta de enlace centralizada, el tráfico entre subredes llega al cortafuegos porque ahí es donde ocurre el enrutamiento. Con IRB distribuido, los conmutadores leaf enrutan localmente y el cortafuegos no ve nada salvo que lo insertes a propósito. Ninguno de los dos modelos es incorrecto. Lo incorrecto es conectar un cortafuegos en el borde y suponer que el fabric le entregará el tráfico.
Dos modelos, dos puntos de inspección distintos
Nombra primero los flujos que necesitan inspección, porque los dos modelos los tratan de forma distinta.
| Flow class | Centralized gateway | Distributed IRB |
|---|---|---|
| Same subnet | Bridged, not routed | Bridged, not routed |
| Inter-subnet | Routed at the firewall | Routed at the leaf |
| Inter-VRF | At the firewall | Needs leaking or service insertion |
| External | Border firewall | Border firewall |
El tráfico dentro de la misma subred es la fila que la gente olvida. Dos hosts en una VLAN hablan mediante puenteo, y en ese camino no hay ningún cortafuegos enrutado salvo que lo intercepte un diseño de inspección de capa 2 aparte. Eso es cierto en ambos modelos, así que es un hueco de diseño y no una comparación entre ellos.
Las otras tres filas son donde los modelos realmente divergen.
Puerta de enlace centralizada: inspección simple, coste real de tránsito
Mantén las VLAN del inquilino como servicios de capa 2 y coloca sus puertas de enlace de enrutamiento en el cortafuegos. El tráfico entre subredes viaja entonces a esa puerta de enlace y vuelve, posiblemente incluso cuando ambos hosts están en el mismo leaf. El punto de inspección es inequívoco, y ese es todo el argumento del diseño. El coste es la carga de tránsito en el cortafuegos más una dependencia central de capacidad y disponibilidad que ahora debes ingeniar.
Limita el cambio a las puertas de enlace de inquilino que pretendes. Quitar cada dirección VLAN es demasiado amplio cuando la gestión, el underlay y las interfaces de plataforma tienen cometidos separados. Comprueba también una segunda puerta de enlace activa, porque una que siga enrutando alrededor del cortafuegos anula el diseño en silencio.
Este modelo es más fácil de explicar a un auditor. No es automáticamente más barato de operar.
IRB distribuido: ruta rápida, sin inspección por defecto
Con puertas de enlace anycast distribuidas, cada leaf enruta el tráfico del inquilino localmente, y RFC 9135 describe por qué eso evita el retorno por una puerta de enlace centralizada. El beneficio es real y tiene una consecuencia directa: la inspección no puede inferirse de dónde está enchufado el cortafuegos. Un cortafuegos conectado a un leaf de borde ve el tráfico externo y todo lo que redirijas explícitamente hacia él.
Inserta el servicio con un mecanismo que la plataforma realmente admita: redirección basada en políticas, un nodo de servicio o enrutamiento controlado entre VRF a través del cortafuegos. Haz coincidir el tráfico previsto en su punto de entrada real. Una política escrita en una interfaz orientada a los hosts no cubre un paquete que llega desde el overlay.
Lee las rutas instaladas y no la ruta por defecto prevista. Un prefijo de inquilino más específico importado directamente puede saltarse la ruta por defecto que apunta al cortafuegos, y nada en la configuración parecerá incorrecto.
La simetría es una propiedad de enrutamiento, no una garantía de inspección
El IRB simétrico describe cómo los nodos provider edge de entrada y salida manejan el enrutamiento y el puenteo para un flujo. No dice nada sobre si ambas direcciones llegan al mismo dispositivo con estado. ECMP, anycast y la alta disponibilidad del cortafuegos influyen en qué nodo ve el tráfico de retorno, y el modelo de estado admitido del clúster decide si eso es aceptable.
Sigue el camino de retorno de forma explícita para cada flujo que te importe. NAT no es un sustituto universal de ese trabajo, y los diseños que se apoyan en él suelen encontrar el hueco durante un failover y no durante la construcción.
Recorre un flujo obligatorio y un flujo excluido a propósito, en ambas direcciones, antes de aprobar el diseño.
Cómo elegir y qué probar en cualquier caso
Elige la puerta de enlace centralizada cuando la cobertura de inspección importe más que la capacidad de tránsito y puedas permitirte la dependencia central. Elige IRB distribuido cuando el enrutamiento local sea el objetivo, y presupuesta la inserción explícita de servicio en lugar de darla por supuesta.
Después prueba el enrutamiento que realmente instalaste, porque es ahí donde los dos diseños más difieren:
show ip route vrf TENANT 10.20.0.0/16
show bgp l2vpn evpn route-type prefixIncluye en la prueba el fallo y la recuperación del nodo de servicio. Una ruta de reserva que evita la inspección en silencio es una decisión distinta de una política fail-open planificada, y normalmente solo se pretende una de las dos. El diseño terminado nombra dónde enruta cada clase de tráfico, dónde se inspecciona y qué ocurre cuando esa ruta de inspección no está disponible.