Я зараз переглядаю нашу мережу. Проблема, до якої я все-таки повертаюся, полягає в тому, щоб: довести рівень 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/