Попытка встроить централизованный межсетевой экран в топологию сети


11

Я нахожусь в процессе перестройки нашей сети, проблема, к которой я все время возвращаюсь, заключается в следующем: попытка перенести уровень 3 в ядро, сохраняя при этом централизованный межсетевой экран.

Основная проблема, с которой я столкнулся, заключается в том, что у «мини-ядерных» коммутаторов, на которых я смотрел, всегда есть низкие аппаратные ограничения ACL, которые мы могли бы быстро достичь даже при нашем нынешнем размере. В настоящее время я собираюсь (надеюсь) приобрести пару EX4300-32F для ядра, но я посмотрел на другие модели и другие опции из линейки Juniper и Brocade ICX. Все они, кажется, имеют одинаковые низкие пределы ACL.

Это имеет смысл, поскольку базовые коммутаторы должны иметь возможность поддерживать маршрутизацию на скорости передачи данных, поэтому не нужно слишком жертвовать процессами ACL. Так что я не могу сделать все свои брандмауэры на самих коммутаторах ядра.

Тем не менее, мы делаем в основном полностью управляемые серверы, и наличие централизованного (с сохранением состояния) брандмауэра очень помогает с этим управлением - поскольку у нас не может быть клиентов, говорящих напрямую друг с другом. Я бы хотел оставить это так, если мы можем, но я чувствую, что большинство сетей провайдеров не будут делать такого рода вещи, поэтому, в большинстве случаев, было бы просто выполнить маршрутизацию в ядре.

Для справки, вот топология, которую я в идеале хотел бы сделать (но, конечно, не уверен, куда поместится FW).

сеть

Curent Solution

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

Я мог бы продолжить (примерно) то же самое решение, расширив L2 до «вершины» нашей сети - пограничных маршрутизаторов. Но затем я теряю все преимущества маршрутизации со скоростью передачи данных, которую может предложить ядро.

Основные коммутаторы IIRC могут выполнять маршрутизацию со скоростью 464 Гбит / с, в то время как мои пограничные маршрутизаторы смогут предложить, возможно, 10 или 20 Гбит / с, если мне повезет. Технически это сейчас не проблема, а скорее проблема роста. Я чувствую, как будто мы не проектируем архитектуру, чтобы использовать возможности основной маршрутизации сейчас, будет болезненно переделывать все, когда мы становимся больше и должны использовать эту емкость. Я бы предпочел сделать это правильно с первого раза.

Возможные решения

Уровень 3 для доступа

Я подумал, что, возможно, я смогу расширить L3 до коммутаторов доступа и таким образом разбить правила брандмауэра на более мелкие сегменты, которые затем будут соответствовать аппаратным ограничениям ACL коммутатора доступа. Но:

  • Насколько я знаю, это не было бы ACL с состоянием
  • L3 для доступа, мне кажется, гораздо более негибким. Перемещение сервера или миграция виртуальных машин в другие кабинеты были бы более болезненными.
  • Если я собираюсь управлять брандмауэром в верхней части каждой стойки (только шесть из них), я все равно, возможно, захочу автоматизацию. Поэтому на данный момент автоматизировать управление брандмауэрами на уровне хоста не так уж и сложно. Таким образом, избегая всего вопроса.

Мостовые / прозрачные брандмауэры на каждой восходящей линии между доступом / ядром

Для этого потребуется задействовать несколько брандмауэров и значительно увеличить необходимое оборудование. И может оказаться более дорогим, чем покупка более крупных базовых маршрутизаторов, даже используя обычные старые блоки Linux в качестве брандмауэров.

Гигантские основные маршрутизаторы

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

Нет централизованного межсетевого экрана

Так как я прыгаю через обручи, возможно, это не стоит усилий. Это всегда было приятно, а иногда и выгодно для покупателей, которым нужен «аппаратный» брандмауэр.

