Migration mit Subnets

Server v7 v7-Betatest
21

reicht das?
http://docs.linuxmuster.net/de/v7/systemadministration/maintenance/migration.html#dinge-die-manuell-gemacht-werden-mussen

VG, tobias

22

Hallo Tobias,

Das ist ziemlich kurz, aber es ist alles drin.

Gruß,
Mathias

23

Hallo zusammen,

das waren mir jetzt zu viele verschieden Netze, ich bin ganz vernetzt, äh verwirrt :woozy_face:

Wir haben Thomas’ Anleitung so verstanden, dass das Servernetz die anderen Subnetze eben NICHT beinhalten soll und haben dem Servernetz - da 254 IPs darin eigentlich genügen sollten (!?) - das Netz 10.0.0.0/24 und den anderen Subnetzen 10.1.0.0/24, 10.2.0.0/24 etc. verpasst.
Ist das korrekt?
Klar kann damit das dritte Oktett nicht als Raumbezeichnung verwendet werden, brauchen wir aber auch nicht.

Viele Grüße,
Jochen

24

Hallo Jochen,

das ist völlig korrekt.
Bei der Diskussion von eben ging es um einen Eintrag in die subnets.csv.
Das Servernetz mit der IP des L3-Switches als Gateway muss deswegen in der subnets.csv beinhaltet sein, da sonst der versucht werden würde, den OPNSense als Gateway für die Subnetze zu nutzen.

Gruß,
Mathias

25

Hallo Mathias,

ja, da hatten wir zuerst die OPNsense drin. Macht natürlich keinen Sinn und haben wir dann auf den L3-Switch geändert.

Viele Grüße,
Jochen

26

Nur für den Laien: Warum macht das keinen Sinn? Damit wir eben den meisten Traffic über den L3-Router abwickeln? Damit wir auf der opnsense nicht die ACLs wiederum einrichten müssen?

27

Hallo Jochen,

das scheint ja (fast) konsens zu sein, dass das das richtige Subnetting ist.
Ich habe jetzt mehrere Probleme auf einmal: ein Verständnisproblem, ein technisches Problem und das Problem (?), dass meine momentane falsche konfiguration funktioniert…

Ich wünschte, du könntest mir mal folgenden output von dir posten, das könnte mir evtl. mit den ersten zwei Problemen helfen.

server# grep -v ^# /etc/linuxmuster/subnets.csv
server# cat /etc/netplan/*
server# route -n

firewall# netstat -rn

natürlich redacted, wenn öffentliche IPs drinnen vorkommen oder ähnliches.

VIelen Dank.

28

Hallo,

das scheint ja (fast) konsens zu sein, dass das das richtige Subnetting ist.
Ich habe jetzt mehrere Probleme auf einmal: ein Verständnisproblem, ein
technisches Problem und das Problem (?), dass meine momentane falsche
konfiguration funktioniert…

um noch ein wenig mehr Verwirrung zu schaffen:
ichhabe seit mehreren Jahren ein segmentiertes Netz.
Die Anleitung von Damals hat den server in ein eigenes Subnet gesteckt:
10.16.1.0/24
Das hier ist die route von meinem (noch) laufenden alten Server:
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use
Iface
default ipfire.bz-pfinz 0.0.0.0 UG 100 0 0 eth0
localnet 10.16.1.253 255.240.0.0 UG 0 0 0 eth0
10.16.1.0 * 255.255.255.0 U 0 0 0 eth0

Dann habe ich letzte Woche migriert und dabei wurde aus meiner subnet
Datei die subnets.cvs gemacht, in der steht:

server subnet definition

10.16.0.0/12;10.16.1.253;10.16.1.100;10.16.1.200;SETUP

und ich halte diesen Eintrag für falsch: da sollte 10.16.1.0/24 stehen.
Eine Nebenwirkung ist z.B., dass mein unifi Controller (10.16.1.10) die
falsche subnet maske bekommt.
Der hat dann genau den kuddelmuddel, der bewirkt, dass es kracht:
nämlich diese route ausgabe:

root@unifi:/home/linadmin# route
Kernel-IP-Routentabelle
Ziel Router Genmask Flags Metric Ref Use
Iface
default 10.16.1.253 0.0.0.0 UG 0 0 0 ens3
10.16.0.0 * 255.240.0.0 U 0 0 0 ens3

und damit erreicht er seine devices nicht: wenn ich ein Gerät anpinge,
dann antwortet es nicht.
Also hab ich ihm von Hand seine Netzwerkkonfig gegeben: dann geht es.

