Использовать выделенную подсеть для подключения всех маршрутизаторов / брандмауэров?
В моей сети есть пара маршрутизаторов / брандмауэров (pfSense, TMG 2010, ISA 2006), которые находятся в состоянии с состоянием. Прямо сейчас все они имеют интерфейс в той же подсети, что и большинство устройств и серверов конечных пользователей. Я буду вносить некоторые изменения и размещать некоторые серверы в своих подсетях за этими брандмауэрами, поэтому мне интересно, следует ли мне настроить одну выделенную подсеть для маршрутизаторов, через которые маршрутизируются пакеты друг к другу. Нет никаких протоколов маршрутизации, только статические маршруты.
Я пытаюсь избежать асинхронной маршрутизации, которая может быть проблемой для брандмауэров с сохранением состояния, поскольку трафик проходит по другому пути в сеть и из нее. Если трафик возвращается через другой путь, и у брандмауэра в этом пути нет записи в таблице состояний, тогда трафик может быть заблокирован.
Мой основной вопрос заключается в следующем: это идеальный способ решения этой проблемы? Почему или почему нет? Я не смог найти много с точки зрения передового опыта, но этот подход оставил бы только один маршрутизатор в каждой подсети, поэтому я бы избежал текущей ситуации на разных машинах с разными шлюзами по умолчанию.
Текущий
Router 1 Router 2 Router 3
192.168.1.1/24 ------ 192.168.1.2/24 ------ 192.168.1.3/24 ------ All other devices
| | |
V V V
10.10.10.1/24 10.20.20.1/24 10.30.30.1/24
Предложил
Router 1 Router 2 Router 3
192.168.1.1/24 ------ All other devices
10.200.200.1/24 ----- 10.200.200.2/24 ----- 10.200.200.3/24 ------ Routers/Firewalls only
| | |
V V V
10.10.10.1/24 10.20.20.1/24 10.30.30.1/24
2 ответа
Исходя из моего комментария, что-то вроде этого
+----------+ +----------+ +----------+
| Router 1 | | Router 2 | | Router 3 |
+-------+--+ +----+-----+ +--+-------+
| | |
| | |10.200.200.0/24
| | |
+--v------------v------------v-+
| Router A +-------------+
+-+---------+---------------+--+ |
| | | |
| | | |
| | | |
+------------v-+ +-----v-------+ +-----v-------+ +------v------+
|192.168.1.0/24| |10.10.10.0/24| |10.20.20.0/24| |10.30.30.0/24|
+--------------+ +-------------+ +-------------+ +-------------+
Маршрутизатор 1 = 10.200.200.1
Маршрутизатор 2 = 10.200.200.2
Маршрутизатор 3 = 10.200.200.3
Маршрутизатор A = 10.200.200.254
Таким образом, каждая из нижних сетей имеет только 1 маршрутизатор и, следовательно, 1 маршрут по умолчанию. Для доступа к внутренним подсетям граничным маршрутизаторам требуется только 1 внутренний маршрут.
Внутренний маршрутизатор становится более сложным, потому что ему необходимо знать о нескольких вышестоящих маршрутизаторах и отслеживать соединения, чтобы избежать асинхронной маршрутизации. Я считаю, что преимущества того стоят: вся сложность заключается в этом маршрутизаторе, а все остальное - просто. И вы можете иметь полный контроль над несколькими подключениями на этом хосте. Например, вы можете получать NAT-трафик от всех 3-х подключений к одному и тому же внутреннему серверу, но серверу не нужно ничего знать об этом, внутренний сервер будет отслеживать каждое подключение и соответствующим образом маршрутизировать трафик, чтобы избежать асинхронности.
Это очень похоже на настройку на моей работе, за исключением того, что у нас есть только 2 восходящих соединения. Маршрутизатор A - это пара блоков Linux, работающих в H/A. Отслеживание соединений осуществляется с использованием политик на основе маршрутизации. Лучшее руководство, которое я нашел для PBR: http://www.cyber.com.au/~twb/doc/dual-uplink.txt
Я бы сказал, что вы вводите дополнительный уровень (буквально) сложности.
Я предполагаю, что ваши проблемы асинхронной маршрутизации происходят из ситуации, например 192.168.1.55
отправляет пакет 10.20.20.55
но не имеет маршрута для этого через 192.168.1.2
поэтому отправляет его по умолчанию в 192.168.1.1
куда он перенаправляется 192.168.1.2
, Затем ответный пакет отправляется непосредственно из 192.168.1.2
к первоисточнику, так 192.168.1.1
видят только пакеты от клиента к серверу, а не пакеты от сервера к клиенту.
В моих средах я избегаю проблемы брандмауэра с асинхронной маршрутизацией, добавляя правило, разрешающее отказов маршрутизацию (все, что входит и выходит в тот же интерфейс == тот же уровень 2 == разрешить) Вы не представляете никаких проблем с безопасностью, поскольку src и dst пакета находятся на одном уровне 2 и в любом случае могут напрямую общаться друг с другом, вы просто "поощряете" проблемы с производительностью путем неоптимальной маршрутизации.