Migration mit Subnets

Hallo zusammen,

die Migration von 6.2 auf 7 hat super geklappt. Vielen Dank schon mal dafür :slight_smile:

Eine Kleinigkeit ist da noch:
Bei der Migration von Subnetzen wird aus der alten /etc/linuxmuster/subnets die neue /etc/linuxmuster/subnets.csv gemacht. Dabei wird das Server-Subnet hinzugefügt:

# server subnet definition 10.16.0.0/16;10.16.1.254;10.16.1.100;10.16.1.200;SETUP

Als Gateway wird hier nicht die IP des L3-Switch, sondern der Firewall (10.16.1.254) eingetragen.

Vielleicht liegts ja auch daran, dass ich bei der Installation dem Server die IP 10.16.1.1/16 und nicht 10.16.1.1/12 gegeben habe.

Wenn nicht, sollte man einen Hinweis in der Dokumantation eintragen oder das Migrationsskript entsprechend abändern.

Viele Grüße und nochmals vielen Dank für das gelungene Migrationsskript,
Mathias

Hallo Mathias,

die Migration von 6.2 auf 7 hat super geklappt. Vielen Dank schon mal
dafür :slight_smile:

hast du erst die workstations importiert und dann das subnetting
eingeschaltet, oder andersrum?

Hast du auch die Passworthashes und die Lehrer/schülerdaten migriert?

LG

Holger

Hallo Holger,

Subnetting habe ich ganz am Schluss mit linuxmuster-import-subnets die Subnets importiert.

Gruß,
Mathias

Hi
Hat das auch schon jemand versucht die alten Netze/-masken aus V6.x zu übernehmen? Ansonsten müsste man offenbar den Layer 3 Switch gleich mit umkonfigurieren. Das würde ich mir eigentlich gerne sparen… oder wie seht ihr das??
Michael

Hi Michael,

dafür gibt es beim Setup ja extra die Option --do-it-like-baboo. Damit hast du in der lmn7 genau die selben Subnetze wie in der lmn6. Habe ich gemacht und funktioniert perfekt.

Gruß

Dominik

Hallo,

auch ich habe 10.16.1.1/12

LG

Holger

Hallo Michael,

Nur keine Panik. Was ich geschrieben habe, ist nur zur Info.
Entweder man schreibt’s in die Doku oder man erweitert das Migrationsskript.

Die Lösung ist, wenn man’s weiß ganz einfach:
In der /etc/linuxmuster/subnets.csv in der server subnet definition die firewall-Ip-Adresse durch die L3-Switch-IP-Adresse ersetzen. Bei mir sieht das dann so aus:
# server subnet definition 10.16.0.0/16;10.16.1.253;10.16.1.100;10.16.1.200;SETUP

Dann noch ein linuxmuster-import-subnets und alles ist in Ordnung. Der L3-Switch muss nicht angefasst werden :smile:

Gruß,
Mathias

Hi @baumhof, @rettich, @foer, @michael,

ich bin auch beim subnetting angekommen…

nachdem ich hier lese „man schreibt’s in die Doku“.
Ich höre raus, dass das an das Ende der Dokumentation zur Migration gehört, richtig? Immerhin ist das ein Schritt den man dann macht, wenn man in der v6 schon subnetting hatte.
ICh würde dann also, das was Mathias schreibt:

an das Ende des Kapitels http://docs.linuxmuster.net/de/v7/systemadministration/maintenance/migration.html#dinge-die-manuell-gemacht-werden-mussen packen, ok?
Oder habt ihr da was anderes im Kopf gehabt?

VG, Tobias

Hi nochmal,

verständnisfrage: das ORANGE/DMZ (172.16.17.x/24), BLAU (172.16.16.x/24) und den OpenVPN Zugang (weiß nicht mehr) von IPFire ist ja auch ein subnetting, wo allerdings der IPFire der Router ist.

