Намагання вписати централізований брандмауер в мережеву топологію


11

Я зараз переглядаю нашу мережу. Проблема, до якої я все-таки повертаюся, полягає в тому, щоб: довести рівень 3 до основної, при цьому все ще маючи централізований брандмауер.

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

Це має ідеальний сенс, оскільки основні комутатори повинні мати можливість підтримувати швидкість маршрутизації, тому не хочеться занадто багато жертвувати через обробку ACL. Тому я не можу зробити всі свої брандмауери на основних комутаторах самі.

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

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

мережа

Curent Solution

Зараз у нас є конфігурація маршрутизатора на палиці. Це дає нам змогу робити NAT, потужний брандмауер та маршрутизацію VLAN в одному місці. Дуже просто.

Я міг би продовжувати з (приблизно) тим же рішенням, розширивши L2 аж до "вершини" нашої мережі - прикордонних маршрутизаторів. Але тоді я втрачаю всі переваги маршрутизації швидкості проводів, які ядро ​​може запропонувати мені.

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

Можливі рішення

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

Я подумав, що, можливо, я міг би поширити L3 на комутатори доступу і, таким чином, розбити правила брандмауера на більш дрібні сегменти, які потім підходили б до апаратних меж ACL-комутаторів доступу. Але:

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

З'єднані / прозорі брандмауери на кожній висхідній лінії зв'язку між доступом / ядром

Це повинно залучати кілька блоків брандмауера та значно збільшити необхідне обладнання. І може закінчитися дорожче, ніж купувати більші основні маршрутизатори, навіть використовувати звичайні старі 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, або мають навіть навіть віртуальні брандмауери? У вас є декілька хостів VM, на яких ви можете вмикати брандмауері для кожного клієнта, використовуючи два інтерфейси: один, який ви потрапляєте у клієнтську VLAN як шлюз за замовчуванням, і той, який ви підключите до загальнодоступної VLAN, орієнтованої на крайові маршрутизатори. Просто думка (я віддаю перевагу віртуальним брандмауерам).
jwbensley

2
Я б серйозно подивився на віртуалізовані брандмауэры, такі як Cisco ASA 1000V або Catbird (catbird.com). Таким чином, ви можете розмістити брандмауер на кожному відвідувачі. Захистіть списки доступу від основного маршрутизатора.
Рон Трунк

Відповіді:


5

Я вибрав би один із двох варіантів:

Індивідуальні віртуальні міжмережеві екрани

Плюси:

  • Горизонтально масштабований
  • Спінінг і віджимання
  • Відносно несприйнятливий до майбутніх змін топології / дизайну
  • Повна розлука / ізоляція клієнтів

Мінуси:

  • Якщо ви не застосовуєте стандартний шаблон, тепер у вас є n окремих брандмауерів
  • Тепер у вас є n окремих брандмауерів, які слід контролювати
  • Тепер у вас є n окремих брандмауерів, які потрібно виправити

Велике шасі / кластер брандмауера з прикладом / контекстом маршрутизації на орендаря

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

Плюси:

  • Єдине поле для управління та налаштування
  • Єдиний ящик для моніторингу
  • Єдиний ящик для виправлення
  • Розлука з клієнтами

Мінуси:

  • Перший день вартість буде вище
  • Без зменшення масштабу
  • Залежно від конфігурації міжпокупницький трафік може починати маршрутизацію через ваші кордонні маршрутизатори

0

Які основні комутатори ви працюєте? Політика зазвичай виконується на рівні розподілу, якщо ви збираєтеся зі згорнутою базовою конструкцією, то ядро ​​повинне бути в змозі обробити ваші вимоги. Також вам подобається державний огляд або просто acls. Якщо у вас є відповідність, яку потрібно дотримуватися, ACL може бути недостатньою.

Особисто я б пішов з брандмауером, можливо, шукаю той, який може бути кластеризований, щоб ви могли кластеризувати один одного і підтримувати централізовану керовану базу правил, наприклад, брандмауер джерела.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.