CARP-Einrichtung

[ThomasE]

Hallo allerseits,

wir arbeiten derzeit mit einer sicherlich ziemlich großen OPNsense-Konfiguration. Um mal die Größenordnung zu verdeutlichen: Wir reden von grob 500 VLANs mit entsprechenden Interfaces, dazu noch DHCP, OpenVPN usw. Unser Setup ist nicht wahnsinnig komplex, aber eben doch ziemlich umfangreich.

Zum gegenwärtigen Zeitpunkt nutzen wir quasi kalte Redundanz: Auf einer zweiten Maschine mit identischer Hardware ist eine identische OPNsense-Version installiert und die Konfiguration wird regelmäßig vom Produktivsystem nach /conf/config.xml auf der Backup-Maschine kopiert, ohne Letztere neu zu starten. Im Fall des Ausfalls des Produktivsystems müssen wir also das zweite System neu starten, damit es die Konfiguration zieht und sämtliche Netzwerkanschlüsse 1:1 umstecken. Es ist klar, dass das jetzt nicht das Nonplusultra der Hochverfügbarkeit ist, aber bei uns stehen weder Millionenbeträge noch Menschenleben auf dem Spiel, wenn das Netzwerk mal ein paar Minuten oder (hoffentlich wenige) Stunden down ist. Dennoch sehen wir hier natürlich Verbesserungspotenzial durch den Einsatz von CARP, und wir befinden uns derzeit in der Prüfungsphase, ob Aufwand und Nutzen hier in einem vernünftigen Verhältnis zueinander stehen. Bevor wir jetzt anfangen, uns in die Tiefen von CARP einzuarbeiten, würde ich eine Frage vorab klären. Konkret geht es mir um diesen Satz (Hervorhebung duch mich) in der Doku:

When using CARP ( FreeBSD handbook on CARP ), all fail-safe interfaces should have a dedicated IP address which will be combined with one shared virtual IP address to communicate to both networks.

Heißt das, ich muss am Ende für jedes Interface insgesamt drei IP-Adressen konfigurieren oder geht das im Prinzip auch irgendwie anders und mit welchen Konsequenzen wäre das verbunden? Bei unserer bisherigen Lösung hatten wir nur ein dediziertes Interface auf beiden Geräten, über das alle erforderlichen Informationen ausgetauscht wurden. Im Falle eines Ausfalls - der in über zehn jahren kein einziges Mal eingetreten ist - hätte das andere Gerät dann nahtlos übernehmen können.

Die zwingende Notwendigkeit, tatsächlich jeweils drei IPs zu konfigurieren, wäre für uns ein Anlass, nochmal darüber nachzudenken, ob CARP wirklich das ist, was wir benötigen.

Über ein paar allgemeine Aussagen, ob die Einrichtung von CARP in einer derart umfangreichen Umgebung überhaupt mit vertretbarem Aufwand darstellbar ist oder ob man das gleich bei der Ersteinrichtung hätte machen sollen/müssen, würde ich mich ebenfalls freuen.

[Monviech (Cedrik)]

CARP kann auch mit einer IP Adresse betrieben werden.

https://forum.opnsense.org/index.php?topic=34955

Für das Interface wo man die Firewalls administriert sollte man es richtig machen mit 3 Adressen, damit man unter den 2 Interface Adressen beide Firewalls jederzeit erreichen kann.

Für den Rest reicht eigentlich eine CARP IPv4 und eine CARP IPv6 Adresse pro VLAN und dann keine IPv4/IPv6 Konfiguration auf den eigentlichen "logischen" VLAN Interfaces. (rein technisch gesehen).

Ob dann DHCP Server mit einer CARP VIP klappt muss man in einer kleinen Testumgebung ausprobieren. Router Advertisement (IPv6) kann man alleinig auf die CARP VIP stellen.

Wenn man gar keine Probleme in irgend einer Art haben will, sollte man die 3 IP Adressen pro VLAN opfern. (Bei IPv6 braucht man nur eine CARP VIP, da jedes Interface standardmäßig Link Local Adressen hat.)

[Patrick M. Hausen]

Heißt das, ich muss am Ende für jedes Interface insgesamt drei IP-Adressen konfigurieren oder geht das im Prinzip auch irgendwie anders und mit welchen Konsequenzen wäre das verbunden?

Ja, das heißt es. Bei CARP benötigt jedes Gerät eine eigene Adresse in der Broadcast Domain und dann gibt es N "floating" IP-Adressen, die zwischen beiden Geräten hin und her wandern können. Ist auch bei VRRP oder HSRP so, generell bei jedem HA-Protokoll.

Bei unserer bisherigen Lösung hatten wir nur ein dediziertes Interface auf beiden Geräten, über das alle erforderlichen Informationen ausgetauscht wurden. Im Falle eines Ausfalls - der in über zehn jahren kein einziges Mal eingetreten ist - hätte das andere Gerät dann nahtlos übernehmen können.

Das hat OPNsense natürlich auch, ist aber ein anderer Baustein der gesamten HA-Thematik.

Gruß
Patrick

[JeGr]

