Metoda restrukturyzacji sieci dla sieci Double-NAT

Ze względu na szereg złych decyzji dotyczących projektowania sieci (głównie) podjętych wiele lat temu w celu zaoszczędzenia kilku dolarów tu i tam, mam sieć, która jest zdecydowanie nieoptymalnie zaprojektowana. Szukam sugestii, jak poprawić tę niemiłą sytuację.

Jesteśmy organizacją non-profit z działem IT opartym na systemie Linux i ograniczonym budżetem. (Uwaga: Żaden z uruchomionych przez nas urządzeń z systemem Windows nie robi nic, co komunikuje się z Internetem, ani nie mamy administratorów systemu Windows dla personelu).

Kluczowe punkty:

• Mamy główne biuro i około 12 zdalnych stron, które zasadniczo podwajają NAT swoich podsieci za pomocą fizycznie posegregowanych przełączników. (Brak sieci VLAN i ograniczona możliwość robienia tego z przełącznikami prądu)
• Lokalizacje te mają podsieć „DMZ”, które są NAT w identycznie przypisanej podsieci 10.0.0 / 24 w każdej lokalizacji. Te podsieci nie mogą komunikować się z strefami DMZ w żadnej innej lokalizacji, ponieważ nie kierujemy ich nigdzie indziej niż między serwerem a przyległą „zaporą ogniową”.
• Niektóre z tych lokalizacji mają wiele połączeń z dostawcami usług internetowych (T1, kablowe i / lub DSL), które ręcznie trasujemy za pomocą Narzędzi IP w Linuksie. Wszystkie te zapory działają w sieci (10.0.0 / 24) i są to głównie zapory typu „pro-sumer” (Linksys, Netgear itp.) Lub modemy DSL dostarczone przez ISP.
• Łączenie tych zapór ogniowych (za pomocą prostych niezarządzanych przełączników) to jeden lub więcej serwerów, które muszą być publicznie dostępne.
• Do podsieci 10.0.0 / 24 głównego biura podłączone są serwery poczty e-mail, telepracownik VPN, serwer VPN zdalnego biura, główny router do wewnętrznych podsieci 192.168 / 24. Muszą być one dostępne z określonych połączeń ISP na podstawie typu ruchu i źródła połączenia.
• Wszystkie nasze trasy są wykonywane ręcznie lub za pomocą instrukcji trasy OpenVPN
• Ruch między biurami przechodzi przez usługę OpenVPN na głównym serwerze „Router”, który ma własny NAT.
• W zdalnych lokalizacjach tylko jeden serwer jest zainstalowany w każdej lokacji i nie może sobie pozwolić na wiele serwerów z powodu ograniczeń budżetowych. Wszystkie te serwery to serwery LTSP z kilkoma 5-20 terminalami.
• Podsieci 192.168.2 / 24 i 192.168.3 / 24 są głównie, ale NIE całkowicie, przełącznikami Cisco 2960, które mogą obsługiwać VLAN. Pozostałymi są przełączniki DLink DGS-1248, których nie jestem pewien, czy ufam wystarczająco dobrze, aby używać ich z sieciami VLAN. Istnieją także pewne wewnętrzne obawy dotyczące sieci VLAN, ponieważ tylko starszy pracownik sieci rozumie, jak to działa.

Cały regularny ruch internetowy przechodzi przez serwer routera CentOS 5, który zamienia NAT podsieci 192.168 / 24 w podsieci 10.0.0.0/24 zgodnie z ręcznie skonfigurowanymi regułami routingu, których używamy do wskazywania ruchu wychodzącego do właściwego połączenia internetowego na podstawie Instrukcje routingu „-host”.

Chcę to uprościć i przygotować wszystko do wirtualizacji ESXi, w tym usługi publiczne. Czy istnieje niedrogie lub niedrogie rozwiązanie, które pozbyłoby się podwójnej translacji NAT i przywróciło odrobinę poczytalności temu bałaganowi, aby mój przyszły zamiennik mnie nie złapał?

Podstawowy schemat dla biura głównego:

Oto moje cele:

• Serwery publiczne z interfejsami w tej środkowej sieci 10.0.0 / 24, które mają zostać przeniesione do podsieci 192.168.2 / 24 na serwerach ESXi.
• Pozbądź się podwójnego NAT i zbierz całą naszą sieć w jednej podsieci. Rozumiem, że i tak musimy to zrobić pod IPv6, ale myślę, że ten bałagan stoi na przeszkodzie.

1.) Przed w zasadzie cokolwiek innego, wyprostuj swój plan adresowania IP. Ponowne numerowanie jest bolesne, ale jest to niezbędny krok do uzyskania funkcjonalnej infrastruktury. Odłóż wygodnie duże, łatwe do podsumowania supernety na stacje robocze, serwery, zdalne witryny (oczywiście z unikalnymi adresami IP), sieci zarządzania, sprzężenia zwrotne itp. Jest dużo miejsca w RFC1918, a cena jest odpowiednia.

2.) Trudno zrozumieć, jak rozłożyć L2 w sieci na podstawie powyższego schematu. Sieci VLAN mogą nie być konieczne, jeśli masz wystarczającą liczbę interfejsów w różnych bramach, a także wystarczającą liczbę przełączników. Gdy poczujesz, że jest to numer 1, sensowne może być osobne podejście do pytania L2. To powiedziawszy, sieci VLAN nie są szczególnie złożonym ani nowatorskim zestawem technologii i nie muszą być tak skomplikowane. Pewna ilość podstawowego szkolenia jest w porządku, ale przynajmniej możliwość podzielenia standardowego przełącznika na kilka grup portów (tj. Bez trunkingu) może zaoszczędzić dużo pieniędzy.

3.) Hosty DMZ powinny być prawdopodobnie umieszczone we własnych sieciach L2 / L3, a nie połączone ze stacjami roboczymi. Idealnie byłoby, gdyby routery graniczne były podłączone do urządzenia L3 (inny zestaw routerów? Przełącznik L3?), Który z kolei połączyłby sieć zawierającą zewnętrzne interfejsy serwera (host SMTP itp.). Hosty te najprawdopodobniej połączyłyby się z odrębną siecią lub (mniej optymalnie) ze wspólną podsiecią serwera. Jeśli odpowiednio rozłożyłeś podsieci, trasy statyczne wymagane do kierowania ruchu przychodzącego powinny być bardzo proste.

3a.) Staraj się oddzielać sieci VPN od innych usług przychodzących. Ułatwi to monitorowanie bezpieczeństwa, rozwiązywanie problemów, księgowość itp.

4.) Poza konsolidacją połączeń internetowych i / lub routingiem jednej podsieci przez kilku operatorów (czytaj: BGP) potrzebujesz routera pośredniego, aby routery graniczne mogły odpowiednio przekierowywać ruch przychodzący i wychodzący (jak Podejrzewam, że robisz w tej chwili). Wydaje się, że to większy ból głowy niż VLAN, ale przypuszczam, że to wszystko jest względne.