Jestem w trakcie przeciążania naszej sieci, do którego wciąż wracam: próba przeniesienia warstwy 3 do rdzenia, wciąż mając scentralizowaną zaporę ogniową.
Głównym problemem, jaki tu mam, jest to, że przełączniki „mini core”, na które patrzyłem, zawsze mają niskie limity sprzętowej listy ACL, które nawet przy naszym obecnym rozmiarze moglibyśmy szybko trafić. Mam zamiar (mam nadzieję) kupić parę EX4300-32F do rdzenia, ale przyjrzałem się innym modelom i innym opcjom z oferty Juniper i Brocade z serii ICX. Wszystkie wydają się mieć takie same niskie limity ACL.
Ma to sens, ponieważ przełączniki rdzeniowe muszą być w stanie utrzymać routing z prędkością drutu, więc nie chcę poświęcać zbyt wiele poprzez przetwarzanie ACL. Więc nie mogę zrobić całego firewalla na samych przełącznikach podstawowych.
Jednak wykonujemy głównie w pełni zarządzane serwery, a scentralizowana (stanowa) zapora bardzo pomaga w tym zarządzaniu - ponieważ nie możemy mieć klientów rozmawiających bezpośrednio ze sobą. Chciałbym, aby tak było, jeśli możemy, ale wydaje mi się, że większość sieci ISP nie zrobiłaby tego rodzaju rzeczy, dlatego w większości przypadków robienie routingu w rdzeniu byłoby proste.
Dla porównania, oto topologia, którą chciałbym zrobić (ale nie jestem pewny, gdzie najlepiej dopasować FW).
Curent Solution
W tej chwili mamy konfigurację routera na patyku. Umożliwia nam to wykonywanie NAT, stanowego firewalla i routingu VLAN w jednym miejscu. Bardzo prosty.
Mógłbym kontynuować (z grubsza) tym samym rozwiązaniem, rozszerzając L2 aż do „szczytu” naszej sieci - routerów granicznych. Ale potem tracę wszystkie zalety routingu z prędkością drutu, które może zaoferować mi rdzeń.
IIRC podstawowe przełączniki mogą wykonywać routing z prędkością 464 Gb / s, a moje routery graniczne będą w stanie zaoferować może 10 lub 20 Gb / s, jeśli będę miał szczęście. Z technicznego punktu widzenia nie jest to obecnie problem, ale bardziej kwestia wzrostu. Wydaje mi się, że jeśli nie zaprojektujemy architektury w celu zwiększenia wydajności rutowania, będzie to bolesne, aby przerobić wszystko, gdy będziemy większe i będziemy musieli wykorzystać tę pojemność. Wolę to zrobić za pierwszym razem.
Możliwe rozwiązania
Warstwa 3, aby uzyskać dostęp
Pomyślałem, że być może mógłbym rozszerzyć L3 na przełączniki dostępu, a tym samym rozbić reguły zapory ogniowej na mniejsze segmenty, które pasowałyby do ograniczeń sprzętowych list ACL przełączników dostępu. Ale:
- O ile mi wiadomo, nie byłyby to stanowe listy ACL
- Wydaje mi się, że L3 to Access jest znacznie mniej elastyczny. Przenoszenie serwerów lub migracja maszyn wirtualnych do innych szaf byłoby bardziej bolesne.
- Jeśli zamierzam zarządzać zaporą ogniową na górze każdej szafy (tylko sześć), prawdopodobnie i tak chcę automatyzacji. W tym momencie zautomatyzowanie zarządzania zaporami ogniowymi na poziomie hosta nie jest wielkim krokiem. W ten sposób unikamy całego problemu.
Mostkowane / przezroczyste zapory ogniowe na każdym łączu zwrotnym między dostępem / rdzeniem
Musiałoby to obejmować wiele zapór ogniowych i znacznie zwiększyć wymagany sprzęt. I może okazać się droższy niż kupowanie większych routerów, nawet używając zwykłych starych urządzeń Linux jako zapór ogniowych.
Gigantyczne routery rdzeniowe
Mógłbym kupić większe urządzenie, które może wykonać firewall, którego potrzebuję i ma znacznie większą wydajność routingu. Ale tak naprawdę nie mam na to budżetu, a jeśli próbuję zmusić urządzenie do zrobienia czegoś, do czego nie został zaprojektowany, prawdopodobnie będę musiał przejść do znacznie wyższej specyfikacji. niż w przeciwnym razie.
Brak scentralizowanej zapory
Ponieważ skaczę przez obręcze, być może nie jest to warte wysiłku. Zawsze było miło mieć, a czasem zaletą dla klientów, którzy chcą zapory „sprzętowej”.
Wydaje się jednak, że posiadanie scentralizowanej zapory ogniowej dla „całej” sieci jest niemożliwe. Zastanawiam się zatem, w jaki sposób więksi dostawcy usług internetowych mogą oferować sprzętowe rozwiązania zapory ogniowej klientom posiadającym serwery dedykowane, skoro mają setki, a nawet tysiące hostów?
Czy ktoś może wymyślić sposób rozwiązania tego problemu? Albo coś, za czym całkowicie tęskniłem, albo odmiana jednego z powyższych pomysłów?
AKTUALIZACJA 16.06.2014:
Opierając się na sugestii @ Rona, natknąłem się na ten artykuł, który całkiem dobrze wyjaśnia problem, przed którym stoję, i dobry sposób na rozwiązanie problemu.
O ile nie ma innych sugestii, powiedziałbym, że jest to problem związany z rekomendacją produktu, więc przypuszczam, że to już koniec.
http://it20.info/2011/03/the-93-000-firewall-rules-problem-and-why-cloud-is-not-just-orchestration/
Odpowiedzi:
Wybrałbym jedną z dwóch opcji:
Indywidualne wirtualne zapory najemcy
Plusy:
Cons:
Duża obudowa / klaster zapory ogniowej z instancją routingu / kontekstem dla każdego najemcy
Wdróż dużą centralną zaporę ogniową (klaster) zwisającą z boku rdzenia i użyj wewnętrznego i zewnętrznego wystąpienia routingu, aby skierować ruch do niego iz powrotem (np. Domyślna brama na Wewnętrzna instancja to zapora, domyślna brama na zapora ogniowa to twoja zewnętrzna instancja w rdzeniu, a domyślną dla zewnętrznej instancji są twoje granice.
Plusy:
Cons:
źródło
Jakie przełączniki podstawowe używasz? Zasady są zwykle wykonywane w warstwie dystrybucyjnej, jeśli wybierasz zwinięty projekt rdzenia, rdzeń powinien być w stanie obsłużyć twoje wymagania. Lubisz też stanową inspekcję, czy po prostu acls. Jeśli masz jakieś wymagania, których musisz przestrzegać, acls może nie wystarczyć.
Osobiście wybrałbym zaporę ogniową, być może poszukaj takiej, która może być skupiona w klastrze, abyś mógł utworzyć klaster razem i utrzymywać centralnie zarządzaną bazę reguł, taką jak zapora ogniowa.
źródło