[OpenBSD]

[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 envoie 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 reçoivent 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.

Étant 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] [group|-group group] \
   ipaddress netmask 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 parmi les autres groupes, et pour distinguer les différents groupes sur un même réseau. Les valeurs acceptables vont de 1 à 255. Elles doivent être identiques sur chacun des membres du groupe.
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 advskew, 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 à 254.
state
Permet de forcer l'état de l'interface carp(4). Les états valides sont init, backup et master.
group, -group
Ajoute ou supprime une interface carp(4) à un certain groupe d'interface. Par défaut toutes les interfaces carp(4) sont ajoutées au groupe carp. Chaque groupe possède un compteur carpdemote affectant toutes les interfaces carp(4) liées à ce groupe. Comme décrit plus loin, il peut être utile de grouper certaines interfaces ensembles pour des choix de redondance.
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 d'un groupe dans le cas où une interface est en panne. Si une des interfaces physiques utilisées pour CARP est indisponible, CARP augmentera le compteur de dégradation, carpdemote, de 1 sur le groupe d'interfaces dont l'interface carp(4) est membre, ce qui aura pour effet de basculer tous les membres du groupe ensemble. net.inet.carp.preempt est à 0 (désactivation) par défaut.
net.inet.carp.log
Journalise les changements d'états, les mauvais paquets CARP et autres erreurs. Peut être entre 0 et 7, correspondant aux priorités syslog(3). La valeur par défaut est 2 (changements d'états uniquement).

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 netmask 255.255.255.0

Les commandes ci-dessous permettent de faire les opérations suivantes :

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
     groups: carp
     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'envoie 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 :

  1. 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).
  2. 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] [defer|-defer]
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é.
defer
Si le drapeau defer est utilisé, le paquet initial d'une nouvelle connexion traversant le pare-feu ne sera pas transmis tant qu'un autre système pfsync(4) n'aura pas acquitté l'état ajouté dans la table, ou que le délai d'attente aura expiré. Cela ajoute un petit délai mais permet au trafic de passer quand plus d'un pare-feu doit s'occuper des paquets activement ("actif/actif"), par exemple avec certaines configurations ospfd(8), bgpd(8) ou carp(4).

Exemple de configuration pfsync

Voici un exemple de configuration pfsync.
# ifconfig pfsync0 syncdev em1 up
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-feu 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 :

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 netmask 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 netmask 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 netmask 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 netmask 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

Étant 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 d'un groupe CARP donné, 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

Une alternative consiste à positionner advskew à une valeur supérieure à la valeur d'advskew sur les hôtes esclaves. Ceci causera un basculement tout en permettant au maître de participer au groupe CARP.

Une autre méthode de basculement consiste à paramétrer finement le compteur de dégradation CARP. Ce compteur est une mesure de la promptitude d'un hôte à devenir le maître d'une groupe CARP. Par exemple, lorsqu'un hôte est au milieu d'une séquence de démarrage, il ne saurait devenir maître CARP avant que toutes les interfaces soient configurées, que tous les services réseau soient démarrés, etc... Des hôtes annonçant une grande valeur de dégradation seront moins privilégiés pour passer maître.

Un compteur de dégradation est stocké au niveau de chaque groupe d'interfaces auquel appartient l'interface CARP. Par défaut, les interfaces CARP sont membres du groupe d'interfaces "carp". La valeur actuelle du compteur de dégradation peut être vue à l'aide d'ifconfig(8) :

# ifconfig -g carp
carp: carp demote count 0

Dans cet exemple, le compteur associé au groupe d'interfaces "carp" est affiché. Lorsqu'un hôte CARP s'annonce sur le réseau, il prend la somme des compteurs de dégradation pour chaque groupe d'interfaces auquel est associée l'interface carp(4) et l'annonce comme étant sa valeur de dégradation.

Considérons maintenant l'exemple suivant. Deux pare-feux utilisant CARP avec les interfaces ci-après :

L'objectif consiste à basculer uniquement les groupes carp1 et carp2 au pare-feu secondaire.

Tout d'abord, affectez chaque interface à un nouveau groupe, dans ce cas appelé "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

Maintenant, augmentez la valeur du compteur de dégradation pour le groupe "internal" à l'aide d'ifconfig(8):

# ifconfig -g internal
internal: carp demote count 0
# ifconfig -g internal carpdemote 50
# ifconfig -g internal
internal: carp demote count 50

Le pare-feu basculera les groupes carp1 et carp2 vers l'autre pare-feu du cluster tout en restant maître de carp3 et carp4. Si l'autre pare-feu commence à s'annoncer avec une valeur de dégradation supérieure à 50 ou s'il arrête d'effectuer des annonces, alors ce pare-feu prendra à nouveau le rôle de maître pour carp1 et carp2.

Pour revenir vers le pare-feu primaire, renversez les modifications :

# ifconfig -g internal -carpdemote 50
# ifconfig -g internal
internal: carp demote count 0

Des services réseau tels que OpenBGPD et sasyncd(8) utilisent le compteur de dégradation pour s'assurer que le pare-feu ne devienne maître que lorsque les sessions BGP ont été établies et les SAs IPsec ont été synchronisées.

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é]

[back] www@openbsd.org
$OpenBSD: carp.html,v 1.31 2013/01/28 09:28:24 ajacoutot Exp $