WEnn nur akut mal das DMZ nehme, dann dachte ich, die Firewall=Opnsense sollte wieder der Router sein und dementsprechend habe ich

# Subnet orange
172.16.17.0/24;172.16.17.254;;;MIGRATION;

in meiner subnets.csv

ist das das richtige vorgehen (i.e. wird das funtionieren?)

VG, Tobias

p.s. warum 10.16.0.0/16 und nicht /12 ? Vermutlich, weil man die 10.17 - 10.31 gar nicht verwendet und somit den kleinsten Bereich abtrennt…

p.p.s. bei mir funktioniert das Skript linuxmuster-import-subnets leider nicht, weil ich den Port der firewall von 443 auf 444 umgebogen habe… weiß jemand, ob das konfigurabel ist?

VG, Tobias

Hallo Tobias,

Das ORANGE-Netz und das BLAU-Netz sind ja kein „Bestandteil“ des grünen Netzes. Insofern tauchen die nicht in subnetzs.csv auf.

Da der Server mit allen Subnets aus subnetzs.csv kommunizieren muss, muss er den L3-Switch als Gateway nutzen. Daher brauchen wir

# server subnet definition 
10.16.0.0/16;10.16.1.253;10.16.1.100;10.16.1.200;SETUP

Der Server ist nun mal im 10.16.0.0/16 bei 10.16.0.0/12 wären alle Netze 10.16.0.0/16 bis 10.31.0.0/16 enthalten. Wenn diese Netzwerke voneinander getrennte Netzwerke sein sollen, und das ist ja das Ziel der Segmentiereung, muss 10.16.0.0/16 verwendet werden.

Da muss ich leider passen…

Gruß,
Mathias

Hi Mathias,

ok. Verstehe ich jetzt.

ok, auch das verstehe ich halbwegs. Deswegen halbwegs, weil ich ja dem Server die IP 10.16.1.1/12 gegeben habe und damit ist er per Definition der Netzmaske in allen Subnetzen drin. Irgendwas verstehe ich eben nur halb. WEnn der Server die 10.16.1.253 als Gateway benötigt um z.B. nach 10.16.18.1 zu kommen, dann müsste ich ihm ja anderweitig den Zugang zu 10.16.18.1 versperren, also z.B. ihn gleich in sein eigenes Subnetz von 10.16.1.0/24 zu sperren, oder nicht?

Das ist jetzt vermutlich nur kleinkariertheit: Der Server war und ist schon immer (bei manchen) in 10.16.0.0/12, eben mit allen Netzen 10.16. - 10.31, siehe http://docs.linuxmuster.net/de/latest/systemadministration/install-from-scratch/preamble.html#ip-bereiche und die Segmentierung ist dann halt die Aufteilung in alle subnetze innerhalb von 10.16.0.0/12. So hab ich es jedenfalls jetzt.

VG und danke!, Tobias

Hallo Tobias,

Vorsicht!!! Nach der Segmentierung sollte der Server nicht in 10.16.0.0/12 sondern in 10.16.0.0/16 sein. Sonst passen die Netzwerke nicht mehr.
Mich wundert es, dass das vorher funktioniert hat :slight_smile:

Gruß,
Mathias

Hi MAthias,
sorry, warum, frage ich mich?
Ich kann doch 10.16.0.0/12 segmentieren wie ich will, z.B: in
10.16.1.0/24
10.16.2.0/24

10.16.255.0/24
10.17.0.0/24
10.17.1.0/24
10.17.2.0/24

usw.

oder nicht?
mir fallen nur die IP Adressen 10.16.0.1-255 ein, von denen ich nicht weiß, ob sie ein eigenes subnetz sind.

VG, Tobias

Hallo Jungs,

