Moin,
Ich bin inzwischen nicht mehr wirklich mit meinem Heimnetz zufrieden und wollte das neu gestalten. Mir gehen da nämlich langsam die IPs aus und die IPs sind etwas chaotisch gewählt. Ist nur nicht ganz ohne, weil es schon etwas komplexer ist (ca 100 Geräte/Gäste, 18 Subnetze über 14 VLANs und 11 davon mit Routing, 3x virtuelle + 5x Plaste-Router, 5x unclustered PVE Hosts, 1Gbit + 10Gbit Netze, ...).
Paar Stunden Downtime sind da nicht das Problem (ist ja nur Heimnetz...) aber so wie ich mich kenne hänge ich da bestimmt Wochen dran, um alle Dienste und Firewalls auf den 100 Geräten/Gästen an die neuen Subnetze anzupassen. Solange kann ich dann hier auch nicht ohne Internet und NAS-Zugriff sein. Ich müsste es also irgendwie im fliegenden Wechsel machen, wo ich beide Netze parallel betreibe und einen Host/Gast nach dem anderen zwischen den Netzen umziehen lasse.
Das meiste läuft hier über einen 24x Gbit + 4x 10Gbit Managed Switch wo ich ja problemlos einen Port nach dem anderen anpassen könnte. Fast alles an Routing findet in zwei OPNsense VMs statt, welche über pfsync auf Software-Ebene HA betrieben werden. Hier würde ich dann wohl zwei neue OPNsense VMs aufsetzen und wo die beiden neuen VMs dann die neuen Subnetze bedienen und die beiden alten VMs die alten Subnetze. Die 4 OPNsenses können dann erst einmal parallel arbeiten und wenn ich fertig bin, kann ich die beiden alten OPNsenses löschen.
Hier bin ich jetzt aber bei Problem Nummer 1:
Alle meine PVE Hosts haben eine VLAN-unaware Linux Bridge je VLAN hinter einem Linux VLAN Interface. Das ist jetzt schon ziemlich unschön mit 14 Bridges für die 14 VLANs, ging damals aber leider nicht anders, weil ich damals noch bare metal PVE + TrueNAS Core als Hypervisor im Mischbetrieb laufen hatte und die Bridges von FreeBSD nicht mit VLAN umgehen konnten, es aber eine Anforderung von OPNsense im HA-Betrieb ist, dass da alle NICs identisch sind. Das ging also bei TrueNAS nicht anders und dann musste es bei PVE eben genau so sein.
Da inzwischen aber alle TrueNAS Cores auf PVE virtualisiert laufen könnte ich nun überall auf VLAN-aware Bridges umstellen, dass ich da nur noch eine VLAN-aware Bridge je NIC/Bond habe anstatt eine Bridge für jedes VLAN.
Wie ich das abändern muss ist mir klar, ich sehe nur gerade keinen Weg wie ich das VM für VM nacheinander abändern kann. Ich habe da Teils bis zu 40 Gäste auf einem PVE Node und mit all der Dokumentation dauert es dann doch etwas, wenn ich da alle Gäste eines Nodes am Stück auf einmal anpassen muss.
Meine Idee war da erst die alten VLAN-unaware Bridges beizubehalten und parallel die neuen VLAN-aware Bridges zu erstellen. Aber wenn ich das richtig sehe kann ich ja nicht zwei Bridges an eine NIC hängen.
Weiß da vielleicht jemand einen Weg oder geht das echt nur indem ich alles in einem Rutsch mache?
Punkt Nummer 2, wo ich mir unsicher bin, ist wie es bei der Performance aussieht:
Jetzt hat jede OPNsense VM 11x virtio NICs um zwischen 11 der 18 Subnetze routen zu können. Sobald ich auf VLAN-aware Bridges umgestellt habe könnte ich das auf 3x virtio NICs reduzieren, bei denen ich dann den "VLAN Tag" freilasse, dass da alles an tagged Paketen ungefiltert an der OPNsense ankommt und die OPNsense dann direkt mit VLANs arbeiten kann. Weiß jemand wie es da von der Performance aussieht? Ich würde auf 36 VLANs erweitern, wo zwischen 19 VLANs geroutet werden müsste, also ist die Frage ob ich 19x Virtio NICs (eine je VLAN) oder 3x Virtio NICs (eine je NIC/Bond) nutzen will. Ordentlicher und mehr Freiheit hätte ich bestimmt wenn ich nur 3x Virtio NICs nutzen würde über die alle VLANs gebündelt gehen. Aber hätten 19x virtio NICs vielleicht einen Geschwindigkeitsvorteil bzgl. Multithreaded-Workload oder so? Weil sehr viel von dem Routing direkt zwischen den Bridges stattfindet, ohne dass da die Pakete den PVE Host verlassen und die Performance der Bridges und Co ja von der CPU-Performance abhängt und nicht von der Bandbreite der NICs. Oder ist das wieder völlig egal weil es nur auf die Queues der NICs ankommt? Die OPNsense VMs haben gerade 4 vCPUs und jede virtio NIC hat Multiqueue=4. Die eine OPNsense hängt an einem LACP Layer 3+4 aus 4x 1Gbit, die anderen an LACP Layer 3+4 aus 2x Gbit.
Dritter Punkt ist, ob jemand vielleicht eine bessere Idee hat die Subnetze zu organisieren:
Nicht dass ich mir dann die ganze Arbeit mache und dann später doch feststelle, dass da etwas nicht ganz duchdacht war und ich dann doch wieder unzufrieden bin. Oder wenn ich mir die länge des Postes so angucke...ob ich da nicht viel zu kompliziert denke...
Sehr vereinfacht sieht es aktuell mit den Subnetzen etwa so aus:
Dabei haben...:
- LAN (VLAN 43) vollen Zugriff auf alle Subnetze
- DMZ (VLAN 42), DMZ2 (VLAN 47), DMZ3 (VLAN 46) und GUEST (VLAN 44) nur Zugriff aufs Internet aber nicht auf andere lokale Subnetze
- IOT (VLAN 50) und RETRO (VLAN 41) keinen Zugriff aufs Internet oder andere Subnetze
Die Gäste hängen dann teils in diversen Subnetzen mit jeweils einer eigenen Virtio NIC. Ich habe hier zwar alles gut dokumentiert und daher halbwegs einen Überblick welcher Gast mit welcher IP in welchen Subnetzen hängt, aber das Ganze ist schon etwas chaotisch. Dass 192.168.XXX.*/24 Schema, wo XXX die VLANID ist, macht es zwar etwas organisiert, aber weil ich nach DHCP IP Range nur noch 150 statische IPs pro Subnetz hatte, konnte ich mir da keine großen Lücken erlauben und jeder Gast hat einfach die nächste freie IP in dem jeweiligen Subnetz bekommen. So hat ein Host dann z.B. die IPs 192.168.43.10, 192.168.42.56 und 192.,168.49.15.
Wäre natürlich deutlich schöner, wenn der selbe Gast in jedem Subnetz die gleiche Nummer hätte wie z.B. 192.168.43.10, 192.168.42.10, 192.,168.49.10. Und wenn ein Gast in einem Subnetz keine IP braucht, dann bleibt die IP in dem Subnetz dann halt frei und wird übersprungen.
Dann würde ich gerne vom 192.168.0.0/16 in den 10.0.0.0/8 Addressbereich damit ich Luft habe und mir nicht wie jetzt die IPs ausgehen. Also anstatt 192.168.<VLANID>.*/24 dann 10.<VLANID>.*.*/16 für die Subnetze. Besonders wenn ich so viele IPs überspringe und ungenutzt lasse, damit ein Host/Gast immer die Selbe Endung in jedem Subnetz beibehält.
Dann hatte ich mir überlegt, dass ich gerne 10 hintereinderfolgende IPs pro Host in jedem Subnetz haben möchte. Weil Teils brauche ich schon mehrere IPs pro Rechner in einem Subnetz. Das kann wegen Dual-Boot sein, wo jedes OS dann seine eigene IP haben soll, ich die aber schon gerne nebeneinander haben möchte. Oder wenn ich ich wegen dem Remote-Unlocking von ZFS/LUKS dem Initramfs eine eigene IP geben will, damit mein SSH client nicht meckert, warum der Fingerprint plötzlich anders ist als der vom eigentlichen OS. Oder wenn ein Rechner noch ein BMC mit eigener IP hat. Da würde dann jeder Rechner/Gast also immer die letzte Stelle der IP-Adresse reserviert bekommen.
Auch hatte ich mir überlegt, dass ich doch IP und VMID koppeln könnte. Sagen wir ich will folgendes Schema: 10.XXX.YYY.YYZ/16
XXX wäre in dem Fall die VLANID welche von 2 bis 249 gehen kann.
YYYYY wäre die VMID welche von 2500 bis 2524 über 2600 bis 2624 über 2700 bis 2724 ... zu 24900 bis 24924 gehen kann.
Z wäre reserviert für den Gast, damit Initramfs, BMC, Dualboot etc ihre eigenen auf einander folgenen IPs haben können.
Dann hätte eine VM mit der VMID 10024 in den VLANs 43 und 45 z.B. die IPs 10.43.100.240/16 bis 10.43.100.249/16 sowie 10.45.100.240/16 bis 10.45.100.249/16.
Die nächste VM wäre dann VMID 10100 in VLAN 42 mit den IPs 10.42.101.0/16 bis 10.42.101.9/16 weil ich die 10025 auslassen würde, da das letzte Oktett ja nur bis 254 nutzbar ist und ich dann nicht bis 10.42.100.259/16 gehen kann und die VM dann keine 10 reservierten IPs hätte. Bei den Oketetten würde ich also immer nur von 0 bis 254 gehen damit die *.*.0.0/16 und *.*.255.255/16 freibleiben.
Dann würde ich die "VMIDs" gerne noch in physische Hosts, VMs und LXCs aufteilen, weil es mir das dann beim Monitoing mit Zabbix leichter machen würde, wenn ich dann z.B. das Monitoring aller LXCs über einen festen VMID-Bereich ausschließen könnte. Ich dachte da an:
Bei den VLANIDs hatte ich auch schon eine Idee, wie ich das Gruppieren könnte. Ich dachte da an:
Am Ende möchte ich meine "Zonen" wie LAN, DMZ, RETRO halt für bessere Zugangskontrolle und besseres Verteilen auf verschiedene physische NICs gerne weiter splitten.
Jetzt läuft alles an Management z.B. noch über das gleiche VLAN und die gleiche NIC auf dem auch die Dienste bereitgestellt werden. Wenn ich da also z.B. mein Pihole in der DMZ habe dann ist sowohl das Admin-webUI, SSH wie auch der DNS-Server im selben DMZ VLAN. Wenn ich da jetzt einen Client in der LAN-Zone den vollen Zugriff auf die DMZ-Zone gebe, damit der Client den DNS-Server benutzen kann, dann kommt der Client auch an das Admin-WebUI und SSH. Braucht der Client aber nicht zu können und soll er auch nicht können. Da würde ich die DMZ-Zone dann lieber in zwei VLANs/Subnetze "DMZ" und "DMZ-MNGT" aufsplitten, wo der Pihole dann eine IP in dem "DMZ" Subnetz für den DNS-Server und eine IP im "DMZ-MNGT" Subnetz für SSH und WebUI hat. Dann kann ich dem "LAN"-Subnetz z.B. den vollen Zugriff auf das "DMZ"-Subnetz geben aber nicht den Zugriff auf das "DMZ-MNGT"-Subnetz. Auf das "DMZ-MNGT" Subnetz kommen dann z.B. nur ganz wenige Rechner die eine IP im "ADMIN" Subnetz haben. Hat dann außerdem noch den Vorteil, dass ich da für Dienste und Administration getrennte NICs benutzen kann, sofern einer der PVE Hosts genügend NICs hat (das schwankt hier zwischen 1 und 7 NICs je Server). Und falls ein Host nicht genügend NICs für eine NIC-Trennung hat, dann geht das zur Not immer noch mit tagged VLAN über einen Trunk über eine gemeinsame NIC. Eigene NIC für das Management wäre aber schon sehr nett, dass da Dinge die niedrige Latenzen brauchen (wie Corosync, pfsync, keepalived, CARP, ... ) nicht durch Traffic von den anderen Diensten ausgebremst werden.
Und einfach ein gemeinsames Management VLAN für alle Zonen geht auch nicht. Das würde den Sinn der Isolation zwischen z.B. "LAN" und "DMZ" ja nichtig machen, wenn Gäste aus beiden schön per OPNsense-Firewall getrennten Zonen gleichzeitig in einem gemeinsamen Management VLAN hängen würden, wo diese dann doch an der OPNsense-Firewall vorbei direkt miteinander kommunizieren können. Da braucht dann also jede Zone ihr eigenes Management VLAN und die OPNsense routet dann halt zwischen den getrennten management VLANs und lässte z.B. alles vom "ADMIN"-VLAN ins "LAN-MNGT"-VLAN und "DMZ-MNGT"-VLAN aber nichts vom "DMZ-MNGT"-VLAN ins "ADMIN"-VLAN oder "LAN-MNGT"-VLAN.
Ähnliches beim Zugriff auf meine diversen NAS oder PBS. Da will ich das der Traffic nach Möglichkeit über die 10Gbit NIC mit 9000 MTU geht und nicht über die Gbit NIC mit 1500 MTU die für die Services benutzt wird. Dass da ein großes Backup oder Datei-Transfer nicht Services für alle anderen Clients ausbremst. Da muss dann also auch wieder jede Zone ihr eigenes VLAN zum NAS oder PBS haben und nicht ein gemeinsames VLAN, dass da die Isolation der Zonen nicht umgangen wird. Und ich will den Zugriff der verschiedenen Subnetze auf die NAS/PBS auch nach Möglichkeit nicht über den Router laufen lassen, dass das nicht von 10Gbit auf 1Gbit gedrosselt wird und alles andere mit ausbremst, wenn die OPNsense ausgelastet ist.
Und dann braucht fast jeder Gast Zugang zum PBS/Veeam/Rsync/Syncthing für Datei-Backups, sollte also Zugang zu einem getrennten Backup-VLAN je Zone haben.
Aber nicht jeder Gast muss an jedes NAS kommen. Ein Pihole muss nicht auf meine zentrale Fotosammlung zugreifen, braucht dann also auch keine IP im NAS-Subnetz. Die SMB-Shares sind natürlich über ACL und IP-Range-Whitelisting geschützt aber ja trotzdem besser, wenn ein Gast erst garnicht Zugang zum NAS hat, wenn es nicht nötig ist.
Die neuen VLANs würde ich mir dann so vorstellen:
Ich bin inzwischen nicht mehr wirklich mit meinem Heimnetz zufrieden und wollte das neu gestalten. Mir gehen da nämlich langsam die IPs aus und die IPs sind etwas chaotisch gewählt. Ist nur nicht ganz ohne, weil es schon etwas komplexer ist (ca 100 Geräte/Gäste, 18 Subnetze über 14 VLANs und 11 davon mit Routing, 3x virtuelle + 5x Plaste-Router, 5x unclustered PVE Hosts, 1Gbit + 10Gbit Netze, ...).
Paar Stunden Downtime sind da nicht das Problem (ist ja nur Heimnetz...) aber so wie ich mich kenne hänge ich da bestimmt Wochen dran, um alle Dienste und Firewalls auf den 100 Geräten/Gästen an die neuen Subnetze anzupassen. Solange kann ich dann hier auch nicht ohne Internet und NAS-Zugriff sein. Ich müsste es also irgendwie im fliegenden Wechsel machen, wo ich beide Netze parallel betreibe und einen Host/Gast nach dem anderen zwischen den Netzen umziehen lasse.
Das meiste läuft hier über einen 24x Gbit + 4x 10Gbit Managed Switch wo ich ja problemlos einen Port nach dem anderen anpassen könnte. Fast alles an Routing findet in zwei OPNsense VMs statt, welche über pfsync auf Software-Ebene HA betrieben werden. Hier würde ich dann wohl zwei neue OPNsense VMs aufsetzen und wo die beiden neuen VMs dann die neuen Subnetze bedienen und die beiden alten VMs die alten Subnetze. Die 4 OPNsenses können dann erst einmal parallel arbeiten und wenn ich fertig bin, kann ich die beiden alten OPNsenses löschen.
Hier bin ich jetzt aber bei Problem Nummer 1:
Alle meine PVE Hosts haben eine VLAN-unaware Linux Bridge je VLAN hinter einem Linux VLAN Interface. Das ist jetzt schon ziemlich unschön mit 14 Bridges für die 14 VLANs, ging damals aber leider nicht anders, weil ich damals noch bare metal PVE + TrueNAS Core als Hypervisor im Mischbetrieb laufen hatte und die Bridges von FreeBSD nicht mit VLAN umgehen konnten, es aber eine Anforderung von OPNsense im HA-Betrieb ist, dass da alle NICs identisch sind. Das ging also bei TrueNAS nicht anders und dann musste es bei PVE eben genau so sein.
Da inzwischen aber alle TrueNAS Cores auf PVE virtualisiert laufen könnte ich nun überall auf VLAN-aware Bridges umstellen, dass ich da nur noch eine VLAN-aware Bridge je NIC/Bond habe anstatt eine Bridge für jedes VLAN.
Wie ich das abändern muss ist mir klar, ich sehe nur gerade keinen Weg wie ich das VM für VM nacheinander abändern kann. Ich habe da Teils bis zu 40 Gäste auf einem PVE Node und mit all der Dokumentation dauert es dann doch etwas, wenn ich da alle Gäste eines Nodes am Stück auf einmal anpassen muss.
Meine Idee war da erst die alten VLAN-unaware Bridges beizubehalten und parallel die neuen VLAN-aware Bridges zu erstellen. Aber wenn ich das richtig sehe kann ich ja nicht zwei Bridges an eine NIC hängen.
Weiß da vielleicht jemand einen Weg oder geht das echt nur indem ich alles in einem Rutsch mache?
Punkt Nummer 2, wo ich mir unsicher bin, ist wie es bei der Performance aussieht:
Jetzt hat jede OPNsense VM 11x virtio NICs um zwischen 11 der 18 Subnetze routen zu können. Sobald ich auf VLAN-aware Bridges umgestellt habe könnte ich das auf 3x virtio NICs reduzieren, bei denen ich dann den "VLAN Tag" freilasse, dass da alles an tagged Paketen ungefiltert an der OPNsense ankommt und die OPNsense dann direkt mit VLANs arbeiten kann. Weiß jemand wie es da von der Performance aussieht? Ich würde auf 36 VLANs erweitern, wo zwischen 19 VLANs geroutet werden müsste, also ist die Frage ob ich 19x Virtio NICs (eine je VLAN) oder 3x Virtio NICs (eine je NIC/Bond) nutzen will. Ordentlicher und mehr Freiheit hätte ich bestimmt wenn ich nur 3x Virtio NICs nutzen würde über die alle VLANs gebündelt gehen. Aber hätten 19x virtio NICs vielleicht einen Geschwindigkeitsvorteil bzgl. Multithreaded-Workload oder so? Weil sehr viel von dem Routing direkt zwischen den Bridges stattfindet, ohne dass da die Pakete den PVE Host verlassen und die Performance der Bridges und Co ja von der CPU-Performance abhängt und nicht von der Bandbreite der NICs. Oder ist das wieder völlig egal weil es nur auf die Queues der NICs ankommt? Die OPNsense VMs haben gerade 4 vCPUs und jede virtio NIC hat Multiqueue=4. Die eine OPNsense hängt an einem LACP Layer 3+4 aus 4x 1Gbit, die anderen an LACP Layer 3+4 aus 2x Gbit.
Dritter Punkt ist, ob jemand vielleicht eine bessere Idee hat die Subnetze zu organisieren:
Nicht dass ich mir dann die ganze Arbeit mache und dann später doch feststelle, dass da etwas nicht ganz duchdacht war und ich dann doch wieder unzufrieden bin. Oder wenn ich mir die länge des Postes so angucke...ob ich da nicht viel zu kompliziert denke...
Sehr vereinfacht sieht es aktuell mit den Subnetzen etwa so aus:
Dabei haben...:
- LAN (VLAN 43) vollen Zugriff auf alle Subnetze
- DMZ (VLAN 42), DMZ2 (VLAN 47), DMZ3 (VLAN 46) und GUEST (VLAN 44) nur Zugriff aufs Internet aber nicht auf andere lokale Subnetze
- IOT (VLAN 50) und RETRO (VLAN 41) keinen Zugriff aufs Internet oder andere Subnetze
Die Gäste hängen dann teils in diversen Subnetzen mit jeweils einer eigenen Virtio NIC. Ich habe hier zwar alles gut dokumentiert und daher halbwegs einen Überblick welcher Gast mit welcher IP in welchen Subnetzen hängt, aber das Ganze ist schon etwas chaotisch. Dass 192.168.XXX.*/24 Schema, wo XXX die VLANID ist, macht es zwar etwas organisiert, aber weil ich nach DHCP IP Range nur noch 150 statische IPs pro Subnetz hatte, konnte ich mir da keine großen Lücken erlauben und jeder Gast hat einfach die nächste freie IP in dem jeweiligen Subnetz bekommen. So hat ein Host dann z.B. die IPs 192.168.43.10, 192.168.42.56 und 192.,168.49.15.
Wäre natürlich deutlich schöner, wenn der selbe Gast in jedem Subnetz die gleiche Nummer hätte wie z.B. 192.168.43.10, 192.168.42.10, 192.,168.49.10. Und wenn ein Gast in einem Subnetz keine IP braucht, dann bleibt die IP in dem Subnetz dann halt frei und wird übersprungen.
Dann würde ich gerne vom 192.168.0.0/16 in den 10.0.0.0/8 Addressbereich damit ich Luft habe und mir nicht wie jetzt die IPs ausgehen. Also anstatt 192.168.<VLANID>.*/24 dann 10.<VLANID>.*.*/16 für die Subnetze. Besonders wenn ich so viele IPs überspringe und ungenutzt lasse, damit ein Host/Gast immer die Selbe Endung in jedem Subnetz beibehält.
Dann hatte ich mir überlegt, dass ich gerne 10 hintereinderfolgende IPs pro Host in jedem Subnetz haben möchte. Weil Teils brauche ich schon mehrere IPs pro Rechner in einem Subnetz. Das kann wegen Dual-Boot sein, wo jedes OS dann seine eigene IP haben soll, ich die aber schon gerne nebeneinander haben möchte. Oder wenn ich ich wegen dem Remote-Unlocking von ZFS/LUKS dem Initramfs eine eigene IP geben will, damit mein SSH client nicht meckert, warum der Fingerprint plötzlich anders ist als der vom eigentlichen OS. Oder wenn ein Rechner noch ein BMC mit eigener IP hat. Da würde dann jeder Rechner/Gast also immer die letzte Stelle der IP-Adresse reserviert bekommen.
Auch hatte ich mir überlegt, dass ich doch IP und VMID koppeln könnte. Sagen wir ich will folgendes Schema: 10.XXX.YYY.YYZ/16
XXX wäre in dem Fall die VLANID welche von 2 bis 249 gehen kann.
YYYYY wäre die VMID welche von 2500 bis 2524 über 2600 bis 2624 über 2700 bis 2724 ... zu 24900 bis 24924 gehen kann.
Z wäre reserviert für den Gast, damit Initramfs, BMC, Dualboot etc ihre eigenen auf einander folgenen IPs haben können.
Dann hätte eine VM mit der VMID 10024 in den VLANs 43 und 45 z.B. die IPs 10.43.100.240/16 bis 10.43.100.249/16 sowie 10.45.100.240/16 bis 10.45.100.249/16.
Die nächste VM wäre dann VMID 10100 in VLAN 42 mit den IPs 10.42.101.0/16 bis 10.42.101.9/16 weil ich die 10025 auslassen würde, da das letzte Oktett ja nur bis 254 nutzbar ist und ich dann nicht bis 10.42.100.259/16 gehen kann und die VM dann keine 10 reservierten IPs hätte. Bei den Oketetten würde ich also immer nur von 0 bis 254 gehen damit die *.*.0.0/16 und *.*.255.255/16 freibleiben.
Dann würde ich die "VMIDs" gerne noch in physische Hosts, VMs und LXCs aufteilen, weil es mir das dann beim Monitoing mit Zabbix leichter machen würde, wenn ich dann z.B. das Monitoring aller LXCs über einen festen VMID-Bereich ausschließen könnte. Ich dachte da an:
- reserviert für Spezielles wie Gateway/DNS/virtuelle IPs: "10.<VLANID>.<0-9>.<0-255>/16" außer "10.<VLANID>.0.0/16" = 2559 nutzbare IPs
- für DHCP: "10.<VLANID>.<10-24>.<0-255>/16" = 3840 DHCP Clients
- für physische Hosts: "10.<VLANID>.<25-99>.<0-24><0-9>/16" = 1875 Hosts mit je 10 reservierten IPs
- für VMs: "10.<VLANID>.<100-174>.<0-24><0-9>/16" = 1875 VMs mit je 10 reservierten IPs
- für LXCs: "10.<VLANID>.<175-249>.<0-24><0-9>/16" = 1875 LXCs mit je 10 reservierten IPs
- reserviert: "10.<VLANID>.<250-255>.<0-255>/16" außer "10.<VLANID>.255.255/16" = 1535 IPs falls mir mal was einfällt was ich damit machen soll
Bei den VLANIDs hatte ich auch schon eine Idee, wie ich das Gruppieren könnte. Ich dachte da an:
- VLANID 1: reserviert weil für untagged traffic
- VLANID 2 - 59: für einzelne ungruppierte VLANs die "/16" Subnetze haben sollen
- VLANID 60 - 249: für 10er-Gruppen an VLANs die "/16" Subnetze haben sollen. Also 60-69, 70-79, 80-89, ... sind gruppiert. Die letzte Stelle würde dann fix je nach Einsatzzweck sein.
- 0 = das Haupt-VLAN, also sozusagen die "Zone" die durch die untenstehenden zusätzlichen VLANs ergänzt wird, über Gbit-NIC
- 1 = für Managemnt über andere 1Gbit NIC für niedrige Latenz (falls ich doch mal Clustern will mit Corosync etc)
- 2 = VLAN für direkten Zugriff über 10Gbit NIC mit Jumboframes zum ersten NAS
- 3 = VLAN für direkten Zugriff über 10Gbit NIC mit Jumboframes zu PBS/Veeam/Rsync/Syncthing für Backupzwecke
- 4 = VLAN für direkten Zugriff über 10Gbit NIC mit Jumboframes zum zweiten NAS
- 5 - 9 = reserviert für zukünftige Ideen oder wenn ich weitere NAS anschaffe etc
- VLANID 250 - 999 wird nicht benutzt
- VLANID 1000 - 2535 wird für einzelne kleinere "/24" Subnetze reserviert, falls mir doch mal die VLANs zu schnell ausgehen sollten oder ich nur mal einzelne Gäste isoliert verbinden will. Z.B. die PBS VM mit der TrueNAS VM in ein eigenes VLAN/Subnetz damit PBS isoliert den Datastore auf dem NFS Share ablegen kann, ohne dass ich mich da mit Kerberus und Co rumschlagen müsste. Oder ein eigenes VLAN/Subnetz rein für die unverschlüsselte Replikation zwischen TrueNAS VMs. Die Idee ist dann den IP-Bereich "10.<250-255>.<0-255>.*/24" für 1535 kleine VLANs/Subnetze zu nutzen. "10.250.<0-255>.*/24" kann dann z.B. lokal als Subnetz über eine eigene isolierte Linux Bridge ohne VLAN benutzt werden oder alternative auch mit einer physischen NIC verbunden als VLANID 1000 - 1255. "10.251.<0-255>.*/24" dann als VLANID 1256 - 1511 usw.
- VLANID 2536 - 4095 wird nicht benutzt
Am Ende möchte ich meine "Zonen" wie LAN, DMZ, RETRO halt für bessere Zugangskontrolle und besseres Verteilen auf verschiedene physische NICs gerne weiter splitten.
Jetzt läuft alles an Management z.B. noch über das gleiche VLAN und die gleiche NIC auf dem auch die Dienste bereitgestellt werden. Wenn ich da also z.B. mein Pihole in der DMZ habe dann ist sowohl das Admin-webUI, SSH wie auch der DNS-Server im selben DMZ VLAN. Wenn ich da jetzt einen Client in der LAN-Zone den vollen Zugriff auf die DMZ-Zone gebe, damit der Client den DNS-Server benutzen kann, dann kommt der Client auch an das Admin-WebUI und SSH. Braucht der Client aber nicht zu können und soll er auch nicht können. Da würde ich die DMZ-Zone dann lieber in zwei VLANs/Subnetze "DMZ" und "DMZ-MNGT" aufsplitten, wo der Pihole dann eine IP in dem "DMZ" Subnetz für den DNS-Server und eine IP im "DMZ-MNGT" Subnetz für SSH und WebUI hat. Dann kann ich dem "LAN"-Subnetz z.B. den vollen Zugriff auf das "DMZ"-Subnetz geben aber nicht den Zugriff auf das "DMZ-MNGT"-Subnetz. Auf das "DMZ-MNGT" Subnetz kommen dann z.B. nur ganz wenige Rechner die eine IP im "ADMIN" Subnetz haben. Hat dann außerdem noch den Vorteil, dass ich da für Dienste und Administration getrennte NICs benutzen kann, sofern einer der PVE Hosts genügend NICs hat (das schwankt hier zwischen 1 und 7 NICs je Server). Und falls ein Host nicht genügend NICs für eine NIC-Trennung hat, dann geht das zur Not immer noch mit tagged VLAN über einen Trunk über eine gemeinsame NIC. Eigene NIC für das Management wäre aber schon sehr nett, dass da Dinge die niedrige Latenzen brauchen (wie Corosync, pfsync, keepalived, CARP, ... ) nicht durch Traffic von den anderen Diensten ausgebremst werden.
Und einfach ein gemeinsames Management VLAN für alle Zonen geht auch nicht. Das würde den Sinn der Isolation zwischen z.B. "LAN" und "DMZ" ja nichtig machen, wenn Gäste aus beiden schön per OPNsense-Firewall getrennten Zonen gleichzeitig in einem gemeinsamen Management VLAN hängen würden, wo diese dann doch an der OPNsense-Firewall vorbei direkt miteinander kommunizieren können. Da braucht dann also jede Zone ihr eigenes Management VLAN und die OPNsense routet dann halt zwischen den getrennten management VLANs und lässte z.B. alles vom "ADMIN"-VLAN ins "LAN-MNGT"-VLAN und "DMZ-MNGT"-VLAN aber nichts vom "DMZ-MNGT"-VLAN ins "ADMIN"-VLAN oder "LAN-MNGT"-VLAN.
Ähnliches beim Zugriff auf meine diversen NAS oder PBS. Da will ich das der Traffic nach Möglichkeit über die 10Gbit NIC mit 9000 MTU geht und nicht über die Gbit NIC mit 1500 MTU die für die Services benutzt wird. Dass da ein großes Backup oder Datei-Transfer nicht Services für alle anderen Clients ausbremst. Da muss dann also auch wieder jede Zone ihr eigenes VLAN zum NAS oder PBS haben und nicht ein gemeinsames VLAN, dass da die Isolation der Zonen nicht umgangen wird. Und ich will den Zugriff der verschiedenen Subnetze auf die NAS/PBS auch nach Möglichkeit nicht über den Router laufen lassen, dass das nicht von 10Gbit auf 1Gbit gedrosselt wird und alles andere mit ausbremst, wenn die OPNsense ausgelastet ist.
Und dann braucht fast jeder Gast Zugang zum PBS/Veeam/Rsync/Syncthing für Datei-Backups, sollte also Zugang zu einem getrennten Backup-VLAN je Zone haben.
Aber nicht jeder Gast muss an jedes NAS kommen. Ein Pihole muss nicht auf meine zentrale Fotosammlung zugreifen, braucht dann also auch keine IP im NAS-Subnetz. Die SMB-Shares sind natürlich über ACL und IP-Range-Whitelisting geschützt aber ja trotzdem besser, wenn ein Gast erst garnicht Zugang zum NAS hat, wenn es nicht nötig ist.
Die neuen VLANs würde ich mir dann so vorstellen:
