Политика межсетевого экрана в EVPN: централизованный шлюз против распределённого IRB

Две схемы EVPN размещают шлюз арендатора в разных местах, и межсетевой экран в каждой видит разный трафик. При централизованном шлюзе трафик между подсетями доходит до межсетевого экрана, потому что маршрутизация происходит именно там. При распределённом IRB коммутаторы leaf маршрутизируют локально, и межсетевой экран ничего не видит, если не вставить его туда намеренно. Ни одна модель не ошибочна. Ошибочно подключать межсетевой экран на границе и полагать, что fabric доставит ему трафик.

Две модели, две разные точки проверки

Сначала назовите потоки, которым нужна проверка, потому что две модели обрабатывают их по-разному.

Трафик внутри одной подсети — та строка, которую забывают. Два хоста в одном VLAN общаются через мост, и на этом пути нет маршрутизирующего межсетевого экрана, если его не перехватит отдельная схема проверки уровня 2. Это верно в обеих моделях, поэтому это пробел в проектировании, а не сравнение между ними.

Остальные три строки — там, где модели действительно расходятся.

Централизованный шлюз: простая проверка, реальная стоимость транзита

Держите VLAN арендатора как сервисы уровня 2 и разместите их маршрутизирующие шлюзы на межсетевом экране. Трафик между подсетями идёт к этому шлюзу и обратно, возможно, даже когда оба хоста находятся на одном leaf. Точка проверки однозначна, и в этом весь аргумент схемы. Цена — транзитная нагрузка на межсетевом экране плюс центральная зависимость от ёмкости и доступности, которую теперь нужно спроектировать.

Ограничьте изменение теми шлюзами арендатора, которые имеете в виду. Удалять каждый адрес VLAN слишком широко, когда управление, underlay и интерфейсы платформы имеют отдельные задачи. Проверьте и второй активный шлюз, потому что тот, что всё ещё маршрутизирует в обход межсетевого экрана, тихо обесценивает схему.

Эту модель проще объяснить аудитору. Она не становится автоматически дешевле в эксплуатации.

Распределённый IRB: быстрый путь, по умолчанию без проверки

С распределёнными anycast-шлюзами каждый leaf маршрутизирует трафик арендатора локально, и RFC 9135 описывает, почему это избегает возврата через централизованный шлюз. Выгода реальна, и у неё есть прямое следствие: проверку нельзя вывести из того, куда включён межсетевой экран. Межсетевой экран, подключённый к граничному leaf, видит внешний трафик и всё, что вы явно направляете к нему.

Вставьте сервис механизмом, который платформа действительно поддерживает: перенаправление на основе политик, сервисный узел или контролируемая маршрутизация между VRF через межсетевой экран. Сопоставьте предполагаемый трафик в его реальной точке входа. Политика, написанная на интерфейсе, обращённом к хостам, не покрывает пакет, приходящий из overlay.

Читайте установленные маршруты, а не предполагаемый маршрут по умолчанию. Более конкретный префикс арендатора, импортированный напрямую, может обойти маршрут по умолчанию, указывающий на межсетевой экран, и в конфигурации ничего не будет выглядеть неправильно.

Симметрия — свойство маршрутизации, а не гарантия проверки

Симметричный IRB описывает, как входные и выходные узлы provider edge обрабатывают маршрутизацию и мостовое соединение для потока. Он ничего не говорит о том, достигают ли оба направления одного и того же устройства с состоянием. ECMP, anycast и высокая доступность межсетевого экрана влияют на то, какой узел видит обратный трафик, а поддерживаемая модель состояния кластера решает, допустимо ли это.

Прослеживайте обратный путь явно для каждого потока, который вам важен. NAT не является универсальной заменой этой работы, и схемы, которые на него полагаются, обычно находят пробел во время failover, а не во время построения.

Пройдите один обязательный поток и один намеренно исключённый поток в обоих направлениях, прежде чем утвердить схему.

Как выбирать и что проверять в любом случае

Выбирайте централизованный шлюз, когда охват проверкой важнее транзитной ёмкости и вы можете позволить себе центральную зависимость. Выбирайте распределённый IRB, когда локальная маршрутизация — суть, и закладывайте бюджет на явное включение сервиса, а не предполагайте его.

Затем проверьте маршрутизацию, которую вы действительно установили, потому что именно там две схемы различаются сильнее всего:

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

Включите в тест отказ и восстановление сервисного узла. Резервный маршрут, который тихо обходит проверку, — иное решение, чем запланированная политика fail-open, и обычно подразумевается только одна из двух. Готовая схема называет, куда маршрутизируется каждый класс трафика, где он проверяется и что происходит, когда этот путь проверки недоступен.