![[OpenBSD]](../../../images/smalltitle.gif){kind=small}
[[Wstecz: Authpf: powłoka dla bramek uwierzytelniających] [Spis treści] [Dalej: Zapora ogniowa dla domu i małego biura]
CARP pracuje pozwalając grupie hostów, w tym samym segmencie sieci, na dzielenie adresu IP. Taka grupa hostów nazywana jest "redundancy group". Taka nadmiarowa grupa posiada przypisany adres IP, który jest dzielony pomiędzy członkami grupy. Wewnątrz grupy jeden host jest przeznaczany jako "główny" (ang. master) natomiast pozostałe jako "zapasowe" (ang. backups). Host główny jest tym który bieżąco "trzyma" dzielony adres IP; odpowiada na każdy ruch i zapytania ARP nadchodzące na ten adres. Każdy host może należeć jednocześnie do więcej niż jednej grupy nadmiarowej.
Jednym z powszechnych zastosowań CARP jest tworzenie grupy nadmiarowych zapór ogniowych. Wirtualny adres IP dedykowany takiej grupie jest ustawiony na maszynach klienckich jako brama domyślna. W przypadku gdy główny firewall ulednie awarii lub zostanie wyłączona, adres IP zostanie przeniesiony na jedną z zapasowych zapór i obsługa będzie kontynuowana niezauważalnie.
CARP wspiera zarówno IPv4 jak i IPv6.
Istnieje możliwość by istniało wiele grup CARP w tym samym segmencie sieci. Rozgłoszenia CARP zawierają Virtual Host ID, które pozwala członkom grup określić do jakiej grupy nadmiarowej dane rozgłoszenie należy.
Aby uniemożliwić złośliwemu użytkownikowi w segmencie sieci podszywanie się pod rozgłoszenia CARP, każda grupa może być skonfigurowana z hasłem. Każdy pakiet CARP wysyłany do grupy jest wtedy chroniony przy użyciu SHA1 HMAC.
Odkąd CARP jest osobnym protokołem powinien mieć sprecyzowaną regułę przepuszczającą w filtrze:
pass out on $carp_dev proto carp keep state
$carp_dev powinien być fizycznym interfejsem przez który komunikuje się CARP.
ifconfig carpN create
ifconfig carpN vhid vhid [pass password] [carpdev carpdev] \
[advbase advbase] [advskew advskew] [state state] ipaddress \
netmask mask
Poniższe zachowania CARP są ustawiane przez sysctl(8).
# 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
Ustawienia te powodują:
Uruchomienie ifconfig dla carp1 pokaże status tego interfejsu.
# 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
Gdy pfsunc(4) jest ustawiony na wysyłanie i odbieranie uaktualnień, domyślnym zachowaniem jest wysyłanie mutlicastowe uaktualnień. Wszystkie uaktualnienia wysyłane są bez uwierzytelniania. Najlepszymi powszechnymi praktykami są:
Kiedy aktualizacje są wysyłane i odbierane, pakiety pfsync powinny być przepuszczane przez reguły filtra:
pass on $sync_if proto pfsync
$sync_if powinien być fizycznym interfejsem przez który komunikuje się pfsync(4).
ifconfig pfsyncN syncdev syncdev [syncpeer syncpeer]
# ifconfig pfsync0 syncdev em1Następuje włączenie pfsync na interfejsie em1. Wychodzące uaktualnienia będą wysyłane mutlicastem do sieci zezwalając by każdy host mógł je odebrać.
Przykładowy scenariusz.
Dwie zapory, fw1 i fw2.
+----| WAN/Internet |----+
| |
em2| |em2
+-----+ +-----+
| fw1 |-em1----------em1-| fw2 |
+-----+ +-----+
em0| |em0
| |
---+-------Shared LAN-------+---
Zapory połączone są back-to-back kablem krosowany, na interfejsach em1 Oba połączone są do sieci LAN poprzez interfejsy em0 oraz z siecią WAN/Internet poprzez interfejsy em1. Poniżej znajdują się wykorzystywane adresy IP:
Polityka sieci zakłada że fw1 będzie preferowaną zaporą główną.
Konfigurujemy fw1:
! enable preemption and group interface failover
# sysctl -w net.inet.carp.preempt=1
! configure pfsync
# ifconfig em1 10.10.10.1 netmask 255.255.255.0
# ifconfig pfsync0 syncdev em1
# ifconfig pfsync0 up
! configure CARP on the LAN side
# ifconfig carp1 create
# ifconfig carp1 vhid 1 carpdev em0 pass lanpasswd \
172.16.0.100 netmask 255.255.255.0
! configure CARP on the WAN/Internet side
# ifconfig carp2 create
# ifconfig carp2 vhid 2 carpdev em2 pass netpasswd \
192.0.2.100 netmask 255.255.255.0
|
Konfigurujemy fw2:
! enable preemption and group interface failover
# sysctl -w net.inet.carp.preempt=1
! configure pfsync
# ifconfig em1 10.10.10.2 netmask 255.255.255.0
# ifconfig pfsync0 syncdev em1
# ifconfig pfsync0 up
! configure CARP on the LAN side
# ifconfig carp1 create
# ifconfig carp1 vhid 1 carpdev em0 pass lanpasswd \
advskew 128 172.16.0.100 netmask 255.255.255.0
! configure CARP on the WAN/Internet side
# ifconfig carp2 create
# ifconfig carp2 vhid 2 carpdev em2 pass netpasswd \
advskew 128 192.0.2.100 netmask 255.255.255.0
|
Przykład:
By przekazać ruch dla określonej grupy CARP, wyłącz interfejs carp(4) na głównej zaporze ogniowej. Spowoduje to wysłanie z niej rozgłoszenia z "nieskończonymi" wartościami advbase oraz advskew Host(y) zapasowe zauważą taką informację i natychmiast przejmą zadania głównego.
# ifconfig carp1 down
Alternatywą jest zwiększenie advskew do wartości większej niż wartość advskew na hostach zapasowych. Spowoduje to awaryjne przełączenie, jednak pozwoli hostowi głównemu na przynależność do grupy CARP.
Inna metodą awaryjnego przełączania jest dostrojenie licznika degradacji CARP'a. Licznik degradacji jest odmierza "kiedy" host staje się hostem głównym w grupie CARP. Przykładowo, złym pomysłem jest by startujący właśnie host stał się głównym w grupie CARP, aż do czasu skonfigurowania wszystkich interfejsów, uruchomienia wszystkich daemonów, itp. Hosty rozgłaszające wysoką wartość degradacji będą znacznie mniej preferowanie w elekcji głównego.
Licznik degradacji przechowywany jest w każdym interfejsie grupy do której należy dany interfejs. Domyślnie, wszyskie interfejsy CARP należą do grupy interfejsów "carp". Aktualną wartość licznika degradacji można sprawdzić korzystając z polecenia ifconfig(8):
# ifconfig -g carp
carp: carp demote count 0
W tym przykładzie pokazana została zawartość licznika powiązanego z grupą interfejsów "carp". Gdy host CARP rozgłasza się w sieci, bierze sumę liczników degradacji dla każdej grupy interfejsów carp(4) do których on należy i rozgłasza tą wartość jako wartość degradacji.
Rozważmy poniższy przykład. Dwie zaporty sieciowe działające z CARP z poniższymi interfejsami CARP:
Celem jest zapewnienie przełączenia tylko grup carp1 i carp2 na drugą zaporę.
Najpierw, przydzielmy każdy z nich do nowej grupy, w tym przypadku nazywanej "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
Zwiększymy teraz wartość licznika degradacji dla grupy "internal" przy pomocy ifconfig(8):
# ifconfig -g internal
internal: carp demote count 0
# ifconfig -g internal carpdemote 50
# ifconfig -g internal
internal: carp demote count 50
Teraz nasz firewall przełączy się gładko z grupami carp1 i carp2 na drugą maszynę w klastrze wciąż pozostając hostem głównym dla carp3 i cart4. Gdyby drugi firewall zaczął się rozgłaszać z degradacją większą niż 50, lub gdy gdy drugi firewall przestał się rozgłaszać, wowczas obecna maszyna stała by się ponownie rolę głównej dla carp1 i carp2.
Aby powrócić do pierwotnego firewall'a, odwracamy zmiany:
# ifconfig -g internal -carpdemote 50
# ifconfig -g internal
internal: carp demote count 0
Daemony sieciowe jak OpenBGPD czy sasyncd(8) korzystają z licznika degradacji aby się upewnić, że firewall nie stanie się masterem aż do czasu nawiązania sesji BGP i synchronizacji IPsec SA.
pass in on fxp0 inet proto tcp from any to carp0 port 22lecz zastąpienie fxp0 carp0 może działać nie tak jak to zaplanowałeś.
NIE zapominaj zezwalać na proto carp and proto pfsync!
[Wstecz: Authpf: powłoka dla bramek uwierzytelniających] [Spis treści] [Dalej: Zapora ogniowa dla domu lub małego biura]
![[back]](../../../images/back.gif){kind=small}
www@openbsd.org