[Précédent : Authpf : Shell Utilisateur pour les
Passerelles d'Authentifications]
[Index]
[Suivant : Pare-feu pour réseau domestique ou
petite société]
PF: Haute-disponibilité des pare-feux avec
CARP et pfsync
Table des Matières
Introduction à CARP
CARP veut dire "Common Address Redundancy Protocol".
L'objectif premier de ce protocole est de permettre à un groupe d'hôtes
sur un même segment réseau de partager une adresse IP.
CARP est une alternative sécurisée et libre aux protocoles Virtual Router Redundancy
Protocol (VRRP) et Hot Standby Router
Protocol (HSRP).
On appelle un groupe d'hôtes utilisant CARP un "groupe de redondance".
Le groupe de redondance se voit attribuer une adresse IP partagée entre
les membres du groupe. Au sein de ce groupe, un hôte est désigné comme
"maître". Les autres membres sont appellés "esclaves".
L'hôte maître est celui qui "prend" l'adresse IP partagée. Il répond à
tout trafic ou requête ARP à l'attention de cette adresse.
Chaque hôte peut appartenir à plusieurs groupes de redondance.
Une utilisation commune de CARP est la création d'un groupe de pare-feux
redondants.
L'adresse IP virtuelle attribuée au groupe de redondance est désignée
comme l'adresse du routeur par défaut sur les machines clientes.
Dans le cas où le pare-feu maître rencontre une panne ou est déconnecté
du réseau, l'adresse IP virtuelle sera prise par un des pare-feux
esclaves et le service continuera à être rendu sans interruption.
CARP supporte IPv4 et IPv6.
Fonctionnement de CARP
L'hôte maître du groupe envoit des annonces régulières sur le réseau
local afin que les hôtes esclaves puissent savoir qu'il est toujours
disponible.
Si les hôtes esclaves ne recoivent plus d'annonce de la part du maître
durant une période de temps configurable, alors l'un d'eux devient le
nouveau maître. Ce dernier est celui dont les valeurs configurées pour
advbase et advskew sont les plus faibles.
Il est possible de faire co-exister plusieurs groupes CARP sur un même
segment réseau.
Les annonces de CARP contiennent un identifiant appelé "Virtual Host ID"
qui permet à des membres d'un même groupe d'identifier le groupe de
redondance auquel une annonce donnée appartient.
Afin d'empêcher un utilisateur malicieux sur le segment réseau d'usurper
les annonces CARP, chaque groupe peut être doté d'un mot de passe. Ainsi
chaque paquet CARP envoyé au groupe est protégé par SHA1 MAC.
Etant donné que CARP est un protocole à part entière, il doit être
explicitement autorisé au niveau des règles de filtrage :
pass out on $carp_dev proto carp keep state
$carp_dev est l'interface physique que CARP utilise pour la
communication.
Configurer CARP
Chaque groupe de redondance est représenté par une interface réseau
virtuelle de type
carp(4). Ainsi, CARP est configuré à l'aide de la commande
ifconfig(8).
ifconfig carpN create
ifconfig carpN vhid vhid [pass password]
[carpdev carpdev] \
[advbase advbase] [advskew advskew]
[state state] ipaddress
mask
- carpN
- Le nom de l'interface virtuelle carp(4). N est un entier qui
représente le numéro de l'interface (par exemple carp10).
- vhid
- L'identifiant Virtual Host ID. C'est un numéro unique utilisé pour
identifier le groupe de redondance sur le réseau. Les valeurs
acceptables sont de 1 à 255.
- password
- Le mot de passe d'authentification à utiliser lors de la
communication avec d'autres hôtes CARP dans le même groupe de
redondance.
Ce mot de passe doit être partagé entre tous les membres du groupe.
- carpdev
- Ce paramètre optionnel spécifie l'interface réseau physique qui
appartient à ce groupe de redondance.
Par défaut, CARP essaiera de déterminer l'interface à utiliser en
cherchant une interface physique qui est dans le même sous-réseau que la
combinaison adresse IP/masque de l'interface carp(4).
- advbase
- Ce paramètre optionnel spécifie le nombre de secondes qui s'écoule
entre chaque annonce CARP.
La valeur par défaut est 1 seconde.
Les valeurs acceptables sont de 1 à 255.
- advskew
- Ce paramètre optionnel spécifie le biais à introduire au niveau de
advbase lors de l'envoi d'annonces CARP.
En manipulant advbase, l'hôte maître CARP peut être
choisi.
Plus grand est ce nombre, moindres sont les chances pour que
l'hôte soit retenu lorsqu'un maître est choisi.
La valeur par défaut est 0.
Les valeurs acceptables sont de 1 à 255.
- state
- Permet de forcer l'état de l'interface carp(4). Les états valides
sont init, backup, et master.
- ipaddress
- Adresse IP partagée entre les membres du groupe de redondance.
Cette adresse n'a pas besoin d'être dans le même sous-réseau que
l'adresse IP de l'interface physique (si une adresse est configurée sur
cette interface).
En revanche, elle doit être la même sur tous les membres du groupe.
- mask
- Masque de sous-réseau de l'adresse IP partagée.
Vous pouvez contrôler d'avantages de paramètres de CARP à l'aide de
sysctl(8).
- net.inet.carp.allow
- Permet d'accepter ou de refuser les paquets CARP entrants. La valeur
par défaut est 1 (accepter).
- net.inet.carp.preempt
- Permet aux hôtes au sein d'un même groupe de redondance d'avoir de
meilleurs advbase et advskew pour élire le maître.
De plus, cette option permet de basculer toutes les interfaces dans le
cas où une interface est en panne.
Si une des interfaces physiques utilisée pour CARP est indisponible,
CARP fixera l'advskew de toutes les autres interfaces à 240. Ce
qui revient à se déclarer indisponible et forcer un basculement.
Cette option est à 0 (désactivation) par défaut.
- net.inet.carp.log
- Journalise les mauvais paquets CARP. La valeur par défaut est 0
(désactivé).
- net.inet.carp.arpbalance
- Permet de partager la charge entre plusieurs membres d'un même
groupe de redondance.
Cette option est à 0 (désactivation) par défaut.
Veuillez consulter
carp(4) pour plus d'informations.
Exemple de configuration CARP
Voici un exemple de configuration CARP.
# sysctl -w net.inet.carp.allow=1
# ifconfig carp1 create
# ifconfig carp1 vhid 1 pass mekmitasdigoat carpdev em0 \
advskew 100 10.0.0.1 255.255.255.0
Les commandes ci-dessous permettent de faire les opérations suivantes :
- Active la réception des paquets CARP (c'est le comportement par
défaut)
- Créé une interface carp(4), carp1.
- Configure carp1 pour l'hôte virtuel #1, met en place un mot
de passe, utilise em0 comme interface physique du groupe, et
fais de cette machine un esclave étant donné la valeur de
advskew, fixée à 100 (en supposant bien entedu que le
maître a un advskew de moins de 100).
L'adresse IP partagée affectée à ce groupe est 10.0.0.1/255.255.255.0.
L'utilisation de ifconfig permet de voir l'état de l'interface
carp1.
# ifconfig carp1
carp1: flags=8802<UP,BROADCAST,SIMPLEX,MULTICAST> mtu 1500
carp: BACKUP carpdev em0 vhid 1 advbase 1
advskew 100
inet 10.0.0.1 netmask 0xffffff00 broadcast
10.0.0.255
Introduction à pfsync
L'interface réseau
pfsync(4) expose certains changements effectués au niveau de la
table d'état de
pf(4).
En surveillant cette interface à l'aide de
tcpdump(8), les changements de la table d'état peuvent être
observés en temps réel.
De plus, l'interface pfsync(4) peut envoyer ces messages relatifs aux
changements affectant la table d'état sur le réseau afin que d'autres
pare-feux PF puissent fusionner ces changements à leurs propres tables
d'état.
De même, pfsync(4) peut aussi être en écoute des messages entrants.
Fonctionnement de pfsync
Par défaut, pfsync(4) n'envoit pas et ne reçoit pas les mises à jour de
la table d'état à travers le réseau. Cependant, les mises à jour peuvent
être toujours surveillées en utilisant tcpdump(8) ou d'autres outils
similaires en local sur la machine.
Lorsque pfsync(4) est configuré pour envoyer et recevoir des mises à
jour à travers le réseau, le comportement par défaut consiste à utiliser le
multicast sur le réseau local.
Toutes les mises à jour sont envoyées sans authentification.
Il faudrait donc utiliser une des deux méthodes suivantes pour sécuriser
les échanges :
- Connectez les deux pare-feux qui devront échanger les mises à jour à
l'aide d'un câble croisé. Les interfaces physiques ainsi connectées
seront utilisées comme syncdev (voir plus bas).
- Utilisez l'option syncpeer de la commande ifconfig(8) (voir
plus bas) de telle façon à utiliser des
échanges unicast pour envoyer les mises à jour au pair, puis configurez
ipsec(4)
entre les deux hôtes pour sécuriser le trafic pfsync(4).
Lorsque les mises à jour sont envoyées et reçues à travers le réseau,
les paquets pfsync doivent être autorisés par les règles de filtrage :
pass on $sync_if proto pfsync
$sync_if est l'interface physique utilisée pour la
communication pfsync(4).
Configurer pfsync
pfsync(4) étant une interface réseau virtuelle, elle est configurée à
l'aide de
ifconfig(8).
ifconfig pfsyncN syncdev syncdev [syncpeer
syncpeer]
- pfsyncN
- Le nom de l'interface pfsync(4). Si vous utilisez le noyau
GENERIC, l'interface pfsync0 existe par défaut.
- syncdev
- Le nom de l'interface physique utilisée pour envoyer les mises à
jour pfsync.
- syncpeer
- Ce paramètre optionnel spécifie l'adresse IP d'un hôte avec qui les
échanges de mises à jour pfsync auront lieu.
Par défaut les mises à jour pfsync sont multicast sur le réseau local.
Cette option change ce comportement et utilise des échanges unicast avec
le syncpeer spécifié.
Exemple de configuration pfsync
Voici un exemple de configuration pfsync.
# ifconfig pfsync0 syncdev em1
Cette commande active pfsync sur l'interface em1.
Les mises à jour seront envoyées en multicast sur le réseau. Ainsi tout
hôte utilisant pfsync pourra les recevoir.
Utilisation combinée de CARP et pfsync pour assurer la haute-
disponibilité et la redondance
En combinant les fonctionnalités de CARP et de pfsync, un groupe de deux
pare-feux ou plus peut être utilisé pour créer une grappe de pare-feux
hautement disponible et entièrement redondante.
- CARP:
- Gère le basculement automatique d'un pare-feu à un autre.
- pfsync:
- Synchronise la table d'état entre les pare-feux.
Dans le cas d'un basculement, le trafic n'est pas interrompu lorsque le
nouveau pare-feu maître prend la main.
Voici un scénario typique avec deux pare-feux : fw1 et
fw2.
+----| WAN/Internet |----+
| |
em2| |em2
+-----+ +-----+
| fw1 |-em1----------em1-| fw2 |
+-----+ +-----+
em0| |em0
| |
---+-------LAN partagé------+---
Les interfaces em1 des pare-feux sont connectées à l'aide d'un
câble croisé.
Les interfaces em0 sont connectées au LAN et les interfaces
em2 sont connectées à un réseau WAN ou à Internet.
Les adresses IP utilisées sont les suivantes :
- fw1 em0 : 172.16.0.1
- fw1 em1 : 10.10.10.1
- fw1 em2 : 192.0.2.1
- fw2 em0 : 172.16.0.2
- fw2 em1 : 10.10.10.2
- fw2 em2 : 192.0.2.2
- IP partagée sur le LAN : 172.16.0.100
- IP partagée sur WAN/Internet : 192.0.2.100
La politique réseau veut que le pare-feu fw1 soit maître.
Configurons d'abord fw1 :
! activation de la préemption et le basculement de toutes les interfaces
# sysctl -w net.inet.carp.preempt=1
! configuration de pfsync
# ifconfig em1 10.10.10.1 netmask 255.255.255.0
# ifconfig pfsync0 syncdev em1
# ifconfig pfsync0 up
! configuration de CARP côté LAN
# ifconfig carp1 create
# ifconfig carp1 vhid 1 carpdev em0 pass lanpasswd \
172.16.0.100 255.255.255.0
! configuration de CARP côté WAN/Internet
# ifconfig carp2 create
# ifconfig carp2 vhid 2 carpdev em2 pass netpasswd \
192.0.2.100 255.255.255.0
|
Configurons maintenant fw2 :
! activation de la préemption et le basculement de toutes les interfaces
# sysctl -w net.inet.carp.preempt=1
! configuration de pfsync
# ifconfig em1 10.10.10.2 netmask 255.255.255.0
# ifconfig pfsync0 syncdev em1
# ifconfig pfsync0 up
! configuration de CARP côté LAN
# ifconfig carp1 create
# ifconfig carp1 vhid 1 carpdev em0 pass lanpasswd \
advskew 128 172.16.0.100 255.255.255.0
! configuration de CARP côté WAN/Internet
# ifconfig carp2 create
# ifconfig carp2 vhid 2 carpdev em2 pass netpasswd \
advskew 128 192.0.2.100 255.255.255.0
|
Problèmes opérationnels
Voici quelques problèmes opérationnels communément rencontrés avec
CARP/pfsync.
Configuration de CARP et pfsync au démarrage
Etant donné que carp(4) et pfsync(4) sont des interfaces réseau, elles
peuvent être configurées au démarrage en créant des fichiers
hostname.if(5).
Le script de démarrage
netstart prendra soin de la création et de la configuration des
interfaces.
Exemples :
- /etc/hostname.carp1
-
inet 172.16.0.100 255.255.255.0 172.16.0.255 vhid 1 carpdev em0 \
pass lanpasswd
- /etc/hostname.pfsync0
-
up syncdev em1
Comment forcer le basculement vers ou depuis le noeud maître
De temps à autre, il peut y avoir besoin de forcer le basculement du
maître intentionnellement.
Il peut s'agir par exemple de la nécessité d'arrêter le maître pour des
besoins de maintenance ou de diagnostic suite à des problèmes de
fonctionnements.
L'objectif est de faire basculer le trafic vers un des hôtes esclaves
afin que les utilisateurs ne soient pas affectés par ces opérations.
Pour forcer le basculement, il vous suffit d'arrêter l'interface carp(4)
sur le maître. Ceci aura pour effet d'amener le maître à annoncer des
valeurs advbase et advskew "infinies".
Les autres membres du groupe de redondance le remarqueront immédiatement
et l'un d'eux prendra le rôle de maître.
# ifconfig carp1 down
Astuces pour la création de règles
Filtrer l'interface physique.
Pour PF, le trafic réseau arrive à partir de l'interface physique, pas
de l'interface virtuelle CARP (i.e., carp0).
N'oubliez pas que, sous PF, le nom d'une interface dans une règle
correspond au nom de l'interface physique ou à l'adresse réseau qui lui
est associée.
Tenez-en compte lors de l'écriture de vos règles.
Par exemple, la règle suivante pourrait être correcte :
pass in on fxp0 inet proto tcp from any to carp0 port 22
mais le remplacement de fxp0 par carp0 ne permettrait
pas de la faire fonctionner comme on le souhaite.
N'oubliez PAS d'autoriser proto carp et proto
pfsync!
Références supplémentaires
Pour plus d'informations, veuillez consulter les sources suivantes :
[Précédent : Authpf : Shell Utilisateur pour les
Passerelles d'Authentifications]
[Index]
[Suivant : pare-feu pour réseau domestique ou
petite société]
www@openbsd.org
$OpenBSD: carp.html,v 1.7 2006/05/02 17:09:33 jufi Exp $