PVE Firewall scheint Ceph zu blockieren

Ingo S

Renowned Member
Oct 16, 2016
348
42
93
41
Hallo zusammen

Da wir in unserem Cluster eine DMZ betreiben wollen, möchte ich das DMZ Netz besser von den anderen Netzen, und die Hosts in der DMZ untereinander isolieren.
Dazu möchte ich die Firewall nutzen.
Ich habe Cluster weit ein allow auf alles, und Host weit ebenfalls. Bei keinem Gast ist zur Zeit das firewall feature aktiviert.

Corosync und Ceph laufen auf jeweils eigenen Netzen:
192.168.15.0/24 -> Ceph
192.168.16.0/24 -> Corosync

Code:
[OPTIONS]

policy_in: ACCEPT
enable: 0

[RULES]
IN ACCEPT
OUT ACCEPT

Sobald ich die Firewall aktiviere, wird allerdings Ceph blockiert. Nach kurzer Zeit stapeln sich die "blocked requests".
Auch wenn ich folgendes clusterweit und bei den Hosts einfüge, läuft es nicht:
Code:
OUT Ceph(ACCEPT) -source 192.168.15.0/24 -dest 192.168.15.0/24
IN Ceph(ACCEPT) -source 192.168.15.0/24 -dest 192.168.15.0/24

Corosync bleibt jedoch völlig unberührt, Clusterkommunikation wird nicht blockiert.

Übersehe ich irgendwas? Leider ist die Firewall nicht gut dokumentiert. Ich weiß auch nicht welche Regeln Vorrang vor anderen haben. Wird die Clusterweite Konfiguration von der Host Konfig und diese wiederum von der Guest Konfig überschrieben? Oder andersrum?

Wer hat Erfahrung mit sowas und kann mir da mal auf die Sprünge helfen?
Danke
 
Hi,

corosync hat eine default Regel im Heimnetzwerk.
Ceph hat so was nicht ich würde dir empfehlen das Interface wo Ceph lauft aus der Firewall heraus zu nehmen.
 
Hallo Wolfgang

Wie kann ich denn ein Interface aus der Firewall heraus nehmen?
Regeltechnisch habe ich ja bereits Host- und Clusterweit auf allen Interfaces alles erlaubt. Ich habe auch testweise einmal explizit das Ceph Netz in und out erlaubt, aber das macht keinen Unterschied.

Gibt es eigentlich irgendwo eine Beschreibung, welches LogLevel welche Meldungen im Log hinterlässt? Debug ist klar, und nolog ebenfalls, aber wenn ich jetzt nur Drop und Reject Ereignisse aber keine Accept Ereignisse sehen will, welches Log Level muss ich dann einstellen? Dazu habe ich leider nichts gefunden.
 
Wie kann ich denn ein Interface aus der Firewall heraus nehmen?
Du musst auf Node ebene alle Interfaces setzen wo die Firewall aktive sein soll aber nicht das Interface wo Ceph lauft.
Alternative kannst du auch eine "Accept" regel machen die ganz am Anfang ist aber das ist nicht so gut da es trotzdem CPU braucht.

Die log Level sind die gleichen wie bei iptable.
 
So, Schluss mit Urlaub, jetzt gehts hier weiter. :D

Du musst auf Node ebene alle Interfaces setzen wo die Firewall aktive sein soll aber nicht das Interface wo Ceph lauft.
Also auf Node Ebene finde ich weder bei den Network Interfaces, noch in der Firewall Config irgendwas um Interfaces in die Firewall rein oder raus zu nehmen:
upload_2018-10-9_8-59-4.png
upload_2018-10-9_8-53-51.png

Bin ich so blind? :eek:

Die log Level sind die gleichen wie bei iptable.
Okay, danke!
 
Ach verstehe, dann ist damit das "Interface" Feld gemeint:
upload_2018-10-9_10-8-34.png

Ich hatte das bisher so interpretiert, dass die Regel dann für dieses Interface gilt. Interfaces die keine Regeln haben, hatte ich vermutet, blockieren einfach jeden Traffic, da es keine allow Regel gibt. Das ist dann vom Prinzip her nach meinem empfinden ein bisschen missverständlich, aber ich probiere es gleich mal aus.
Danke für die Geduld.
 
Ich hatte das bisher so interpretiert, dass die Regel dann für dieses Interface gilt.
Genau alle Interfaces die du hier einträgst wird die Regeln angewandt.
Umgekehrt wenn ein Interface nicht eingetragen ist nicht.
Wenn du wie du nichts einträgst bekommen alle diese Regel.

Interfaces die keine Regeln haben, hatte ich vermutet, blockieren einfach jeden Traffic,
Das hängt von deiner Default rule ab.
 