Was Patrick schon schrieb - es liegt in der Natur von Redundanzprotokollen, dass sie sich auf jedem Interface um das es geht gegenseitig austauschen um Ausfälle zu bemerken. Es gibt Hersteller die das "anders basteln" und dann nur auf bspw. dem Management mit 3 Adressen arbeiten und das auf den restlichen Interfaces anders hinmogeln, prinzipiell um es sauber aufzusetzen sind aber 3 IPs pro Interface/VLAN notwendig.

Monviech hat an der Stelle recht, dass man es - wie andere auch - hinfrickeln kann mit weniger auszukommen. Das hat aber die ein oder andere Fußangel über die man meist dann fällt, wenn man es gerade nicht gebrauchen kann. Ja es geht - gerade auf dem WAN - mit weniger als 3 IPs, das wurde u.a. wegen Szenarien wie PPPoE Interfaces gebaut, die man HA bauen wollte. Allerdings sind die in ihrem Naturell eh schon suboptimal (weil nur eine Maschine sie sinnvoll aufbauen kann) und daher ist dann das "Problem", dass nur der primary Node online ist so oder so gegeben.

Wenn aber eine saubere Verbindung beider Firewalls auf dem WAN bspw. möglich ist, sollte das versucht werden zu erreichen, damit die Verbindung auch dann läuft, wenn mal nicht alles problemlos rennt. Ohne entweder ein /29 am WAN oder mit einem Transfernetz am Providerrouter klappts dann nicht.

Was hat das für Vorteile? Eine ganze Menge:

* Update Handling: Updates können - von VPNs auf der Firewall abgesehen - ohne Unterbrechung durchgeführt werden, da hier zuerst das Standby Gerät aktualisiert wird, dann getestet und geschwenkt und dann erst das Primärgerät aktualisiert. Da das Umschalten von Primär auf Sekundär-Gerät innerhalb von ns/ms läuft, wird man da im Normalfall bei korrekter Konfiguration nichts bemerken.
* Failover Handling: Bei Problem mit Gerät, Kabel, Switch am einen Gerät wird automatisch aufs Zweitgerät gewechselt ohne dass jemand vor Ort sein muss.
* Sync kann per Cronjob quasi sofort oder "hängend" mit Versatz konfiguriert werden, so dass auf dem Backup Gerät notfalls noch eine ältere Konfiguration vorhanden ist, wenn eine Konfigurationsänderung was kaputt macht.


Was die Implementation in vorhandene Umgebungen angeht:

Das hängt stark von der Umgebung ab. Wie viele Netze/VLANs existieren, sind dort überall noch IPs frei - am besten die gleichen Adressen über alle Netze hinweg. Die vorhandene IP der jetzigen Firewall wird man dann als CARP VIP jeweils definieren und den Firewalls selbst andere IPs in den Netzen geben. Was sich - je nach GW - anbietet, sind die IPs .1-.3 oder .251-.254 in den Netzen zu nutzen. Allerdings kennen wir auch "krumme" Gateways wie .4, .6, .14 oder andere hysterisch gewachsene Strukturen. Wichtig ist hier nur, dass in jedem Netz die Firewalls noch Adressen hätten, die am Besten nebeneinander liegen damit man sich zurechtfindet.

Beispiel:

Ist-Zustand: 1x WAN, 10x LAN-Typ Netze. GW ist in den LANs die .6 aus historisch-hysterischem Setup - nicht zu ändern. In jedem Netz ist noch der Bereich ab .250 nach oben frei. WAN ist ein DSL Anschluß.
Dann kann man den Cluster in etwa so integrieren:

FWL1:
- bekommt auf LANs statt der .6 jetzt die .251.
- zusätzlich bekommt sie die .6 jeweils als CARP VIP in den Netzen
- auf dem DSL Interface wandert die DSL Einwahl auf den Providerrouter/-modem, der mit den Firewalls ein Transfernetz baut (192.0.2.0/29)
- dort bekommt sie die .4 und als CARP VIP zusätzlich die .6
- dem Providergerät verpasst man einen exposed Host, dass alles auf die .6 weitergeleitet wird (Gerät und Tauglichkeit prüft man vorab)
- hängt intern an Switch 1

FWL2:
- bekommt auf LANs die .252
- bekommt auf dem neuen WAN Transfernetz die .5
- nach sauberem Sync von FWL1 sollte sie als CARP Status für alle Adressen brav Backup sein.
- hängt intern an Switch 2

Mit dieser Konstellation gibt es bei Ausfall von Gerät 1, Switch 1 oder Verkabelung dazwischen sofort einen sauberen Failover auf die 2er Schiene und umgekehrt. Natürlich wird dann vielfach lamentiert, dass man die Providereinwahl dann nicht redundant hat, das ist aber in den meisten Fällen eh nicht möglich. Ob da nun ein Router davor klemmt oder ein Modem das den Löffel abgibt - es ist ein Gerät und damit ein SPOF und muss gesondert behandelt werden. Entweder legt man sich eben ein zweites Modem/Router/whatever auf Lager oder es ist ein Providergerät, dann muss der auch dafür gerade stehen und es schnellstmöglich tauschen. Gegen die Art des Ausfalls würde eh nur eine zweite Leitung helfen. Das ändert aber nichts daran, dass ab dem Providergerät dann alles sauber redundant ausgelegt ist und entsprechend ausfallen kann ohne Störung zu erzeugen. (entsprechende Verkabelung etc. vorausgesetzt).

Das wäre dann so der grobe Ablauf.

Cheers
\jens