Высокая доступность для прозрачного межсетевого экрана pfsense?

PFsense имеет встроенную высокую доступность, используя несколько вещей. У него есть CARP для обеспечения отработки отказа на его LAN и WAN IP, и у него есть собственный протокол синхронизации конфигурации.

Представьте, что есть два межсетевых экрана pfsense с выделенной частной сетью / 30 (или / 126 на IPv6), с которой они могут общаться. У каждого из них также есть по крайней мере два дополнительных сетевых порта, давайте пока помечаем их как WAN / LAN.

PFsense также можно перевести в режим «моста», подключив WAN / LAN к сети, я могу подключить маршрутизатор к его порту WAN, который может выступать в роли DHCP / DNS для локальной сети. Все, что делает блок PFsense, - это фильтрует пакеты.

Теперь представьте, что это сделано не для частной сети, а для публичной сети. обратите внимание, что IP4 являются ценным ресурсом, и они также в основном уже используются, поэтому их нельзя повторно использовать. По сути, предположим, что есть только 2 IP-адреса, доступных для использования между двумя блоками PFsense, и нет возможности создания новой сети. Кроме того, части сети за брандмауэром (то есть маршрутизатор) не находятся под моим контролем. Это означает: мы не можем отключить сеть и попросить администратора маршрутизатора перенаправить сеть, используя статические маршруты.

Таким образом, в идеале, мы должны поместить два блока PFsense и подключить их как на стороне WAN, так и на стороне LAN к коммутатору, и подключить коммутаторы к маршрутизатору на стороне WAN и серверам на стороне LAN. Но это создало бы очевидный цикл: поскольку блоки PFsense по сути являются модными коммутаторами в режиме моста, у нас есть петля уровня 2 OSI, выполняющая PF1 >> WAN-коммутатор >> PF2 >> LAN-коммутатор >> PF1, и сеть будет просто не работает вообще.

Следовательно, логическое решение, если требуется высокая доступность, состоит в том, чтобы каким-то образом получить и то, и другое . Но отработка отказа обсуждается только с точки зрения IP-адресов CARP. Прозрачные мосты вообще не имеют IP-адресов, так как я могу получить свой торт и съесть его тоже?

Моя первоначальная идея заключается в том, что блоки PFsense должны каким-то образом координировать следующее: в то время как вторичный блок видит, что первичный подключен к сети, он должен выключить свой интерфейс локальной сети (в идеале: это означает, что оба брандмауэра PFsense остаются доступными из Интернета для настройки). Для этого он может использовать интерфейс SYNC; даже если цикл создан, сеть SYNC должна оставаться работоспособной.

Какой самый простой / канонический способ достижения этого?

Для наглядности приведу небольшую сетевую диаграмму. Предположим для оптимального решения: красные части находятся вне контроля и не могут быть изменены.