Netzwerkrestrukturierungsmethode für Double-NAT-Netzwerk

Aufgrund einer Reihe von schlechten Entscheidungen zum Netzwerkdesign, die (meistens) vor vielen Jahren getroffen wurden, um hier und da ein paar Dollar zu sparen, habe ich ein Netzwerk, das entschieden suboptimal aufgebaut ist. Ich suche nach Vorschlägen, um diese unangenehme Situation zu verbessern.

Wir sind gemeinnützig mit einer Linux-basierten IT-Abteilung und einem begrenzten Budget. (Hinweis: Keines der von uns ausgeführten Windows-Geräte funktioniert mit dem Internet, und wir haben keine Windows-Administratoren im Personal.)

Wichtige Punkte:

• Wir haben ein Hauptbüro und ungefähr 12 entfernte Standorte, die ihre Subnetze mit physisch getrennten Switches im Wesentlichen verdoppeln. (Kein VLANing und eingeschränkte Möglichkeiten mit aktuellen Switches)
• Diese Standorte verfügen über ein "DMZ" -Subnetz, das an jedem Standort in einem identisch zugewiesenen 10.0.0 / 24-Subnetz NAT-verknüpft ist. Diese Subnetze können an keinem anderen Ort mit DMZs kommunizieren, da wir sie nur zwischen dem Server und der angrenzenden "Firewall" weiterleiten.
• Einige dieser Standorte verfügen über mehrere ISP-Verbindungen (T1, Kabel und / oder DSLs), die wir mithilfe von IP Tools unter Linux manuell weiterleiten. Diese Firewalls werden alle im Netzwerk (10.0.0 / 24) ausgeführt und sind meistens Firewalls mit Pro-Sumer-Qualität (Linksys, Netgear usw.) oder von ISP bereitgestellte DSL-Modems.
• Das Verbinden dieser Firewalls (über einfache, nicht verwaltete Switches) besteht aus einem oder mehreren Servern, auf die öffentlich zugegriffen werden muss.
• Mit dem 10.0.0 / 24-Subnetz des Hauptbüros sind Server für E-Mail, Tele-Commuter-VPN, Remote-Office-VPN-Server und primärer Router für die internen 192.168 / 24-Subnetze verbunden. Dies muss der Zugriff von bestimmten ISP-Verbindungen sein, basierend auf dem Verkehrstyp und der Verbindungsquelle.
• Das gesamte Routing erfolgt manuell oder mit OpenVPN-Routenanweisungen
• Der Inter-Office-Verkehr wird über den OpenVPN-Dienst auf dem Hauptserver "Router" geleitet, an dem eine eigene NAT beteiligt ist.
• An Remotestandorten ist an jedem Standort nur ein Server installiert, und aus Budgetgründen können sich nicht mehrere Server leisten. Diese Server sind alle LTSP-Server mit mehreren 5-20 Terminals.
• Die Subnetze 192.168.2 / 24 und 192.168.3 / 24 befinden sich meistens, aber NICHT vollständig auf Cisco 2960-Switches, die VLAN ausführen können. Der Rest sind DLink DGS-1248-Switches, denen ich nicht sicher genug vertraue, um sie mit VLANs zu verwenden. Es gibt auch einige interne Bedenken hinsichtlich VLANs, da nur die leitenden Netzwerkmitarbeiter verstehen, wie dies funktioniert.

Der gesamte reguläre Internetverkehr wird über den CentOS 5-Routerserver geleitet, der wiederum die 192.168 / 24-Subnetze gemäß den manuell konfigurierten Routing-Regeln, mit denen der ausgehende Datenverkehr basierend auf der richtigen Internetverbindung auf die richtige Internetverbindung verweist, NATs Routing-Anweisungen '-host'.

