13
Umstellung eines 172.16.0.0 - 16er Netzes in Segmente (Segmentierung, vlan migration): sinnvolles Vorgehen?
Hallo zusammen,
brauche mal bitte den Rat der Experten hier.
habe vor Jahren in meinem unwissentlichen Leichtsinn ein Netz (damals Class B) eingerichtet mit 172.16.0.0/16 (255.255.0.0). Ja ich weis: würg!
Über die Jahre ist es natürlich gewachsen und die Sicherheitsanforderungen sind gewachsen.
Plan ist die Segmentierung des 172.16.0.0 in diverse Subnetze (vlan basiert). Habe mich schon ziemlich in das Thema eingelesen; Mit späteren ACL etc. ist auch klar.
Infrastruktur ist entsprechend vorhanden:
- (Cisco SG300-28PP L3 Switch). Die entsprechenden VLANs sind bereits eingerichtet
- ein zweiter identischer Cisco wäre für Migrations-Zwischenschritte auch verfügbar
- Zentraler Internet-Router auf der 172.16.0.1 (L2 Router) mit DHCP Server für alle Subnetze; dieser ist momentan bei allen Netzgeräten (fix oder per DHCP) als zentrales GW eingerichtet (logisch..)
Das Netz besteht aus
- Servern/Backend-Systeme (NAS, Linux-Server mit Docker, dedizierte Systeme für Netzwerküberwachung (opennms, grafana etc.), Homeautomation, alle mit FESTEN IP-Adressen (im Bereich von 1-59 und 101-254), jeweils mit der o.g. GW Adresse
- diverse Clients (workstations, iphones, tablets etc.) im DHCP Bereich von 172.16.0.60 - 100
- IoT Devices (im 'Segment' 172.16.1.x)
- IP Cameras (im Segment 172.16.2.x)
- die diversen Docker Netzwerke krallen sich ja dann die 172.17, 18, 19 etc. aufwärts..
Bei der Frage wie ich das ganze nun am geschicktesten migriere, bzw. die Reihenfolge des switchens von der 16er auf die 24er Netmask stellt sich mir primär die Frage, wie ich das Netz ohne grösseren Ausfall(!) oder mich auszuschliessen umstelle, macht mir die Migration der Server (die ich ja alle der Reihe nach manuell anfassen muss) Kopfzerbrechen.
- Wenn der L3 Switch noch auf 172.16.0.254/16 hängt:
- die Umstellung der Clienst über DHCP geht ja in einem Rutsch.
- der Internet Router ist nicht so kritisch; den würde ich dann am Ende des Wartungsfensters 'schubsen'
Geplant ist hierbei:
- Möglichst Beibehaltung der 172.16er Struktur für das Backend, aber segmentiert (Nachtrag: Hintergrund sind die ca. 50 IOT Devices, die die 172.16.0.x IP-Adresse des zentralen MQTT-Brokers in der Firmware eingetragen haben; wenn ich den ändere, müsste ich alle devices offline nehmen und neu flashen, was zeitlich/aufwandstechnisch ein NO-GO ist)
- Clients und alles andere in separate Netze
Meine Zielstruktur sähe dann prinzipiell so aus:
- Alle Backend-Systeme im 172.16.0.0 Segment belassen, aber mit Netmask 255.255.255.0 (24) auf die VLANS gelegt
- Alle Clients in ein komplett separates A netz mit 10.0.x.0/24, auch per VLANS separiert
heisst dann z.B.
VLAN 1 (default, untagged) 172.16.0.0/24
VLAN 10 (IOT lan) 172.16.1.0/24
VLAN 20 (CAM lan) 172.16.2.0/24
VLAN 30 (AUTOMATION lan) 172.16.3.0/24
VLAN 101 (guest lan): 10.0.1.0/24
VLAN 110 (client lan): 10.0.10.0/24
VLAN 199 (test/migrations lan): 10.0.99.0/24
...
Bin für Eure zielführenden ratschläge dankbar!
LG Axel
brauche mal bitte den Rat der Experten hier.
habe vor Jahren in meinem unwissentlichen Leichtsinn ein Netz (damals Class B) eingerichtet mit 172.16.0.0/16 (255.255.0.0). Ja ich weis: würg!
Über die Jahre ist es natürlich gewachsen und die Sicherheitsanforderungen sind gewachsen.
Plan ist die Segmentierung des 172.16.0.0 in diverse Subnetze (vlan basiert). Habe mich schon ziemlich in das Thema eingelesen; Mit späteren ACL etc. ist auch klar.
Infrastruktur ist entsprechend vorhanden:
- (Cisco SG300-28PP L3 Switch). Die entsprechenden VLANs sind bereits eingerichtet
- ein zweiter identischer Cisco wäre für Migrations-Zwischenschritte auch verfügbar
- Zentraler Internet-Router auf der 172.16.0.1 (L2 Router) mit DHCP Server für alle Subnetze; dieser ist momentan bei allen Netzgeräten (fix oder per DHCP) als zentrales GW eingerichtet (logisch..)
Das Netz besteht aus
- Servern/Backend-Systeme (NAS, Linux-Server mit Docker, dedizierte Systeme für Netzwerküberwachung (opennms, grafana etc.), Homeautomation, alle mit FESTEN IP-Adressen (im Bereich von 1-59 und 101-254), jeweils mit der o.g. GW Adresse
- diverse Clients (workstations, iphones, tablets etc.) im DHCP Bereich von 172.16.0.60 - 100
- IoT Devices (im 'Segment' 172.16.1.x)
- IP Cameras (im Segment 172.16.2.x)
- die diversen Docker Netzwerke krallen sich ja dann die 172.17, 18, 19 etc. aufwärts..
Bei der Frage wie ich das ganze nun am geschicktesten migriere, bzw. die Reihenfolge des switchens von der 16er auf die 24er Netmask stellt sich mir primär die Frage, wie ich das Netz ohne grösseren Ausfall(!) oder mich auszuschliessen umstelle, macht mir die Migration der Server (die ich ja alle der Reihe nach manuell anfassen muss) Kopfzerbrechen.
- Wenn der L3 Switch noch auf 172.16.0.254/16 hängt:
- was passiert wenn ich die Server von 16er auf 24er umstelle (bei Beibehaltung der IP)? Clasht das dann im Zugriff bis ich den Router selber umgestellt habe?
- anders herum: wenn ich den Switch zuerst auf 24er umstelle (bei gleicher IP), komme ich dann noch auf die Server die ja noch mit der 16er laufen?
- die Umstellung der Clienst über DHCP geht ja in einem Rutsch.
- der Internet Router ist nicht so kritisch; den würde ich dann am Ende des Wartungsfensters 'schubsen'
Geplant ist hierbei:
- Möglichst Beibehaltung der 172.16er Struktur für das Backend, aber segmentiert (Nachtrag: Hintergrund sind die ca. 50 IOT Devices, die die 172.16.0.x IP-Adresse des zentralen MQTT-Brokers in der Firmware eingetragen haben; wenn ich den ändere, müsste ich alle devices offline nehmen und neu flashen, was zeitlich/aufwandstechnisch ein NO-GO ist)
- Clients und alles andere in separate Netze
Meine Zielstruktur sähe dann prinzipiell so aus:
- Alle Backend-Systeme im 172.16.0.0 Segment belassen, aber mit Netmask 255.255.255.0 (24) auf die VLANS gelegt
- Alle Clients in ein komplett separates A netz mit 10.0.x.0/24, auch per VLANS separiert
heisst dann z.B.
VLAN 1 (default, untagged) 172.16.0.0/24
VLAN 10 (IOT lan) 172.16.1.0/24
VLAN 20 (CAM lan) 172.16.2.0/24
VLAN 30 (AUTOMATION lan) 172.16.3.0/24
VLAN 101 (guest lan): 10.0.1.0/24
VLAN 110 (client lan): 10.0.10.0/24
VLAN 199 (test/migrations lan): 10.0.99.0/24
...
Bin für Eure zielführenden ratschläge dankbar!
LG Axel
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 544598
Url: https://administrator.de/contentid/544598
Printed on: April 19, 2024 at 10:04 o'clock
13 Comments
Latest comment
Servus!
Frage:
Was erwartest du von dieser Segmentierung?
Willst du einen zusätzlichen Security-Layer einführen - weil davon lese ich nichts...
Ich mein - nur weil du verschiedene Segmente einführst, und alles über einen gemeinsamen Router (wie auch immer der ausschaut...) gewinnst du ja keine weitere Sicherheit
Ich bin nur interessiert - nix weiter...
Gruß
Luigi
Frage:
Was erwartest du von dieser Segmentierung?
Willst du einen zusätzlichen Security-Layer einführen - weil davon lese ich nichts...
Ich mein - nur weil du verschiedene Segmente einführst, und alles über einen gemeinsamen Router (wie auch immer der ausschaut...) gewinnst du ja keine weitere Sicherheit
Ich bin nur interessiert - nix weiter...
Gruß
Luigi
Zitat von @126231:
Servus!
Frage:
Was erwartest du von dieser Segmentierung?
Willst du einen zusätzlichen Security-Layer einführen - weil davon lese ich nichts...
Ich mein - nur weil du verschiedene Segmente einführst, und alles über einen gemeinsamen Router (wie auch immer der ausschaut...) gewinnst du ja keine weitere Sicherheit
Ich bin nur interessiert - nix weiter...
Gruß
Luigi
Hallo Luigi,Servus!
Frage:
Was erwartest du von dieser Segmentierung?
Willst du einen zusätzlichen Security-Layer einführen - weil davon lese ich nichts...
Ich mein - nur weil du verschiedene Segmente einführst, und alles über einen gemeinsamen Router (wie auch immer der ausschaut...) gewinnst du ja keine weitere Sicherheit
Ich bin nur interessiert - nix weiter...
Gruß
Luigi
ja korrekt: wie ich bemerkte:
1.gestiegene Sicherheitsanforderungen->segmentierung->vlans->dedizierte ACEs (wer darf wohin?)
2. ich will durch die VLANS auch die broadcast etc. auf den Segmenten limitieren
3. Und mit dem Routing ist ja so auch nicht ganz korrekt; das Inter-Vlan Routing übernimmt ja dann der L3 switch. Der zentrale Router ist ja dann nur für die Internet-Verbindung, Firewall etc. (so wie heute auch, da er sonst nix routet in einem flachen Netzwerksegment)
Moin,
Migrier doch alles in 172.17.0...255.X/24
Dann kannst Du jeweils ein VLAN mit den 17er Netz erstellen und die Systeme gruppenweise da reinpacken, ggf mit DHCP und Reservierungen. und hast dann trotzdem für die noch nicht migrierten das alte Netz zur Verfügung..
lks
Migrier doch alles in 172.17.0...255.X/24
Dann kannst Du jeweils ein VLAN mit den 17er Netz erstellen und die Systeme gruppenweise da reinpacken, ggf mit DHCP und Reservierungen. und hast dann trotzdem für die noch nicht migrierten das alte Netz zur Verfügung..
lks
1
Die Migration ist eigentlich ganz einfach und geht im Grundo so vonstatten wie sie Kollege LKS oben schon geschildert hat.
Du erstellst auf deinem L3 Switch erstmal alle neuen VLAN und reservierst ein VLAN für dein "Altnetz" z.B. 99.
Das "Altnetz" klemmst du dann komplett so wie es ist an das VLAN und segmentierst dir die neuen VLANs als 172.17.x.0 /24er Segmente.
Dann ziehst du sukzessive alle Clients vom Altnetz in die neuen Segmente um und gut iss.
Das kannst du sogar im laufenden Betrieb ohne jegliche Unterbrechung machen.
Mit der sukzessiven Migration hast du dann auch gleich immer ein Test das diese Clients sauber im neu segmentierten Netz laufen.
Das Altnetz verschwindet dann komplett wenn alles migriert ist oder du kannst natürlich Restgeräte weiter darin betreiben und wenn es von der Adressierung passt dieses Segment dann auch in ein /24er Prefix überführen.
Das kannst du frei entscheiden.
Eigentlich ist so eine Adress Migration eine sehr einfache Übung.
Du erstellst auf deinem L3 Switch erstmal alle neuen VLAN und reservierst ein VLAN für dein "Altnetz" z.B. 99.
Das "Altnetz" klemmst du dann komplett so wie es ist an das VLAN und segmentierst dir die neuen VLANs als 172.17.x.0 /24er Segmente.
Dann ziehst du sukzessive alle Clients vom Altnetz in die neuen Segmente um und gut iss.
Das kannst du sogar im laufenden Betrieb ohne jegliche Unterbrechung machen.
Mit der sukzessiven Migration hast du dann auch gleich immer ein Test das diese Clients sauber im neu segmentierten Netz laufen.
Das Altnetz verschwindet dann komplett wenn alles migriert ist oder du kannst natürlich Restgeräte weiter darin betreiben und wenn es von der Adressierung passt dieses Segment dann auch in ein /24er Prefix überführen.
Das kannst du frei entscheiden.
Eigentlich ist so eine Adress Migration eine sehr einfache Übung.
1Solange man nicht darauf besteht, das es unterbrechungsfrei passieren soll und die alten Nummernkreise erhalten bleiben müssen.
lks
Zitat von @aqui:
Das "Altnetz" klemmst du dann komplett so wie es ist an das VLAN und segmentierst dir die neuen VLANs als 172.17.x.0 /24er Segmente.
Das "Altnetz" klemmst du dann komplett so wie es ist an das VLAN und segmentierst dir die neuen VLANs als 172.17.x.0 /24er Segmente.
Danke Dir erstmal dafür. Ja so wäre es am einfachsten.
Kopfschmerzen bereiten mir hier bei der Wahl eines '17er' Zielsegments nur die diversen existierenden Docker-netzwerke (bridges). Hier hat Docker ja auf Grund des bestehenden host Netzwerks im 172.16.0/16 Segment angefangen, die netze ab 172.17.0/16 zu vergeben.
ich denke wenn ich nun den Docker Host auf das neue 172.17er Zielnetz umziehe, wird das clashen (ohne dass ich sämtliche docker-bridges manuell umstelle was schwierig ist), oder?
Daher hatte ich mir (um das Problem zu umgehen) eher überlegt als 'Zielsegment' ein Class A zu nehmen
10.0.1.0/24 als default VLAN 1
10.0.10.0/24 (VLAN 10) als Backbone, dann hoch für die diversen Client-Netze 10.0.20.0, 10.0.30.0, ...
So hätte ich dann:
172.16.0/16 als 'Altnetz' (löst sich dann auf wie von Dir beschrieben)
172.17.0/16, 172.18.0/16, ... als Docker-Netze
10.0.x/24 als neues Ziel-Netz
Hätte das Nachteile zu dem 17er Ansatz?
Kopfschmerzen bereiten mir hier bei der Wahl...
Wenn du "intelligent" die IP Adressen in deinem /16er Netz vergeben hast also an bestimmte Gerätegruppen immer mit dediziertem 3ten Byte ist das ja dann auch kein Thema, dann kannst du sie Gruppenweise migrieren.ein Class A zu nehmen
Vergiss mal den Blödsinn mit Classes. Das ist Steinzeit und gibt es seit 27 Jahren nicht mehr:https://de.wikipedia.org/wiki/Classless_Inter-Domain_Routing
Aber wenn du damit meinst das du das 10er Netz mit 24er Prefixes unterteilen willst dann geht das natürlich fehlerlos. Dazu kannst du übrigens auch alles 172.16.0.0 /12er RFC 1918 IP Netze nehmen. Das ist rein kosmetisch was man da macht.
Dert iefere Sinn einer Segmentierung ist ja moglichst kleine Layer 2 Collision Domains zu schaffen und so die Netzwerk Performance auf einem hohen Niveau zu halten. Goldenen Netzwerker Regel ist so nicht mehr als 100 bis 150 Client pro L2 Domain.
Wenn du das einhalten kannst und sonst keinerlei andere externen Adressierungszwänge oder Vorgaben hast, ist es dann mehr oder minder eigentlich egal ob du mit z.B. 20 Endgeräten in einem /16er einem /24er oder einem /25 oder /26 arbeitest.
1Zitat von @fennsen:
Danke Dir erstmal dafür. Ja so wäre es am einfachsten.
Kopfschmerzen bereiten mir hier bei der Wahl eines '17er' Zielsegments nur die diversen existierenden Docker-netzwerke (bridges). Hier hat Docker ja auf Grund des bestehenden host Netzwerks im 172.16.0/16 Segment angefangen, die netze ab 172.17.0/16 zu vergeben.
Zitat von @aqui:
Das "Altnetz" klemmst du dann komplett so wie es ist an das VLAN und segmentierst dir die neuen VLANs als 172.17.x.0 /24er Segmente.
Das "Altnetz" klemmst du dann komplett so wie es ist an das VLAN und segmentierst dir die neuen VLANs als 172.17.x.0 /24er Segmente.
Danke Dir erstmal dafür. Ja so wäre es am einfachsten.
Kopfschmerzen bereiten mir hier bei der Wahl eines '17er' Zielsegments nur die diversen existierenden Docker-netzwerke (bridges). Hier hat Docker ja auf Grund des bestehenden host Netzwerks im 172.16.0/16 Segment angefangen, die netze ab 172.17.0/16 zu vergeben.
Dann nimm 172.18 oder 19 oder 20 oder 21 oder .... oder 31!
Was ist das Problem?
lks
Dann nimm 172.18 oder 19 oder 20 oder 21 oder .... oder 31!
Was ist das Problem?
lks
Was ist das Problem?
lks
Hallo Lks
nun, das 'Problem' ist, das jeder Docker Host mit jedem Container ein netz hochgeht.
Sprich mit 10 Conatiner habe ich dann jetzt schon 172.18 - 172.28
Selbst wenn ich also auf 172.31 gehe, clasht das dann wenn ich noch 3 Container hinzufüge.
Daher die andere Alternative mit dem 10er Netz überlegt
mit 10 Conatiner habe ich dann jetzt schon 172.18 - 172.28
Zeigt dann aber eher von wenig IP Adressierungs Know How.Sinnvoller wäre ja mit sinnvollen /24er Masken zu arbeiten.
Also 172.17.1.x bis 172.17.10.x
Deine komische Rechnung von oben ala "Selbst wenn ich also auf 172.31 gehe..." ist IP Adress technisch nicht nachzuvollziehen ?! Vermutlich machst du hier einen gehörigen Denkfehler zum Subnetting ?!
Sinnvoller wäre ja mit sinnvollen /24er Masken zu arbeiten.
Also 172.17.1.x bis 172.17.10.x
Also 172.17.1.x bis 172.17.10.x
Erstmal vielen Dank für den sicher gut gemeinten Ratschlag.
Du hast aber leider das Problem nicht verstanden:
Die beknackte /16er Masken habe nicht ICH mir ausgedacht. Es geht hier speziell um eine Migration eines sensiblen _bestehenden_ Netzes, was zum Grossteil aus Serverservices in Docker-Umgebungen auf diversen Maschinen besteht. Und nicht um eine 'wie macht man es bei einem Greenfield Approch richtig?' Ansatz.
Ergo: Die 172.17.x/16 Maske für die Bridge ist hierbei fest im Code von Docker implementiert.
Das macht Docker daher standardmässig so: beim Erzeugen der Container; sprich der erste Container kriegt dann die 172.18.x/16, der zweite die 172.19.x/16 usw.
Deine komische Rechnung von oben ala "Selbst wenn ich also auf 172.31 gehe..." ist IP Adress technisch nicht nachzuvollziehen ?! Vermutlich machst du hier einen gehörigen Denkfehler zum Subnetting ?!
ich denke Du merkst jetzt worauf das hinausläuft. Oder welchen Denkfehler meinst Du dann in dem o.g. Zusammenhang?Wenn Du Dich da einlesen willst, siehe z.B. hier
https://forums.docker.com/t/change-default-docker0-bridge-ip-address/304 ...
Zeigt dann aber eher von wenig IP Adressierungs Know How.
ich könnte jetzt antworten, das das eher von wenig Know How mit Docker auf der anderen Seite zeugt (was ich jetzt aber auch nicht unbedingt von einem Netzwerkadmin voraussetzen würde - mal angenommen das ist Dein Scope).Finde ich aber nicht zielführend sowas. M.E. ist so ein Forum dazu da Menschen zu helfen, die halt keine 'Netzwerkprofis' sind. Wenn ich alles wüsste wäre ich nicht hier und hätte die Frage gestellt.
Beste Grüße und nochmals Danke dass Du Dich meines Problems angenommen hast.
Axel
OK, das ist natürlich etwas krank von Docker. Gut, kann man sicher nicht erwarten das die zusätzlich zu Container Experten auch noch Netzwerk Experten sind...aber nundenn. Ziel eines optimierten Designs ist es ja gerade die Layer 2 Collision Domains immer klein und damit performant zu halten.
Dann belässt du es halt mit den /16er Prefixes und setzt das alte Docker Netz VLAN auf eine 172.16.0.0 /12.
Das inkludiert dann den gesamten Bereich von 172.16.0.0 bis 172.31.255.255.
Den neuen Bereich legst du dann in das 10er RFC 1918 IP Netz mit der Subnetzmaske wie du es dann final in den 10er Segmenten willst.
So hast du keinerlei Probleme dann mit der Migration und diese kann dann ebenso wie oben sukzessive Schritt für Schritt sogar im laufenden Betrieb passieren.
Dann belässt du es halt mit den /16er Prefixes und setzt das alte Docker Netz VLAN auf eine 172.16.0.0 /12.
Das inkludiert dann den gesamten Bereich von 172.16.0.0 bis 172.31.255.255.
Den neuen Bereich legst du dann in das 10er RFC 1918 IP Netz mit der Subnetzmaske wie du es dann final in den 10er Segmenten willst.
So hast du keinerlei Probleme dann mit der Migration und diese kann dann ebenso wie oben sukzessive Schritt für Schritt sogar im laufenden Betrieb passieren.
Zeigt dann aber eher von wenig IP Adressierungs Know How.
ich könnte jetzt antworten, das das eher von wenig Know How mit Docker auf der anderen Seite zeugt (was ich jetzt aber auch nicht unbedingt von einem Netzwerkadmin voraussetzen würde - mal angenommen das ist Dein Scope).https://support.zenoss.com/hc/en-us/articles/203582809-How-to-Change-the ...
Man kann Docker aber auch anweisen kleinere und andere Netze zu verwenden. İch denke, das ist wirklich zu wenig know-how mit Docker und daher schlechte Planung gewesen, einfach die defaults zu nehmen.
lks
