ChrisRa 42 Geschrieben 12. November 2020 Melden Teilen Geschrieben 12. November 2020 Hallo zusammen, ich stehe aktuell vor einer Herausforderung, die ich mir mithilfe von Infomaterial, Foren, Blogs, etc. nicht beantworten kann. Vielleicht habe ich auch ein Brett vor dem Kopf. Wir möchten gerne unser Netz neu strukturieren (kleinteiligere Segmentierung, etc.). Jeder Standort bekommt mehrere Subnetze. Bedeutet also: Standort 1: 10.1.0.0/24 Standort 1 Subnetz 1: 10.1.1.0/24 Standort 1 Subnetz 2: 10.1.2.0/24 etc. Standort 2: 10.2.0.0/24 Standort 2 Subnetz 1: 10.2.1.0/24 Standort 2 Subnetz 2: 10.2.2.0/24 etc. Für die VLANs würden wir dann gerne das dritte Oktett multipliziert mit 10 (also 10.2.1.0 wird VLAN10, 10.2.2.0 wird VLAN20) Wir nutzen sehr viele RED-Devices von Sophos an Außenstellen. Die 50er RED Devices unterstützen VLANs. Nun stellt sich mir die Frage, ob es ein Problem ist, dass wir an allen Standorten die selben VLAN-IDs verwenden? Ist das technisch überhaupt sinnvoll? Oder wäre es sinniger in jedem Subnetz auch eine eindeutige VLAN-ID zu verwenden? Viele Grüße! Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 12. November 2020 Melden Teilen Geschrieben 12. November 2020 Moin, Fangen wir doch erst mal vorne an: was ist das Ziel des Ganzen? Und: sollen die Firewalls das interne Routing übernehmen? Gruß, Nils Zitieren Link zu diesem Kommentar
ChrisRa 42 Geschrieben 12. November 2020 Autor Melden Teilen Geschrieben 12. November 2020 (bearbeitet) Hallo Nils, genau, die Firewalls übernehmen das interne Routing. Ziel des Ganzen ist es, dass wir an unseren Standorten das Netzwerk segmentieren können. An kleineren Standorten haben wir "nur" RED-Devices stehen. Also keine aktive Firewall / Router. Dadurch gibt es zum Beispiel Probleme, wenn wir am Remotestandort einen Server stehen haben. Der Server befindet sich zukünftig in einem anderen Subnetz als die Clients, genauso wie dann natürlich auch IoT-Geräte, IT-Management-Schnittstellen, Alarmserver usw. All diese Geräte wollen wir in einzelnen Subnetzen zusammenfassen. Diese werden am Remotestandort dann natürlich nicht nur durch das Subnetz, sondern auch mittels VLANs voneinander getrennt. Durch die Problematik, dass wir an den Remotestandorten keine Firewall stehen haben, sondern nur die RED-Devices, wollen wir das Firewall- und Routingmanagement an der in der Zentrale stehenden UTM verwalten. Durch die vielen Standorte gibt es aber jedoch mehrere IT-Management-Subnetze, IoT-Subnetze, usw. Meine Frage ist nun: Wie gehe ich nun mit den VLAN-IDs um? Muss ich für jedes IoT-Subnetz je Standort eine eigene VLAN-ID vergeben, wenn ich die durch das RED-Device tunnel, oder kann ich für das IoT-Subnetz generell immer dieselbe VLAN-ID an jedem Standort verwenden? Wenn wir an jedem Standort für jedes Subnetz eine eigenständige VLAN-ID vergeben, wären wir bei 50 Standorten á 4-11 Subnetzen im Schnitt bei ca. 350 VLAN-IDs. Das ist natürlich ein entschiedenes Designkriterium. Diese Frage bereitet mir gerade einen Knoten im Hirn. bearbeitet 12. November 2020 von ChrisRa Zitieren Link zu diesem Kommentar
Dukel 454 Geschrieben 12. November 2020 Melden Teilen Geschrieben 12. November 2020 Wie gehen die Geräte an den kleinen Standorten ins Internet bzw. bauen das VPN? Wie wäre es mit einem Gerät, welches VPN, Internet, Routing und Firewall macht. Zitieren Link zu diesem Kommentar
ChrisRa 42 Geschrieben 12. November 2020 Autor Melden Teilen Geschrieben 12. November 2020 Die Geräte gehen über den VPN-Tunnel des RED-Device am Remotestandort ins Internet. Damit dort der Proxy usw. vorgelagert werden kann. Zitieren Link zu diesem Kommentar
Dukel 454 Geschrieben 12. November 2020 Melden Teilen Geschrieben 12. November 2020 Kann das RED Device routen? Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 12. November 2020 Melden Teilen Geschrieben 12. November 2020 Moin, Und der Durchsatz der Red-Geräte reicht für den internen Traffic aus? Das wäre sehr untypisch. Gruß, Nils Zitieren Link zu diesem Kommentar
ChrisRa 42 Geschrieben 12. November 2020 Autor Melden Teilen Geschrieben 12. November 2020 Nein, die RED-Devices können nicht routen. Der Durchsatz reicht, es sind wirklich kleine Standorte. Die RED50 haben einen Durchsatz von 850 MBit/s. Am sinnvollsten wäre natürlich eine eigene Firewall je Standort. Aber da kommen wir an die Grenzen des machbaren und administrierbaren. Zitieren Link zu diesem Kommentar
NilsK 2.934 Geschrieben 12. November 2020 Melden Teilen Geschrieben 12. November 2020 Moin, dann verstehe ich nicht, was du vorhast. Wie sollen denn die Clients die Server erreichen, wenn es kein lokales Routing gibt? Und gerade an kleinen Standorten stellt sich für mich dann immer die Sinnfrage. Gruß, Nils Zitieren Link zu diesem Kommentar
ChrisRa 42 Geschrieben 12. November 2020 Autor Melden Teilen Geschrieben 12. November 2020 (bearbeitet) Okay, Server waren vielleicht ein denkbar schlechtes Beispiel. An den kleineren Standorten stehen keine Server. Nehmen wir z.B. die Managementschnittstelle von einem Accesspoint, die sich in einem anderen Subnetz als die Clients Vorort befindet. Diese möchte ich aus der Zentrale erreichen können. Das Routing übernimmt nach meinem Verständnis dann die lokale UTM. Warum sonst sollte man VLANs auf dem RED einrichten können. Ich glaube die Frage ist ziemlich RED-spezifisch. Bei je einer Firewall pro Standort wäre das klar... Dann könnte ich in jedem Standort die gleiche VLAN-ID verwenden. bearbeitet 12. November 2020 von ChrisRa Zitieren Link zu diesem Kommentar
MurdocX 949 Geschrieben 12. November 2020 Melden Teilen Geschrieben 12. November 2020 Mal anderst gedacht, ist das VLAN nur die logische Trennung der Netze vor Ort, anstatt eigene Switche verwenden zu müssen. Da die Netze durch Routing erreicht werden, wird es der RED egal sein. Kann es ihr auch, denn sie Routet und Tagged nur. Ähnlich wie du das VLAN in die Netze einbaust, habe ich das auch schon gemacht. Klingt sinnig und ist bei großen oder vielen kleinen Strukturen eine bessere Merkbarkeit. Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.