Ich habe immer alles nach Dokumentation zum jeweiligen Zeitpunkt umgesetzt…allerdings ist meine 7.2 eine sehr alte upgedatete 6…ich habe keine Ahnung mehr wann ich was wie eingerichtet habe. Subnetting habe ich seit es geht und das damals nach deiner Anleitung für den Cisco umgesetzt. Die Konfiguration des Cisco ist immer noch so wie zu diesem Zeitpunkt. Wenn also die Defaultroute jetzt der L3 sein soll, dann müssen halt auch die Routen auf dem Cisco neu gemacht werden.
Da da draußen viele alte Installationen mit dieser Konfiguration unterwegs sind wird es wahrscheinlich auch bei allen knallen…ein System, was so wächst wie unseres ist balt an vielen Ecken nicht immer up to date…da fehlt halt häufig eine Notiz, das dieses oder jemes jetzt anders konfiguriert werden muss…nicht alle (auch ich) lesen immer alles mit…
Ist doch nicht persönlich, sry wenn das so rüberkommt. Mich wundert es nur, dass ihr Systeme habt, auf denen die Firewall das Subnetrouting übernimmt, wo wir doch immer gepredigt haben, das muss der L3-Switch machen, da er das in Hardware macht und dementsprechend performanter ist. Die Firewall macht das Routing in Software und kann daher zum Flaschenhals werden.
Ich predige das selber Ich habe ehrlich gesagt noch nie in die Netplanconfig rein geschaut…wann der Eintrag da bei der Installatiaon vor zig Jahren gelandet ist habe ich keine Ahnung…ich ging immer davon aus, dass der L3 Router das Defaultgateway des Servers ist…
Shit happens.
Wahrscheinlich ist der L3-Switch auch so konfiguriert, dass er das Routing übernehmen kann und du musst im Idealfall nur die GW-IPs in subnets.csv ändern. Ist halt auch in Bezug auf die Sicherheit problematisch, wenn der gesamte LAN-Traffic über die FW geroutet wird.
Bzgl. der netplan-Konfiguration: Das muss ich nochmal gründlich durchtesten, allerdings nur auf einem System mit L3-Switch als GW.
Die alte Konfiguration funktioniert ja.
Nur noch eine Anmerkung. Ich bin mir sehr sicher, dass bei der überwiegenden Mehrheit derjenigen, die Subgenettet haben das Defaultgateway die FW ist. Das ergibt sich einfach aus der Installation. Zuerst macht man eine Grundinstallation ohne Subnetting, da wird die FW als Gateway in die Netplanconf eingetragen. Wenn man jetzt nach Dokumentation Subnets einrichtet, werden zwar die Routen angelegt, das Defaultgateway bleibt aber die FW, weil die Config durch linuxmuster-import-subnets da nicht angepasst wird. Irgendwie solltest du das berücksichtigen (Warnung / Abfrage o.ä.), damit nicht bei allen, die diese Config haben das Netz kaputt geht. Der Effekt ist wirklich böse, weil sich still und leise die FW so langsam verabschiedet und dann wirklich nichts mehr geht.
Mir ist aber einfach nicht klar, warum diese Konsequenzen eintreten!? Ich bilde mir ein, mein L3 ist schon richtig konfiguriert und auch alle Gateways der Subnetze sind richtig eingetragen. Mir ist überhaupt nicht klar, was da wo schief läuft…nach der Änderung auf den L3 als Gateway funktioniert ja auch alles ohne Probleme, bis dann eben langsam sich das Netz Stück für Stück verabschiedet. Meine L3 Konfiguration ist genau wie hier beschrieben. Meine subents.conf sieht so aus:
Da ist nichts falsch. Die entsprechende /etc/netplan/01-netcfg.yaml sollte so aussehen:
network:
ethernets:
eth0:
addresses:
- 10.16.1.1/24
dhcp4: false
dhcp6: false
gateway4: 10.16.1.254
nameservers:
addresses:
- 10.16.1.1
- 10.16.1.254
search:
- wbs-gp.de
routes:
- to: 10.16.1.0/24
via: 10.16.1.253
- to: 10.30.10.0/24
via: 10.16.1.253
- to: 10.20.10.0/24
via: 10.16.1.253
- to: 10.20.20.0/24
via: 10.16.1.253
- to: 10.20.30.0/24
via: 10.16.1.253
- to: 10.20.29.0/24
via: 10.16.1.253
- to: 10.20.41.0/24
via: 10.16.1.253
- to: 10.20.40.0/24
via: 10.16.1.253
- to: 10.20.103.0/24
via: 10.16.1.253
- to: 10.20.104.0/24
via: 10.16.1.253
- to: 10.20.105.0/24
via: 10.16.1.253
- to: 10.20.99.0/24
via: 10.16.1.253
version: 2
Das Default-GW ist die FW. In die Subnetze wird über den L3-Switch geroutet, alles andere über die FW. Also alles gut. Ich fürchte, das Ganze war ein Missvertändnis.
In der neuen Version der 01-netcfg.yaml müsste es so aussehen:
network:
ethernets:
eth0:
addresses:
- 10.16.1.1/24
dhcp4: false
dhcp6: false
nameservers:
addresses:
- 10.16.1.1
- 10.16.1.254
search:
- wbs-gp.de
routes:
- to: default
via: 10.16.1.254
- to: 10.16.1.0/24
via: 10.16.1.253
- to: 10.30.10.0/24
via: 10.16.1.253
- to: 10.20.10.0/24
via: 10.16.1.253
- to: 10.20.20.0/24
via: 10.16.1.253
- to: 10.20.30.0/24
via: 10.16.1.253
- to: 10.20.29.0/24
via: 10.16.1.253
- to: 10.20.41.0/24
via: 10.16.1.253
- to: 10.20.40.0/24
via: 10.16.1.253
- to: 10.20.103.0/24
via: 10.16.1.253
- to: 10.20.104.0/24
via: 10.16.1.253
- to: 10.20.105.0/24
via: 10.16.1.253
- to: 10.20.99.0/24
via: 10.16.1.253
version: 2
perfekt, dann bin ich doch nicht zu blöd. Genau deine neue Variante habe ich oben als Vorschlag beschrieben ;-).
Die neue Variante trage ich morgen mal ein und teste, ob das so funktioniert…jetzt habe ich gute Ruhe, weil ich wenigstens weiß, wo ich drehen muss, wenn sich das Netz wieder verabschiedet. Was mir allerdings immer noch nicht klar ist: ich hatte nach dem Crash per Hand die netplanconfig wieder in den Ursprungszustand versetzt, was allerdings nicht gereicht hat. Irgendwas dabei hat auch die FW zerschossen…ich konnte das wirklich nur durch einen Restore der FW aus dem Backup beheben!?
Die neue Variante trage ich morgen mal ein und teste, ob das so
funktioniert…jetzt habe ich gute Ruhe, weil ich wenigstens weiß, wo ich
drehen muss, wenn sich das Netz wieder verabschiedet. Was mir allerdings
immer noch nicht klar ist: ich hatte nach dem Crash per Hand die
netplanconfig wieder in den Ursprungszustand versetzt, was allerdings
nicht gereicht hat. Irgendwas dabei hat auch die FW zerschossen…ich
konnte das wirklich nur durch einen Restore der FW aus dem Backup beheben!?
das hab ich mich auch gefragt: wenn wir wüßten, was dort noch ist, dann
könnten wir „gefahrloser“ testen.
Schau dir mal die GWs in der Firewall an:
System->Gateways->Einzeln
Bei mir zeigt die GW_LAN auf den L3 im Servernetz (10.16.1.253)
Und drunter sind die Routen:
System->Routen->Konfiguration
da stehen bei mir alle AUßER dem Servernetz…irgend wie logisch: sie
steht ja in dem Netz: braucht also keine Route.
Alle zeigen auf den L3 im Servernetz (also das GW_LAN)
Hallo,
ich weiß nicht genau, ob hier ein Zusammenhang besteht: Aber ich mache die selbe Beobachtung bereits seit ein paar Wochen, wie @foer
„… bis dann eben langsam sich das Netz Stück für Stück verabschiedet.“,
wenn ich linuxmuster-import-subnets (allerdings noch lmn 7.1) absetze. Komischerweise verabschiedet sich das Netz exakt zu einer „runden“ Uhrzeit (13 Uhr oder 18 Uhr), kann aber auch Zufall sein. Die OpnSense ist dann nicht mehr bedienbar und spuckt nur noch arpresolve: can't allocate llinfo for X.X.X.X on emX aus.
Ich muss dann auf den vorigen Zustand zurück und Gateway und Routen von Hand in der OpnSense eintragen.
LG Daniel
Ich habe gerade die Zeit gefunden, es erneut zu testen. Leider wird bei mir immer noch die Default-Route durch linuxmuster-import-subnets gelöscht.
Ich vermute, dass das Problem darin liegt, dass ich keinen Eintrag für ‚gateway4‘ habe, da ich die Version 7.2 direkt mit Ubuntu 22.04 installiert habe und kein Upgrade vorgenommen habe. Der Eintrag gateway4 wird bei der Installation von Ubuntu 22.04 nicht mehr verwendet.
sondern den Gateway bei routes:
routes:
- to: 0.0.0.0/0
via: 10.26.31.254
statt 0.0.0.0/0 default ändert daran auch nichts.
routes:
- to: default
via: 10.26.31.254
root@server:~# dpkg -l | grep linuxmuster
ii linuxmuster-base7 7.2.0-rc9 all linuxmuster.net configuration scripts
ii linuxmuster-linbo-gui7 7.2.2 all Linuxmuster Linbo GUI
ii linuxmuster-linbo7 4.1.33-0 all linuxmuster-linbo7
ii linuxmuster-prepare 7.2.5-0 all linuxmuster.net pre setup configuration scripts
ii linuxmuster-webui7 7.2.18 all Next generation web-based management tool for linuxmuster.net v7.x
Ich denke, dass man bei einer Beta-Version immer vorsichtig sein sollte. Allerdings habe ich in den letzten beiden Tagen eine Schule mit Version 7.2 in Betrieb genommen und konnte keine größeren Probleme feststellen – abgesehen davon, dass die Default-Route gelöscht wird.
danke für die Rückmeldung. Hier funktioniert es auch. Ich werde das so umsetzen, dass linuxmuster-import-subnets das umstellt, wenn der gateway4-Eintrag noch vorhanden ist.
ich habe gerade frisch von 7.1 auf 7.2 upgegraded (inkl. 18.04 auf 22.04) , bis zum finalen dist-upgrade nach Eintragen der 7.1- und 7.2-Repositories hat alles problemlos funktioniert, dann hagelte es allerdings Fehlermeldungen, die mit einem fehlenden Kontakt zu Samba4 begannen.
Ein systemctl status samba-ad-dc.service brachte eine ausnahmsweise erhellende Fehlermeldung zu Tage:
invalid permissions on directory ‚/var/lib/samba/ntp_signd‘ : has 0640 should be 0750
Eine Änderung gemäß dieser Anweisung und Samba ließ sich starten. Anschließend lief auch das dist-upgrade erfolgreich durch, Server-Neustart und ein Login als Domänenuser am Client funktioniert, Schulkonsole läuft, mehr teste ich nächste Woche, sieht aber gut aus.
added netplan gateway fix to linuxmuster-import-subnets (a206eac).
Die netplan-Konfiguration wird bei einem Aufruf von linuxmuster-import-subnets aktualisiert (gateway4 wird durch das routes-Statement ersetzt).
linuxmuster-prepare verwendet jetzt eine aktualisierte Vorlage.
bei einer Neuinstallation von 7.2(also kein Upgrade von 7.1) wird der Dropbear SSH-Client in Linbo nicht gestartet. Grund ist wahrscheinlich dass die SSH-Keys nicht vorhanden sind.
Linbo meldet das auch bei der (Re-)Installation:
cp: cannot stat '/etc/linuxmuster/linbo/dropbear_*_host_key': No such file or directory
Danke für Deine schnelle Rückmeldung!
Ja, ich habe nachgesehen, die 7.1 Repos sind drinnen. Es sieht so aus, als ob es linuxmuster-linbo-common7 auch in 7.1 gar nicht mehr gibt bzw. es nur ein Überbleibsel ist. Evtl. müsste man das also in Linbo einbauen, daß die Keys generiert werden, wenn diese nicht vorhanden sind.
Ich habe nun rausgefunden wie man das macht. Da ich nicht weiß, welcher der beiden Keys verwendet wird, habe ich beide generiert:
