![[OpenBSD]](../../../images/smalltitle.gif){kind=small}
[Zurück: Authpf: Benutzer-Shell für authentifizierende Gateways] [Inhalt] [Weiter: Firewall für zuhause oder ein kleines Büro]
CARP funktioniert, indem es einer Gruppe mehreren Hosts in einem gleichen Netzwerksegment ermöglicht, sich eine IP-Adresse zu teilen. Eine solche Gruppe wird als Redundanzgruppe bezeichnet (im Folgenden nur Gruppe genannt). Dieser Gruppe ist eine IP-Adresse zugeteilt, die sich die Gruppenmitglieder untereinander teilen. Innerhalb der Gruppe arbeitet ein Host als Master, die restlichen Hosts in der Gruppe als Backup. Der Masterhost hält die zugewiesene IP-Adresse; er reagiert auf den gesamten Netzwerkverkehr und auf ARP-Anfragen, die an ihn bzw. an die ihm zugewiesene IP gerichtet sind. Jeder Host kann einer oder mehreren Gruppen zugeteilt sein.
In der Praxis wird CARP häufig dazu genutzt, eine Gruppe von redundanten Firewalls zu erstellen. Die virtuelle IP, die der Gruppe zugeteilt ist, wird bei den Netzwerkclients als das standardmäßige Gateway konfiguriert. Sollte nun der Masterhost der Gruppe ausfallen, so wird einer der Backuphosts in der Gruppe seine Funktion übernehmen.
CARP unterstützt IPv4 und IPv6.
Es ist möglich, mehrere CARP-Gruppen in einem gleichen Netzwerksegment einzurichten. Die CARP-Nachrichten beinhalten eine »Virtual Host ID«, welche es den Hosts ermöglicht, zwischen den verschiedenen Gruppen zu unterscheiden.
Um eine Gruppe vor gefälschten CARP-Nachrichten zu schützen, ist es möglich, jede dieser Gruppen mit Passwortschutz zu versehen. Jedes gesendete Paket ist durch einen SHA1-HMAC geschützt.
CARP ist ein eigenständiges Protokoll, sodass extra definierte pass-Regeln im Regelsatz verwendet werden sollten.
pass out on $carp_dev proto carp keep state
$carp_dev sollte das physikalische Interface sein, über welches CARP kommuniziert.
ifconfig carpN create
ifconfig carpN vhid vhid [pass password] [carpdev carpdev] \
[advbase advbase] [advskew advskew] [state state] ipaddress \
netmask mask
Weiterhin kann das Verhalten von CARP via sysctl(8) manipuliert werden.
# sysctl -w net.inet.carp.allow=1
# ifconfig carp1 create
# ifconfig carp1 vhid 1 pass mekmitasdigoat carpdev em0 \
advskew 100 10.0.0.1 netmask 255.255.255.0
Das bewirkt Folgendes:
Ein Aufruf von ifconfig für carp1 zeigt den Status des Interfaces an.
# ifconfig carp1
carp1: flags=8802<UP,BROADCAST,SIMPLEX,MULTICAST> mtu 1500
carp: BACKUP carpdev em0 vhid 1 advbase 1 advskew 100
groups: carp
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
Wenn pfsync(4) so konfiguriert ist, diese Nachrichten über das Netzwerk zu senden und zu empfangen, werden die Nachrichten an alle Teilnehmer der Gruppe versendet. All diese Updateinformationen werden jedoch ohne Authentifizierung versendet. Um hier für Sicherheit zu sorgen, gibt es zwei bewährte Verfahren:
Wenn die Updates über das Netzwerk gesendet und empfangen werden, sollten diese pfsync-Pakete auch im Regelsatz so berücksichtigt werden, dass sie auch ihr Ziel erreichen können.
pass on $sync_if proto pfsync
$sync_if sollte das physikalische Interface sein, über das pfsync(4) kommuniziert.
ifconfig pfsyncN syncdev syncdev [syncpeer syncpeer]
# ifconfig pfsync0 syncdev em1Dies aktiviert pfsync auf dem em1-Interface. Ausgehender Verkehr wird via Multicast in das Netzwerk gesendet. Jeder Host mit aktiviertem pfsync kann die Updates empfangen.
Ein Beispielszenario. Zwei Firewalls: fw1 und fw2.
+------| WAN/Internet |------+
| |
em2| |em2
+-----+ +-----+
| fw1 |-em1--------------em1-| fw2 |
+-----+ +-----+
em0| |em0
| |
---+--gemeinsam genutztes LAN---+---
Die Firewalls sind über ein Crossover-Kabel miteinander über em1 verbunden. Beide sind an das LAN mit em0 und an das WAN (bzw. Internet) an em2 angeschlossen. Die IP-Adressen wurden folgendermaßen vergeben:
Als Firewall-Masterhost wird fw1 festgelegt.
Konfiguration von fw1:
! aktiviere Preemptivität und Ausfallsicherheit für Gruppeninterfaces
# sysctl -w net.inet.carp.preempt=1
! pfsync konfigurieren
# ifconfig em1 10.10.10.1 netmask 255.255.255.0
# ifconfig pfsync0 syncdev em1
# ifconfig pfsync0 up
! CARP auf dem LAN-Interface konfigurieren
# ifconfig carp1 create
# ifconfig carp1 vhid 1 carpdev em0 pass lanpasswd \
172.16.0.100 netmask 255.255.255.0
! CARP auf dem WAN/Internet-Interface konfigurieren.
# ifconfig carp2 create
# ifconfig carp2 vhid 2 carpdev em2 pass netpasswd \
192.0.2.100 netmask 255.255.255.0
|
Konfiguration von fw2:
! aktiviere Preemptivität und Ausfallsicherheit für Gruppeninterfaces
# sysctl -w net.inet.carp.preempt=1
! pfsync konfigurieren
# ifconfig em1 10.10.10.2 netmask 255.255.255.0
# ifconfig pfsync0 syncdev em1
# ifconfig pfsync0 up
! CARP auf dem LAN-Interface konfigurieren
# ifconfig carp1 create
# ifconfig carp1 vhid 1 carpdev em0 pass lanpasswd \
advskew 128 172.16.0.100 netmask 255.255.255.0
! CARP auf dem WAN/Internet-Interface konfigurieren.
# ifconfig carp2 create
# ifconfig carp2 vhid 2 carpdev em2 pass netpasswd \
advskew 128 192.0.2.100 netmask 255.255.255.0
|
Beispiele:
Um einen solchen Ausfall für eine bestimmte CARP-Gruppe zu erzwingen, fahre das carp(4)-Interface auf dem Masterhost herunter. Das führt dazu, dass der Masterhost sich selber mit »unendlich hohen« advbase und advskew ankündigen wird. Der Backuphost (oder einer davon) wird das merken und ab sofort die Rolle vom Masterhost übernehmen.
# ifconfig carp1 down
Eine Alternative wäre advskew zu vergrößern, sodass der Wert größer ist als advskew auf dem Backuphost (bzw. den anderen Backuphosts). Damit wird ein Failover hervorgerufen, der es dem Master ermöglicht, weiterhin in der CARP-Gruppe verfügbar zu sein.
Eine andere Möglichkeit, um Ausfallsicherheit zu gewährleisten, ist die Anpassung des CARP-Demotionzählers. Der Demtionzähler gilt als Maß dafür, wie »bereit« ein Host ist, der Master der CARP-Gruppe zu werden. Wenn ein Host zum Beispiel gerade dabei ist hochzufahren, wäre es eine schlechte Idee, ihn als CARP-Master zu deklarieren, bis alle Interfaces eingerichtet, alle Netzwerkdaemons gestartet wurden etc. Hosts, die einen hohen Demotionwert versenden, werden seltener als Master ausgewählt.
Ein Demotionzähler wird in jeder Interfacegruppe gespeichert, zu der das CARP-Interface gehört. Standardmäßig sind alle CARP-Interfaces Mitglied der »carp«-Interfacegruppe. Der aktuelle Wert des Demotioncounters kann mit ifconfig(8) angezeigt werden:
# ifconfig -g carp
carp: carp demote count 0
In diesem Beispiel wird der Zähler der »carp«-Interfacegruppe angezeigt. Wenn ein CARP-Host sich selbst im Netzwerk anbietet, so wird die Summe aller Demotionzähler der Interfacegruppen versendet, zu denen das carp(4)-Interface gehört. Das heißt, dass der versendete Demotionwert die Summe aller Zähler darstellt.
Nehmen wir nun folgendes Beispiel an. Zwei Firewalls mit CARP besitzen folgende CARP-Interfaces:
Das Ziel besteht darin, nur die carp1- und carp2-Gruppen im Falle eines Ausfalls auf die zweite Firewall umzuleiten.
Zuerst müssen beide zuerst zu einer neuen Interfacegruppe hinzugefügt werden. In diesem Beispiel nennen wir sie »internal«:
# ifconfig carp1 group internal
# ifconfig carp2 group internal
# ifconfig internal
carp1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
carp: MASTER carpdev em0 vhid 1 advbase 1 advskew 100
groups: carp internal
inet 10.0.0.1 netmask 0xffffff00 broadcast 10.0.0.255
carp2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> mtu 1500
carp: MASTER carpdev em1 vhid 2 advbase 1 advskew 100
groups: carp internal
inet 10.0.1.1 netmask 0xffffff00 broadcast 10.0.1.255
Nun erhöhen wir den Demotionzähler für die Gruppe »internal« mittels ifconfig(8):
# ifconfig -g internal
internal: carp demote count 0
# ifconfig -g internal carpdemote 50
# ifconfig -g internal
internal: carp demote count 50
Die Firewall wird nun im Falle eines Ausfalls die Gruppen carp1 und carp2 gerne an die andere Firewall im Cluster übergeben, doch weiterhin Master von carp3 und carp4 bleiben. Wenn die andere Firewall nun selbst beginnt, sich mit einem Demotionwert über 50 anzubieten, oder die andere Firewall aufhört, ihren Wert zu übermitteln, so wird diese Firewall wie zuvor die Gruppen carp1 und carp2 übernehmen.
Um auf die primäre Firewall zurückfallen zu können, mach die Änderungen wieder rückgängig:
# ifconfig -g internal -carpdemote 50
# ifconfig -g internal
internal: carp demote count 0
Netzwerkdaemons wie zum Beispiel OpenBGPD und sasyncd(8) verwenden den Demotioncounter, um sicherzustellen, dass die Firewall nicht zum Master wird, bevor die BGP-Sitzung aufgebaut und IPsec-SAs synchronisiert wurden.
pass in on fxp0 inet proto tcp from any to carp0 port 22Das Ersetzen von fxp0 in carp0 würde aber nicht das machen, was du erwartest.
Vergiss NIEMALS, proto carp und proto pfsync zu übergeben!
[Zurück: Authpf: Benutzer-Shell für authentifizierende Gateways] [Inhalt] [Weiter: Firewall für zuhause oder ein kleines Büro]
![[zurück]](../../../images/back.gif){kind=small}
www@openbsd.org