Bereich Administration Rechentechnik

Also in OPNSense kann man die Pakete in Richtungen Filtern, habe ich in der GUI für das ZKS ja auch gemacht

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.

Ah ok hab ich verstanden. Danke für die Erklärung

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.)]

https://streaming.media.ccc.de/clt25/relive/93
https://cdn.c3voc.de/relive/clt25/93/muxed.mp4