Implementierung eines Firewallcluster als Ersatz für die bestehende FW

#1 Hallo Community,

wir haben vor, unsere bestehende Firewall durch einen Firewallcluster zu ersetzen. Die bestehende Firewall ist das Gateway eines großen Firmennetzwerks, das mehrere Kunden (auch wir) in Form von VLANs nutzen.

Meine bisherigen Erfahrungen mit Firewalls beruhen auf einfachen Gateways, die als Router dienen, mit einfachen iptables-Regeln.

Bei unserem neuen Baby stellt sich mir aber gleich schon folgende Frage:
Wie schließe ich physikalisch den neuen Firewallcluster an?

Derzeitig sieht es so aus:
http://www.christian-baensch.de/vorhandene_verkabelung.gif

Die Firewall in der Zeichnung soll durch den neuen Firewallcluster ersetzt werden. Sie wird als Router, Firewall, VPN-Server eingesetzt und verwaltet die VLANs der Kunden in Form von virtuellen IP-Adressen (z.B. eth0.132) in etc/network/interfaces. Dasselbe soll, wie schon angesprochen, auch der Cluster übernehmen.
Zum Einsatz kommen folgende Pakete:
- shorewall als Firewall
- OpenVPN als VPN-Server
- heartbeat als Clustersoftware
Daneben soll noch IP-/Traffic-Accounting funktionieren...

Ich stelle mir das ungefähr so vor:
http://www.christian-baensch.de/neue_verkabelung.gif
Die Frage ist nur, ob sich das so, wie ich das gezeichnet habe, auch praktisch realisieren läßt.

Wie verhält es sich mit der VLAN-Geschichte? Ist hier noch was extra am Router/FW einzutragen?

Vielleicht habt Ihr den ein oder anderen Tipp für mich oder könnt mir sonst weiterhelfen. Bin für jeden noch so kleinen Tipp sehr dankbar.

Vielen Dank im voraus und einen schönen Tag.

Gruß, h.o.t. aka Christian

#2 Hi Christian,

Dein obersteres Bild ist leider nicht erreichbar!

Greetz Lp

#3 Hallo Laserpointa,

jetzt müsste die Grafik funktionieren...
Danke für den Hinweis!

Gruß, Christian

#4 Hi Christian,

Zitat

Die Frage ist nur, ob sich das so, wie ich das gezeichnet habe, auch praktisch realisieren läßt.

In deiner Zeichnung ist nicht alles eingezeichnet, was du beschreibst, deswegen kann man das nicht zu 100% sagen. Wenn die Konfiguration passt, dann sollte das so gehen, wie du das da eingezeichnet hast. Hängt allerdings von den Antworten auf die folgenden Fragen ab:

Ist das "ein" Switch mit 2 Modulen oder 2 gestackte Switche oder 2 Switche im redundanten Setup (stp/rstp)? Was hast du da für Hardware?

Ist das wellige Kabel auf eth1 bei den Firewalls das Crossover Kabel für Heartbeat? GBit braucht man da nicht wirklich, zudem solltest du auch den Einsatz eines Null Modem Kabels in Erwägung ziehen um eine 2. Heartbeat Kommunikationsstrecke zu haben (vermeidet Split Brains ungemein

Wie genau schaut dein VLAN Plan aus? Liegen alle VLANs auf den Core Switchen? Düsen alle VLANs durch einen physikalischen Port auf den Firewalls? Bei letzterem würde ich zumindest Internet und Intern trennen.

Zitat

Wie verhält es sich mit der VLAN-Geschichte? Ist hier noch was extra am Router/FW einzutragen?

Ja, du müsstest die tagged VLANs, so wie auf den Switchen, auch auf den Firewalls konfigurieren. Schau mal hier. Ich habe allerdings nicht wirklich Erfahrung mit VLANs bei Linux Kisten. Bis jetzt hatte ich immer genug Ports auf den Systemen

Soweit erstmal mein Senf

Viele Grüße,

Don

PS:
Beim Thema "Redundanz" reicht es nicht die Firewalls redundant aufzusetzen, folgendes solltest du auch beachten:

- redundante Hardware (RAID/doppelte Netzteile)
- Einsatz von NIC Teaming (bonding/ etherchannel)
- mind. 2 Switche
- redundante Stromversorgung (USV, 2 verschieden gespeiste Leitungen -> falls Sicherung mal fliegt
- redundante Anbindung ans Internet (Multihoming / BGP, einfach mal Provider fragen)

#5 Heartbeat als Clusterlösung.
Das beruht ja darauf (ich kenn es nur von Linux-Kisten Redundanz) dass EINE IP-Adresse genutzt wird. Geht Kiste 1 (die in Produktion ist) kaputt, wird das Interface von Kiste 2 hochgefahren - allerdings mit der SELBEN IP-Adresse die eben noch Kiste 1 hatte.

Oder ist das da anders?


Wir nutzen VRRP als Redundanzprotokoll.

#6

Zitat

Das beruht ja darauf [...] dass EINE IP-Adresse genutzt wird.

Nein, man kann beliebig viele IP Adressen und sogar Dienste bei einem Fail- oder Switchover auf der aktiven, bzw. passiven Node hoch und runter fahren.
Richtig ist, dass natürlich jedes Netz genau EINE Gateway IP Adresse braucht, die sinniger Weise immer nur auf EINER Node im Cluster gleichzeitig aktiv ist.

Zitat

allerdings mit der SELBEN IP-Adresse die eben noch Kiste 1 hatte

Na, das will ich doch hoffen. Wenn deine default Route auf 192.168.1.1 lag und die Kiste plötzlich weg schmiert, dann möchte ich schon, dass die 2. Maschine die SELBE IP Adresse übernimmt, damit meine Systeme noch raus routen können.
Natürlich wäre es auch möglich eine andere IP Adresse automatisch zu starten. Heartbeat kann so ziemlich alles

Zitat

Wir nutzen VRRP als Redundanzprotokoll.

Ich hatte vor Jahren mal VRRP ausprobiert und war von der Geschwindigkeit des Failovers begeistert Allerdings gab es unter Linux damals nur die Implementation von "keepalived" und das lief nicht so tuffig. Zudem hat mich bei VRRP etwas genervt, dass das Auswahlverfahren (Election) über die jeweiligen Interfaces geht, also auch über die externen IFs. Die damalige Verschlüsselung war zudem nur IPSEC/AH (also nur gesicherte Authentifizierung, Pakete an sich sind lesbar). Weiterhin hatte ich in meinen Tests desöfteren Split Brains produzieren können, was mir gar nicht gefiel. Lag allerdings wohl eher an "keepalived".

Wie dem auch sei, wir nutzen in diversen HA Projekten Heartbeat und ich möchte es ehrlich nicht missen Wenn man ne Cisco Kiste hat, ist VRRP/HSRP jedoch nicht verkehrt.

Don