ok, auch das verstehe ich halbwegs. Deswegen halbwegs, weil ich ja dem
Server die IP |10.16.1.1/12| gegeben habe und damit ist er per
Definition der Netzmaske in allen Subnetzen drin. Irgendwas verstehe ich
eben nur halb. WEnn der Server die 10.16.1.253 als Gateway benötigt um
z.B. nach 10.16.18.1 zu kommen, dann müsste ich ihm ja anderweitig den
Zugang zu 10.16.18.1 versperren, also z.B. ihn gleich in sein eigenes
Subnetz von 10.16.1.0/24 zu sperren, oder nicht?

Der server ist dadurch eingesperrt, dass seine Route für alles außerhalb
von 10.16.1.x auf den L3 Router zeigt.

Hier route von meinem Server:

Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use
Iface
default firewall.bzpf.l 0.0.0.0 UG 0 0 0 eth0
10.16.0.0 0.0.0.0 255.240.0.0 U 0 0 0 eth0
10.16.0.0 10.16.1.253 255.240.0.0 UG 0 0 0 eth0
10.17.1.0 10.16.1.253 255.255.255.0 UG 0 0 0 eth0
10.17.15.0 10.16.1.253 255.255.255.0 UG 0 0 0 eth0
10.17.27.0 10.16.1.253 255.255.255.0 UG 0 0 0 eth0
10.17.61.0 10.16.1.253 255.255.255.0 UG 0 0 0 eth0
10.17.100.0 10.16.1.253 255.255.255.0 UG 0 0 0 eth0
10.17.101.0 10.16.1.253 255.255.255.0 UG 0 0 0 eth0
10.17.102.0 10.16.1.253 255.255.255.0 UG 0 0 0 eth0
10.17.103.0 10.16.1.253 255.255.255.0 UG 0 0 0 eth0
10.17.145.0 10.16.1.253 255.255.255.0 UG 0 0 0 eth0
10.17.154.0 10.16.1.253 255.255.255.0 UG 0 0 0 eth0
10.17.155.0 10.16.1.253 255.255.255.0 UG 0 0 0 eth0
10.18.126.0 10.16.1.253 255.255.255.0 UG 0 0 0 eth0
10.18.155.0 10.16.1.253 255.255.255.0 UG 0 0 0 eth0

Das wird durch das script linuxmuster-import-subnets angelegt.

Der Server ist nun mal im 10.16.0.0/16 bei 10.16.0.0/12 wären alle
Netze 10.16.0.0/16 bis 10.31.0.0/16 enthalten. Wenn diese Netzwerke
voneinander getrennte Netzwerke sein sollen, und das ist ja das Ziel
der Segmentiereung, muss 10.16.0.0/16 verwendet werden.

Das ist jetzt vermutlich nur kleinkariertheit: Der Server war und ist
schon immer (bei manchen) in 10.16.0.0/12, eben mit allen Netzen 10.16.

ich habe, da ich das schon in der lmn6 so hatte, 10.16.1.1/12

LG

Holger

Hallo Mathias,

Der Server war und ist schon immer (bei manchen) in 10.16.0.0/12,
eben mit allen Netzen 10.16. - 10.31, siehe
http://docs.linuxmuster.net/de/latest/systemadministration/install-from-scratch/preamble.html#ip-bereiche
und die Segmentierung ist dann halt die Aufteilung in alle subnetze
innerhalb von 10.16.0.0/12. So hab ich es jedenfalls jetzt.

Vorsicht!!! Nach der Segmentierung sollte der Server nicht in
10.16.0.0/12 sondern in 10.16.0.0/16 sein. Sonst passen die Netzwerke
nicht mehr.

warum?

Mich wundert es, dass das vorher funktioniert hat :slight_smile:

es funktioniert auch weiterhin…

LG

Holger

ok, das klingt für mich logisch: Auf technischer Ebene ist ihm der Zugang zu 10.16.18.1 eigentlich frei, aber die Route zwingt ihn über 10.16.1.253 zu gehen. Von mir aus. WEil ich so viel anderes am Hut habe, belasse ich es dabei… denn deine Route