Но кажется, что наличие централизованного брандмауэра для всей вашей сети невозможно. Тогда мне интересно, как крупные интернет-провайдеры могут предлагать аппаратные брандмауэры клиентам с выделенными серверами, когда у них сотни или даже тысячи хостов?

Кто-нибудь может придумать способ решения этой проблемы? Или я что-то упустил полностью, или вариант одной из идей выше?

ОБНОВЛЕНИЕ 2014-06-16:

Основываясь на предложении @ Рона, я наткнулся на эту статью, которая довольно хорошо объясняет проблему, с которой я сталкиваюсь, и хороший способ ее решения.

Если нет других предложений, я бы сказал, что это проблема с рекомендациями по продукту, так что я полагаю, что это конец.

http://it20.info/2011/03/the-93-000-firewall-rules-problem-and-why-cloud-is-not-just-orchestration/


Используете ли вы VRF-Lite или MPLS в сети? Какой марки основные выключатели?
Даниэль Диб

@DanielDib Пока не использую VRF или MPLS, но я планирую развернуть его между этим сайтом и другим сайтом. Марка еще не определена (все еще выясняется список покупок) ... Но сейчас мы в основном смотрим на Juniper EX4300-32F или Brocade ICX 6610-48-PE
Geekman

1
Я проголосовал за закрытие; Причина в том, что вопрос, который вы задаете, состоит из очень конкретных деталей вашего решения, таких как выбор поставщика / модели, бюджетные ограничения и т. Д., Как это изменит ваше предложение для ваших клиентов ... Все, что здесь не подходит это деловые решения. Вы можете спросить, каковы плюсы и минусы каждой топологии, но никто не может сказать вам, что лучше для вас.
Jwbensley

1
Мои два пенса по вашей ситуации: Рассматривали ли вы брандмауэры, которые поддерживают контексты, такие как Cisco ASA, или даже просто виртуальные брандмауэры? Есть несколько виртуальных хостов, на которых вы можете включить межсетевые экраны для каждого клиента с двумя интерфейсами: один, который вы добавляете в клиентскую VLAN в качестве шлюза по умолчанию, а другой - в общедоступную VLAN по направлению к вашим пограничным маршрутизаторам. Просто мысль (я предпочитаю виртуальные брандмауэры).
jwbensley

2
Я бы серьезно посмотрел на виртуальные межсетевые экраны, такие как Cisco ASA 1000V или Catbird (catbird.com). Таким образом, вы можете установить брандмауэр на каждом сервере. Держите свои списки доступа вне основного маршрутизатора.
Ron Trunk

Ответы:


5

Я бы выбрал один из двух вариантов:

Индивидуальные виртуальные брандмауэры для каждого арендатора

Плюсы:

  • Горизонтально масштабируемый
  • Раскрутка и раскрутка
  • Относительно невосприимчив к будущим изменениям топологии / дизайна
  • Полное отделение клиента / изоляция

Минусы:

  • Если вы не используете стандартный шаблон, теперь у вас есть n отдельных брандмауэров для управления
  • Теперь у вас есть n отдельных брандмауэров для мониторинга
  • Теперь у вас есть n отдельных брандмауэров для патча

Большое шасси / кластер брандмауэра с экземпляром / контекстом маршрутизации для каждого клиента

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

Плюсы:

  • Единый блок для управления и настройки
  • Одна коробка для мониторинга
  • Одна коробка для патча
  • Разделение клиентов

Минусы:

  • Стоимость первого дня будет выше
  • Нет уменьшения
  • В зависимости от конфигурации межабонентский трафик может начать маршрутизацию через граничные маршрутизаторы.

0

Какие основные коммутаторы вы используете? Политики, как правило, выполняются на уровне распространения. Если вы используете свернутый дизайн ядра, то ядро ​​должно быть в состоянии удовлетворить ваши требования. Кроме того, вам нравится государственная проверка или просто ACLS. Если у вас есть какое-либо соответствие, которому вы должны следовать, acls может быть недостаточно.

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

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.