Aufgabe #2336
offen"Schulung" zur Hochverfügbarkeit (Ausfallsicherheit) für den Dienst Firewall
0%
Beschreibung
Samstag 11:00 Uhr in Chemnitz, oder Online gibts nen Vortrag, wie wir mit Linux, genau das bekommen können, was am Anfang an Anforderungen an die Firewalls im Keller gestellt wurde. Alles, was an Software benötigt wird gibts unter NixOS.
https://streaming.media.ccc.de/clt25/V3
https://chemnitzer.linux-tage.de/2025/en/programm/beitrag/306
Beispielsetup mit Ansible - komplett lauffähige Umgebung, auch in VMs machbar.
https://codeberg.org/liske/clt2025-liske-firewalls/
Die Config in den Demos lässt sich natürlich nicht direkt in Nixos kopieren, nach Anpassen der Template Dinge, können wir aber ohne Probleme unsere Bridge konfigurieren, und das bei beiden, wenn wir den VRRP-Code kopieren. Filtern auf der Bridge habe ich in der Apline VM auf dem Testserver mit nftables schon getestet, das geht von den Regeln her fast besser als unter OPNSense, weil man die Richtung der Pakete filtern kann, was bei der OPNSense mit der GUI nicht geht.
Von PaulRiegel vor 13 Tagen aktualisiert
- Thema wurde von Hochverfügbarkeit Firewalls zu "Schulung" zur Hochverfügbarkeit (Ausfallsicherheit) für den Dienst Firewall geändert
- Abgabedatum wurde auf 28.03.2025 gesetzt
- Kategorie wurde auf Betrieb Firewall gesetzt
- Zugewiesen an wurde auf Bereich Administration Rechentechnik gesetzt
- Priorität wurde von Normal zu Hoch geändert
@GoeranHeinemann - das wohl fähigste Mitglied zum Thema Netzwerk im Bereich - ist der Ansicht, dass das Vorgestellte für uns Wissen zur Realisierung des ursprünglichen (hohen) Anspruchs zur Verfügbarkeit vom (ausfallsicheren) Dienst Firewall bereitstellt.
Also alle, die beim Thema Firewall mitreden wollen, sollten mindestens der Empfehlung (Schauen vom Vortrag) nachkommen.
Von JannisWitnik vor 13 Tagen aktualisiert
Also in OPNSense kann man die Pakete in Richtungen Filtern, habe ich in der GUI für das ZKS ja auch gemacht
Von GoeranHeinemann vor 13 Tagen aktualisiert
Der unterschied zu dem ZKS ist, dass da Nat gemacht wird, das heißt, du hast extern eine IP, und intern ein Netz (aus vielen, normalerweise 255 IP Adressen) und alle internen Hosts kommen ins Internet, indem NAT-Translation gemacht wird, das heißt die Firewall leitet Pakete von einem Interface weiter auf das nächste, ändert aber die quell IP Adresse (gerne NAT-Translation googeln ,youtube, whatever, ich erkläre das sonst ausführlich zur nächsten Sitzung). Das ist der selbe Betriebsmodus, wie eine Fritzbox, oder Kabelbox zuhause tut.
Eine Bridge-Firewall, das was wir haben wollen, verhält sich wie ein fancy switch. Es sind öffentliche Adressen vor und hinter der Firewall. Eben wie der Switch in der 104, aber die öffentlichen Adressen, z.B. aktuell unser Mailserver haben nur bestimmte Ports, die von außen erreichbar sein sollen. Der "Switch" also die Firewall schaut sich die Pakete, die durchkommen an und akzeptiert nur manche nach Regeln. OPNSense, unsere produktive Hauptfirewall tut das. Die Filterregeln der WebUI können in diesem speziellen Modus nicht die Richtung der Pakete erkennen. Deshalb bist du mit einem Laptop im Büro quasi ungefiltert. Die Firewall weiß nicht, ob du davor und dahinter bist.
Da ich diesen Fakt jetzt öffentlich lesbar ins netz schreibe sollten wir das um so schneller ändern :D lasst uns da am besten zeitnah besprechen und behandeln, wenn ihr mir mehr Fragen und Unklarheiten zukommen lasst, könnte ich da vielleicht auch ein paar Sitzen und Beispiele vorbereiten, um explizit die verschiedenen Funktionsweisen der Firewalls zu erläutern.
Von JannisWitnik vor 12 Tagen aktualisiert
Ah ok hab ich verstanden. Danke für die Erklärung
Von PaulRiegel vor 12 Tagen aktualisiert
JannisWitnik schrieb (#note-4):
Ah ok hab ich verstanden. Danke für die Erklärung
:-)
Also es geht um den Dienst Firewall zwischen Server(n) [Cluster & Co] und Internet. Dabei hatten wir einmal den Stand, dass wir "ausfallsicher" 2 Geräte parallel betrieben haben, wobei ein Gerät im "Notfall" einfach übernehmen konnte.
Mit der Umstellung vom Konzept https://docs.opnsense.org/manual/how-tos/transparent_bridge.html konnte das (bisher) nicht mehr erfolgreich eingerichtet werden. (Es gibt die Behauptung, dass das auch nicht möglich wäre, was wohl auch so sein wird.)
Mit dem vorgetragenen Konzept (zu den CLT) soll das Thema erneut - nur eben mit Linux (vermutlich NixOS) - angegangen werden, sodass wir auch mit dem Ausfall eines Gerätes noch "überleben" würden. [Es ist eine Direktive, dass wir Ausfallsicherheit (von Hardware) schaffen wollen. (Daher auch der foo mit Ceph & PVE, oder mirror für ZFS für das System vom Zugangsschließsystem, und so weiter.)]