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