Использовать выделенную подсеть для подключения всех маршрутизаторов / брандмауэров?

В моей сети есть пара маршрутизаторов / брандмауэров (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 и в любом случае могут напрямую общаться друг с другом, вы просто "поощряете" проблемы с производительностью путем неоптимальной маршрутизации.

Другие вопросы по тегам