Ich möchte dies vereinfachen und All Of The Things für die ESXi-Virtualisierung bereitstellen, einschließlich dieser öffentlich zugänglichen Dienste. Gibt es eine kostenlose oder kostengünstige Lösung, die das Double-NAT beseitigt und ein wenig Vernunft in diesem Chaos wiederherstellt, damit mein zukünftiger Ersatz mich nicht jagt?

Grunddiagramm für das Hauptbüro:

Das sind meine Ziele:

• Öffentliche Server mit Schnittstellen in diesem mittleren 10.0.0 / 24-Netzwerk, die auf ESXi-Servern in das Subnetz 192.168.2 / 24 verschoben werden sollen.
• Befreien Sie sich von der doppelten NAT und nutzen Sie unser gesamtes Netzwerk in einem einzigen Subnetz. Mein Verständnis ist, dass wir dies unter IPv6 sowieso tun müssen, aber ich denke, dass dieses Durcheinander im Weg steht.

1.) Bevor Sie etwas anderes tun, sollten Sie Ihren IP-Adressierungsplan korrigieren. Es ist schmerzhaft, die Nummer neu zu nummerieren, aber es ist der notwendige Schritt, um zu einer funktionsfähigen Infrastruktur zu gelangen. Legen Sie bequem große, einfach zusammenfassende Supernetzwerke für Workstations, Server, Remote-Standorte (natürlich mit eindeutigen IP-Adressen), Verwaltungsnetzwerke, Loopbacks usw. beiseite. Es gibt viel RFC1918-Speicherplatz und der Preis stimmt.

2.) Es ist schwierig, anhand des obigen Diagramms ein Gefühl dafür zu bekommen, wie L2 in Ihrem Netzwerk angeordnet ist. VLANs sind möglicherweise nicht erforderlich, wenn Sie über eine ausreichende Anzahl von Schnittstellen in Ihren verschiedenen Gateways sowie über eine ausreichende Anzahl von Switches verfügen. Sobald Sie ein Gefühl für Nummer 1 haben, kann es sinnvoll sein, die L2-Frage separat erneut zu beantworten. VLANs sind jedoch keine besonders komplexen oder neuartigen Technologien und müssen nicht so kompliziert sein. Ein gewisses Maß an Grundausbildung ist angebracht, aber zumindest die Möglichkeit, einen Standard-Switch in mehrere Gruppen von Ports (dh ohne Trunking) zu unterteilen, kann viel Geld sparen.

3.) Die DMZ-Hosts sollten wahrscheinlich in ihren eigenen L2 / L3-Netzwerken platziert und nicht mit Workstations zusammengeführt werden. Idealerweise haben Sie Ihre Grenzrouter mit einem L3-Gerät (einem anderen Satz von Routern? L3-Switch?) Verbunden, das wiederum ein Netzwerk mit Ihren nach außen gerichteten Serverschnittstellen (SMTP-Host usw.) verbindet. Diese Hosts stellen wahrscheinlich eine Verbindung zu einem bestimmten Netzwerk oder (weniger optimal) zu einem gemeinsamen Server-Subnetz her. Wenn Sie Ihre Subnetze entsprechend angeordnet haben, sollten die statischen Routen, die zum Leiten des eingehenden Verkehrs erforderlich sind, sehr einfach sein.

3a.) Versuchen Sie, die VPN-Netzwerke von anderen eingehenden Diensten zu trennen. Dies erleichtert die Sicherheitsüberwachung, Fehlerbehebung, Buchhaltung usw.

4.) Wenn Sie Ihre Internetverbindungen nicht konsolidieren und / oder ein einzelnes Subnetz über mehrere Netzbetreiber weiterleiten möchten (lesen Sie: BGP), benötigen Sie den Zwischensprung vor Ihren Grenzroutern, um eingehenden und ausgehenden Verkehr entsprechend umleiten zu können (as Ich vermute, Sie tun es im Moment. Dies scheint ein größeres Problem zu sein als das von VLAN, aber ich nehme an, es ist alles relativ.