überzeugt mich eigentlich nicht von oben gesagtem.
Egal.
Grüße, Tobias

Hallo Tobias,

Klar, kannst du. Du musst nur darauf achten, dass zwei unterschiedliche Netzwerke nicht ineinander enthalten sind.

10.17.0.0/16 ist aber in 10.16.0.0/12 enthalten. Das ist nicht gut!
Denn wenn der Server die IP 10.17.1.2 erreichen möchte, „denkt“ er, dass 10.17.1.2 im Netz 10.16.0.0/12 ist und versucht ihn direkt zu erreichen. Er wird also nicht den L3-Switch kontaktieren. Und dann ist’s vorbei.

10.17.0.0/16 ist nicht in 10.16.0.0/16 enthalten. 10.17.0.0/16 ist ach nicht in 10.16.0.0/24 enthalten. Beides geht.
Will der Server 10.17.1.2 erreichen, sieht er, dass 10.17.1.2 nicht in 10.16.0.0/16 liegt und kontaktiert den L3-Switch. und alles ist gut :slight_smile:

Gruß,
Mathias

HI Mathias,

ok. Jetzt verstehe ich dich: Du steckst den Server in das subnetz 10.16.0.0/16 und deine anderen Subnetze sind außerhalb davon, nämlich 10.17.0.0/16 usw. (du hast damit 10.16.0.0/12 in 16-bit große Häppchen aufgeteilt)

Ich habe wohl die ganze Zeit von etwas anderem geredet, nämlich dass das 10.16.0.0/12 in kleinere 24-bit Häppchen aufgeteilt wird… Egal wie geteilt wird, bei dir ist die Zeile:

dafür da, den Server in eines der Subnetze von 10.16.0.0/12 zu sperren.
Ich habe die Zeile interpretiert, den Server im Gesamtnetz 10.16.0.0/12 zu lassen.

Ich weiß jetzt auch, wo meine (Fehl?)interpretation der server-subnetz-zeile herkommt:


Thomas schreibt da:

und weiter unten:

Daher meine Interpretation: „Lass den Server in 10.0.0.0/16 und ergänze weitere Subnetze durch 10.0.100.0/24“ oder in meinem Fall eben „Lass den Server in 10.16.0.0/12 und ergänze weitere Subnetze durch 10.16.2.0/24 oder 10.17.1.0/24“ usw.

Wenn es so sein sollte, wie du es interpretierst, dann muss in die Doku rein, dass der Server umgesteckt werden muss in z.B. (range angepasst)

# server subnet definition
10.0.0.0/24;10.0.0.254;10.0.0.100;10.0.0.200;SETUP`

und für die mit L3-switche:

# server subnet definition
10.0.0.0/24;10.0.0.253;10.0.0.100;10.0.0.200;SETUP`

Stimmst du mir da zu?
VG, Tobias

Hallo Tobias,

Du darfst nur den

einsetzen. Dann werden die folgenden Eintragungen in /etc/netplan/01-netcfg.yaml gemacht:

root@server:~# cat /etc/netplan/01-netcfg.yaml 
network:
  ethernets:
    ens18:
      addresses:
      - 10.16.1.1/16
      dhcp4: false
      dhcp6: false
      gateway4: 10.16.1.254
      nameservers:
        addresses:
        - 10.16.1.1
        - 10.16.1.254
        search:
        - linuxmuster.lan
      routes:
      - to: 10.16.0.0/16
        via: 10.16.1.253
      - to: 10.17.0.0/16
        via: 10.16.1.253
      - to: 10.18.0.0/16
        via: 10.16.1.253
      - to: 10.19.0.0/16
        via: 10.16.1.253
      - to: 10.20.0.0/16
        via: 10.16.1.253
  version: 2

Dabei ist der Gateway für IPs außerhalb von 10...* die Firewall.

Gruß,
Mathias