Я нахожусь в процессе перестройки нашей сети, проблема, к которой я все время возвращаюсь, заключается в следующем: попытка перенести уровень 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/
Ответы:
Я бы выбрал один из двух вариантов:
Индивидуальные виртуальные брандмауэры для каждого арендатора
Плюсы:
Минусы:
Большое шасси / кластер брандмауэра с экземпляром / контекстом маршрутизации для каждого клиента
Разверните большой центральный межсетевой экран (кластер), висящий сбоку от вашего ядра, и используйте внутренний и внешний экземпляр маршрутизации для маршрутизации трафика и обратно к нему (например: шлюз по умолчанию на внутреннем экземпляре - это брандмауэр, шлюз по умолчанию на межсетевой экран - это ваш внешний экземпляр в ядре, а внешний экземпляр по умолчанию - ваши границы.)
Плюсы:
Минусы:
источник
Какие основные коммутаторы вы используете? Политики, как правило, выполняются на уровне распространения. Если вы используете свернутый дизайн ядра, то ядро должно быть в состоянии удовлетворить ваши требования. Кроме того, вам нравится государственная проверка или просто ACLS. Если у вас есть какое-либо соответствие, которому вы должны следовать, acls может быть недостаточно.
Лично я бы пошел с брандмауэром, возможно, поищу тот, который можно кластеризовать, чтобы вы могли кластеризовать каждый вместе и поддерживать централизованно управляемую базу правил, такую как брандмауэр sourcefire.
источник