Dass es, trotz falscher Netmask, auf dem server geht liegt daran, dass
für die anderen subnets eigene routen angelegt wurden.
Die Ausgabe von route am neuen Server ist:

root@server:~# routchannel 101: open failed: connect failed: Connection
refused
e
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

Aber auch hier ist, meiner Meinung nach, das routing nicht sauber.
Die 10.17.15.2 muss er nicht übre das Gateway ansprechen: nach der
routingtabelle, weil es ja in 10.16.0.0/12 enthalten ist.
Er macht es aber richtig, weil er die route weiter unten als wahr annimmt.

Für mich fühlt sich das falsch an: routen müssen eindeutig sein: wo
kommen wir den hin, wenn Computer entscheiden müssen … ? :slight_smile:

Aber: das ist nur meine Meinung: wir werden mal einen Netzwerkexperten
befragen: und dann mal sehen.

LG

Holger

29

Hallo Tobias,

Auf jeden Fall hat’s bei uns dadurch erstmal nicht funktioniert und als wir uns das Routing angeschaut haben war es so, dass der Hinweg zum Server über den L3-Switch ging, der Rückweg erst über die OPNsense und dann über den L3-Switch zum entsprechenden Subnet. Vermutlich hätte man jetzt auch was an der OPNsense drehen können, damit das funktioniert, ich hatte mir dann aber gedacht, dass das nicht so sinnvoll ist, da dadurch ja jeglicher Traffic über die OPNsense geht und das ist zumindest bei größeren Volumina wie Image-Rollouts von der Performance her eher nicht so toll, wenn sich das alles durch die OPNsense quälen muss.

Viele Grüße,
Jochen

30

Hallo Holger,

vermutlich kommt das daher, dass davon ausgegangen wird, dass das Servernetz bei der v7 10.16.0.0 ist? Du müsstest also entweder Deine Server-IP anpassen oder die Einträge in der subnet.csv auf 10.16.1… (ohne es wirklich bis in’s Detail verstanden zu haben…)

Viele Grüße,
Jochen

31

Hallo Tobias,

also bei uns ist:

server: 10.16.0.1
firewall: 10.16.0.254
L3-Switch im Server-Netz: 10.16.0.253

10.0.0.0/24;10.0.0.253;10.0.0.201;10.0.0.250;SETUP
10.1.0.0/24;10.1.0.254;10.1.0.201;10.1.0.250;;
10.2.0.0/24;10.2.0.254;10.2.0.201;10.2.0.250;;
10.3.0.0/24;10.3.0.254;10.3.0.201;10.3.0.250;;
10.4.0.0/24;10.4.0.254;10.4.0.201;10.4.0.250;;
10.5.0.0/24;10.5.0.254;10.5.0.201;10.5.0.250;;

...
addresses:
- 10.0.0.1/24
...
gateway4: 10.0.0.254
...
routes:
- to: 10.0.0.0/24
- via: 10.0.0.253
- to: 10.1.0.0/24
- via: 10.0.0.253
...

Dabei fällt mir auf, dass hier noch immer die OPNsense (10.0.0.254) als Gateway drin steht. Kann sein, dass das ein Relikt ist, das wir vergessen haben zu ändern!? Oder er nimmt die OPNsense nur dann, wenn er raus will (s. Output route -n)…???

Destination Route Genmask Flags Metric Ref Use Iface
0.0.0.0 10.0.0.254 0.0.0.0 UG 0 0 0  ens160
10.0.0.0 0.0.0.0 255.255.255.0 U 0 0 0  ens160
10.0.0.0 10.0.0.254 255.255.255.0 UG 0 0 0  ens160
10.0.0.0 10.0.0.253 255.255.255.0 UG 0 0 0  ens160
10.1.0.0 10.0.0.253 255.255.255.0 UG 0 0 0  ens160
10.2.0.0 10.0.0.253 255.255.255.0 UG 0 0 0  ens160
...

Äh, ich versteh die 3 Zeilen mit 10.0.0.0 nicht… Hat er da (noch) 3 verschiedene Gateways???

Destination Gateway Flags Netif
default 192.168.30.254 UGS em1
10.0.0.0/16 link#1 U em0
10.0.0.254 link#1 UHS lo0
10.1.0.0./24 10.0.0.253 UGS em0
...
127.0.0.1 link#4 UH lo0
192.168.30.0/24 link#2 U em1
192.168.30.2 link#2 UHS lo0
192.168.30.162 00:0c:29:ec:60:56 UHS em1

Bringt Dir das mehr als es mich verwirrt? :wink:

Viele Grüße,
Jochen