Ach, stimmt, das ist klar.

Ich muss jetzt leider noch mal weiter bohren, irgendwie funktioniert das nämlich immer noch nicht so wie ich mir das vorstelle.
Folgendes:
  • Clusterweit habe ich eine Default Rule Accept, keine weiteren Regeln
  • Auf den Nodes habe ich eine Regel die allen Hosts auf vmbr0 erlaubt, überall hin zu kommunizieren. Die Regel ist nötig, damit die normalen Server weiterhin normal erreichbar sind. Wir haben eine Firewall Appliance und ich will in Proxmox das Regelwerk von da nicht nochmal nachbauen, das wäre nur redundant.
  • Für den abzusichernden Gast habe ich eine Regel auf net1 gebaut die alles verbietet:
    Code:
    [RULES]
    IN DROP -i net1
    OUT DROP -i net1
  • Dennoch kann ich im Netz von Interface net1 alles pingen und normal erreichen.
    • Unter Hardware ist das Häkchen bei firewall gesetzt
    • der Gast wurde einmal komplett gestoppt
    • dann gestartet
    • Der Firewall Dienst auf dem Host System läuft
    • unter Optionen ist die Firewall überall aktiviert.
Ich verstehe noch nicht so ganz was ich da falsch mache. In welcher Reihenfolge haben die Regeln Priorität? Gehen Host-regeln vor Node-, vor Cluster Regeln oder umgekehrt? Mich beschleicht das Gefühl, das die "erlaube alles" Regel die Host spezifische Drop Regel überschreibt bzw vorrang hat.
 
Schick mir mal bitte den output von.

iptables -L
 
Ich habe den Fehler gefunden. Im Datacenter war wider Erwarten Firewall auf no gesetzt. Ich hab wohl so viel hin und her probiert, das ich das übersehen habe. o_O:rolleyes:

Sorry für den Aufhebens.
Wenn nun doch alles nach Plan funktioniert, markiere ich den Thread mit [Solved]
 
Darf ich hier nochmal nachhaken? - ihr habt ja geklärt, wie einzelne Rules für bestimmte Interfaces aktiviert werden (oder, wenn leer für alle). Aber wo bzw. wie man die Firewall generell pro Node für ein Interface deaktiviert - wie oben als Lösung erwähnt - kann ich nicht herausfinden?
 
So wie ich das verstanden habe kann man die Firewall nicht generell für ein Interface deaktivieren, die Firewall greift immer für alle Interfaces. Wenn du bei einer Regel kein Interface einträgst, greift sie auf allen Interfaces.
Trägst du dort z.B. nur eth0 ein aber nicht eth1, dann wird die Regel nur auf eth0 angewandt. Auf eth1 greift dann aber die default rule und alle anderen Regeln, die kein interface oder eth1 angegeben haben.

Wenn du die Firewall für einen Node komplett deaktivieren willst, dann kannst du auf dem Node im Menü Firewall -> Options die Firewall auf "no" setzen. Dann sollte die Firewall dort komplett nicht angewendet werden.

Das ist ganz schön schwer zu beschreiben, ich hoffe das war nachvollziehbar.
Ich muss aber zugeben das ich mit der Firewall bis heute noch nicht zurecht gekommen bin. Ich habe mir eine Testumgebung aufgebaut, hatte aber bislang zu wenig Zeit um nochmal richtig einzusteigen und alles durch zu spielen.
 
Hallo!

Erstmal vielen Dank für die ausführliche Antwort!

Das habe ich soweit genauso verstanden, wie du es schilderst.
Vielleicht gibt es eine andere Lösung für mein Problem:

Ich habe ein dediziertes Ceph-Interface auf jedem Cluster-Node. Ich würde gerne dieses Interface auf jedem Node von der Firewall ausnehmen, da diese Interfaces sehr viel Traffic haben und ich dort keine Regeln benötige.

Derzeit habe ich es mit ACCEPT-Regeln für diese Interfaces gelöst, aber das benötigt IMHO unnötig Resourcen...so verstehe ich auch wolfgang:
Du musst auf Node ebene alle Interfaces setzen wo die Firewall aktive sein soll aber nicht das Interface wo Ceph lauft.
Alternative kannst du auch eine "Accept" regel machen die ganz am Anfang ist aber das ist nicht so gut da es trotzdem CPU braucht.
Dieser von wolfgang angedeutete umgekehrte Weg der Lösung scheint mir viel attraktiver...aber ev. ist die Möglichkeit Interfaces von der Firewall auf Node-Ebene auszunehmen einfach nicht mehr vorhanden?

Ich verwende v5.4-3

Danke & LG
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!