Viele Firewalls betreuen

[GaardenZwerch]

Hallo,

ich bin dabei OPNsense zu testen um >70 Firewalls zu ersetzen. Da die firewalls auf viele gemeinsame Objekte zurückgreifen (hosts, nets, ports, Regeln) wäre es interessant wenn es eine #include Funktion in config.xml gäbe, oder wenn ich Tag-Pare dort plaztieren könnte und die Blöcke dazwischen selbst austauschen könnte.

Sind euch solche (oder ähnliche Ansätze bekannt)? Wie verwaltet Ihr euren Park?


Vielen Dank im Voraus,

Frank

[JeGr]

Wenn die Firewalls viele gleiche Objekte haben, warum dann keine "gemeinsame" Grundkonfiguration erstellen und diese exportieren? Dann stehen jedem die gleichen Startobjekte etc. zur Verfügung. Includes fände ich schwer umsetzbar/handlebar, denn das bringt dann auch nichts, wenn die auseinander driften und man dann doch wieder die gleichen Include Files überall austauschen muss. Am Ende des Tages bringt langfristig IMHO nur die Umstellung auf Headless/API etwas, mit der Möglichkeit eine UI auf der gleichen Kiste laufen zu lassen oder die UI zu zentralisieren und den Durchgriff auf die Instanzen via API zu machen. Dann kann man auch von einer zentralen Stelle sowas wie Aliase, Tabellen etc. pushen und den Zirkus automatisieren

Und die API Entwicklung ist ja durchaus im Gang

[GaardenZwerch]

Hallo JeGr,

danke für Deine Antwort. Gibts Info's zur API und Headless?

Include files austauschen wäre für mich kein Ding, das liesse sich leicht skripten und verteilen...

LG,

Frank

[JeGr]

Austauschen ja, aber du musst es auch propagieren damit die Kiste es wieder neu einliest und das ist dann tricky. Daher wäre API m.E. das einzig wirklich sinnvolle.

Ansonsten geht die Reise sicher auf lange Sicht dahin: https://forum.opnsense.org/index.php?topic=6337.0
Ist ja auch bei der pfSense ein Langzeit-Ziel, nicht allein deshalb den PHP Layer loszuwerden, in dem doch einiges an Legacy / M0n0 Code etc. steckt und was man sicher moderner gestalten könnte

[GaardenZwerch]

Es sieht jedenfalls so aus als ob jede Änderung im config.xml sofort im gui sichtbar wird.
Zum Aktivieren stelle ich mir vor dass etwas wie

Code: [Select]

/etc/rc.d/pf restartdie Sache tut. Oder sehe ich das zu einfach?

[JeGr]

Das siehst du zu einfach. Die Änderungen an der Config werden geschrieben, wenn die UI das sagt und dann aktiv. Wenn du untendrunter einfach irgendwelche Konfigurationen änderst, werden die nicht aktiv und die GUI beim nächsten Speichern die wieder überschreiben. SO einfach ist es nicht, einfach von der Seite was reinzuschieben

[franco]

# configctl filter reload

[JeGr]

@franco: das würde zwar den Filter neu laden, aber ja nicht dagegen helfen, dass die UI die Änderungen an der Konfig überschreibt? Selbst wenn man manuell ein include reinfummeln würde, wäre das bei der nächsten Änderung ja wieder überschrieben?

[franco]

Das bezog sich nur auf #4: Wenn es in der config.xml ist und in der GUI angezeigt wird, dann führt der Konsolenbefehl dazu, dass die Änderungen aus der Config.xml analog dazu im System gesetzt werden.

Hätte es zitieren sollen; der Kontext war unklar.


Grüsse
Franco