OBSD4* : wiki

Version de traduction basée sur la 6.4 officielle (v1.62 : 29/10/2018)


PF - Redondance de Pare-feu (CARP et pfsync)

Introduction à CARP

CARP est le Protocole Redondant d'Adresse Commune - Common Address Redundancy Protocol. Son but premier est de permettre à de multiples hôtes sur un même segment réseau de partager une adresse IP. CARP est sécurisé, une alternative libre au Protocole de Redondance de Routage Virtuel (VRRP - Virtual Router Redundancy Protocol) et au Protocole de Routage Hot Standby (HSRP - Hot Standby Router Protocol).

CARP fonctionne en permettant à un groupe d'hôtes sur le même segment réseau de partager une adresse IP. Ce groupe d'hôtes est appelé un “groupe de redondance”. Le groupe de redondance est assigné à une adresse IP qui est partagée entre les membres du groupe. Dans un groupe, un hôte est désigné “master” et le reste “backups”. L'hôte maître est celui qui couramment “capture” l'IP partagée ; il répond à tout trafic ou requête ARP dirigé vers lui. Chaque hôte peut appartenir à plus d'un groupe de redondance à la fois.

Une utilisation commune pour CARP est de créer un groupe de pare-feux redondants. L'IP virtuelle, qui est assignée au groupe de redondance, est configurée sur les machines clientes en tant que passerelle par défaut.

Dans le cas où le pare-feu maître subit une défaillance ou est déconnecté, l'IP se déplacera vers l'un des pare-feux de sauvegarde et le service continuera sans être affecté.

CARP supporte IPv4 et IPv6.

Opération CARP

L'hôte maître dans le groupe envoie des annonces régulières sur le réseau local afin que les hôtes de sauvegarde sachent qu'il est toujours en vie. Si les hôtes de sauvegarde n'entendent pas une annonce du maître pendant une certaine période de temps, alors un d'eux prendra la fonction de maître (quelque soit l'hôte de sauvegarde ayant les valeurs les plus basses advbase et advskew configurées).

Il est possible pour des groupes CARP multiples d'exister sur un même segment réseau. Les annonces CARP contiennent l'ID d'Hôte Virtuel qui permet aux membres du groupe d'identifier à quel groupe de redondance elles appartiennent.

Afin de prévenir qu'un utilisateur malicieux sur le segment réseau puisse manipuler les annonces CARP, chaque groupe peut être configuré avec un mot de passe. Chaque paquet CARP envoyé au groupe est alors protégé par un HMAC SHA1.

Puisque CARP a son propre protocole, il devrait y avoir une règle explicite de laisser passer dans le jeu de règles de filtrage :

  pass out on $carp_dev proto carp

$carp_dev devrait être l'interface physique sur laquelle CARP communique.

Configurer CARP

Chaque groupe de redondance est représenté par une interface réseau virtuelle carp(4). En tant que tel, CARP est configuré en utilisant 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) où N est un entier qui représente le numéro d'interface (ex. carp10).

vhid
L'ID d'Hôte Virtuel. C'est le numéro unique qui est utilisé pour identifier le groupe de redondance des autres nœuds dans le groupe, et de distinguer les groupes sur le même réseau. Les valeurs de 1 à 255 sont acceptables. Celui-ci doit être le même pour tous les membres du groupe.

password
Le mot-de-passe d'authentification qui est utilisé lors des discussions aux autres hôtes CARP activés dans le groupe de redondance. Cela doit être le même pour tous les membres du groupe.

carpdev
Ce paramètre optionnel spécifie l'interface réseau physique qui appartient au groupe de redondance. Par défaut, CARP essaiera de déterminer quelle interface est utilisée en cherchant l'interface physique qui est dans le même sous-réseau que la combinaison ipaddress et mask donnée à l'interface carp(4).

advbase
Ce paramètre optionnel spécifie combien d'annonces, en nombre de secondes, pour s'annoncer en tant que membre du groupe de redondance. La valeur par défaut est de 1 seconde. Les valeurs acceptables sont de 1 à 255.

advskew
Ce paramètre optionnel spécifie comment fausser advbase lors de l'envoi des annonces CARP. En manipulant advskew, l'hôte CARP maître peut être choisi. Plus le nombre est élevé, moins l'hôte sera préféré pour choisir le maître. La valeur par défaut est 0. Les valeurs acceptables sont de 0 à 254.

state
Force une interface carp(4) dans un certain état. Les états valides sont init, backup, et master.

group, -group
Ajouter ou supprimer une interface carp(4) dans un certain groupe d'interfaces. Par défaut, toutes les interfaces carp(4) sont ajoutées au groupe carp. Chaque groupe a un compteur carpdemote qui affecte toutes les interfaces carp(4) appartenant au groupe. Comme décrit ci-dessous, il peut être utile de grouper certaines interfaces ensemble à des fins de bascule.

ipaddress
C'est l'adresse IP partagée assignée au groupe de redondance. Cette adresse n'a pas à être dans le même sous-réseau que l'adresse IP de l'interface physique (si elle est présente). Cette adresse a toutefois besoin d'être dans le même sous-réseau que tous les hôtes du groupe.

mask
Le masque de sous-réseau de l'IP partagée.

Davantage de comportements CARP peuvent être contrôlés via sysctl(8).

net.inet.carp.allow
Accepte les paquets CARP entrants ou non. La valeur par défaut est 1 (yes).

net.inet.carp.preempt
Permet que les hôtes qui ont de meilleurs advbase et advskew dans le groupe de redondance à anticiper le maître. De plus, cette option active aussi de basculer sur un groupe d'interfaces en cas de panne d'une interface. Si une interface physique activée par CARP chute, CARP augmentera le compteur demotion, carpdemote, de 1 sur le groupe d'interfaces dont l'interface carp(4) est membre, ce qui aura pour effet de faire basculer tous les membres du groupe ensemble. net.inet.carp.preempt a pour valeur 0 (désactivé) par défaut.

net.inet.carp.log
Journalise les changements d'état, les mauvais paquets et les autres erreurs. Cette valeur peut être comprise entre 0 et 7, correspondant aux priorités de syslog(3). La valeur par défaut est 2 (juste les changements d'état).

Exemple CARP

Voici un exemple de configuration CARP :

  # sysctl net.inet.carp.allow=1
  # echo 'net.inet.carp.allow=1' >> /etc/sysctl.conf
  # ifconfig carp1 create
  # ifconfig carp1 vhid 1 pass mekmitasdigoat carpdev em0 advskew 100 10.0.0.1 netmask 255.255.255.0

Cela paramètre ce qui suit :

  • Active la réception des paquets CARP (c'est le paramètre par défaut).
  • Crée une interface carp(4), carp1.
  • Configure carp1 pour l'hôte virtuel #1, active le mot-de-passe, paramètre em0 en tant qu'interface appartenant au groupe, et fait de l'hôte un backup du fait qu' advskew ait la valeur 100 (en assumant bien-sûr que le maître soit paramétré avec une advskew plus petite que 100). L'adresse IP partagée, assignée à ce groupe, est la 10.0.0.1/255.255.255.0.

Exécuter ifconfig sur carp1 montre le status de l'interface :

  # 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 certain changements faits par la table d'état pf(4). En utilisant tcpdump(8) pour monitorer ce périphérique, 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 de changements d'état sur le réseau afin que d'autres nœuds exécutant PF puissent fusionner les modifications dans les propres tables d'état. De même, pfsync(4) peut aussi écouter sur le réseau pour les messages entrants.

Opération pfsync

Par défaut, pfsync(4) n'envoie pas ou ne reçoit pas les mises à jour des tables d'état sur le réseau ; toutefois, les mises à jour peuvent toujours être surveillées en utilisant tcpdump(8) ou d'autres outils similaires sur la machine locale.

Quand pfsync(4) est paramétré pour envoyer ou recevoir les mises à jour sur le réseau, le comportement par défaut est de diffuser des mises à jour sur le réseau local. Toutes les mises à jour sont envoyées sans authentification. La meilleure pratique est :

  1. De connecter les deux nœuds qui s'échangeront les mises à jour en utilisant un câble croisé et cette interface en tant que syncdev (voir ci-dessous).
  2. D'utiliser l'option syncpeer d'ifconfig(8) (voir ci-dessous) ainsi les mises à jour sont transmises en unicast directement vers le pair, puis configurer ipsec(4) entre les hôtes pour sécuriser le trafic de pfsync(4).

Quand les mises à jour sont envoyées et reçues sur le réseau, les paquets de pfsync devraient être passés par le filtrage du jeu de règles :

  pass on $sync_if proto pfsync

$sync_if devrait être l'interface physique sur laquelle communique pfsync(4).

Configurer pfsync

Puisque pfsync(4) est une interface réseau virtuelle, il est configuré en utilisant ifconfig(8).

# ifconfig pfsyncN syncdev syncdev [syncpeer syncpeer] [defer|-defer]

pfsyncN
Le nom de l'interface pfsync(4). pfsync0 existe par défaut lors de l'usage du noyau GENERIC.

syncdev
Le nom de l'interface physique utilisé par pfsync pour envoyer les mises à jour.

syncpeer
Ce paramètre optionnel spécifie l'adresse IP de l'hôte avec qui pfsync échange les mises à jour. Par défaut, les mises à jour de pfsync sont multi-diffusées sur le réseau local. Cette option surcharge le comportement et à la place envoie en mode unicast la mise à jour avec le syncpeer spécifié.

defer
Si le drapeau defer est utilisé, le paquet initial d'une nouvelle connexion passant par le pare-feu ne sera transmis tant qu'un autre système pfsync(4) n'a pas connaissance de l'ajout dans la table d'état ou qu'un délai n'aura pas expiré. Cela ajoute de petits délais mais permet au trafic de circuler quand plus d'un pare-feu peut gérer activement les paquets (“active/active”), ex. avec certaines configurations d'ospfd(8), bgpd(8) ou carp(4).

Exemple pfsync

Voici un exemple de configuration de pfsync :

  ifconfig pfsync0 syncdev em1 up

Cela active pfsync sur l'interface em1. Les mises à jour sortantes seront multi-diffusées sur le réseau permettant à tout autre hôte exécutant pfsync de les recevoir.

Combiner CARP et pfsync pour la bascule

En combinant les fonctionnalités de CARP et de pfsync, un groupe de deux pare-feux ou plus peuvent être utilisés pour créer un cluster de pare-feux hautement disponible et pleinement redondant.

CARP :
Gère la bascule automatique d'un pare-feu à l'autre.

pfsync :
Synchronise les tables d'état entre tous les pare-feux. Dans le cas d'une bascule, le trafic peut circuler de manière ininterrompue au-travers du nouveau pare-feu maître.

Un exemple de scenario : Deux pare-feux, fw1 et fw2.

       +----| WAN/Internet |----+
       |                        |
    em2|                        |em2
    +-----+                  +-----+
    | fw1 |-em1----------em1-| fw2 |
    +-----+                  +-----+
    em0|                        |em0
       |                        |
    ---+-------Shared LAN-------+---

Les pare-feux sont connectés l'un à l'autre en utilisant un câble croisé sur em1. Les deux sont connectés sur le LAN sur em0 et sur la connexion WAN/Internet sur em2. Les adresses IP 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
  • LAN IP partagée : 172.16.0.100
  • WAN/internet IP partagée : 192.0.2.100

La politique réseau est que fw1 sera le maître préféré.

Configurez fw1 :

  ! enable preemption and group interface failover
  # sysctl net.inet.carp.preempt=1
  # echo 'net.inet.carp.preempt=1' >> /etc/sysctl.conf
  
  ! 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

Configurez fw2 :

  ! enable preemption and group interface failover
  # sysctl net.inet.carp.preempt=1
  # echo 'net.inet.carp.preempt=1' >> /etc/sysctl.conf
  
  ! 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

Problèmes opérationnels

Quelques problèmes opérationnels communs sont rencontrés avec CARP/pfsync.

Configurer CARP et pfsync durant le démarrage

Puisque carp(4) et pfsync(4) sont deux types d'interfaces réseaux, ils peuvent être configurés au démarrage en créant le fichier hostname.if(5). Le script de démarrage netstart prendra soin de créer l'interface et de la configurer.

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

Forcer la bascule du maître

Il peut arriver parfois qu'il soit nécessaire de basculer ou de rétrograder le nœud maître à dessein. Les exemples incluent de faire tomber un nœud maître pour la maintenance ou le dépannage d'un problème. L'objectif ici est de basculer le trafic gracieusement vers l'un des hôtes de sauvegarde afin que les utilisateurs ne remarquent pas d'impact.

Pour basculer un groupe CARP particulier, arrêtez une interface carp(4) sur le nœud maître : cela obligera le maître à s'avertir lui-même avec une infinité d'annonces advbase et advskew. Le(s) hôte(s) de sauvegarde le verront et immédiatement prendront le rôle de maître.

  # ifconfig carp1 down

Une alternative est d'augmenter advskew à une valeur plus grande que celle sur l'hôte de sauvegarde. Cela obligera une bascule mais permettra toujours à ce que le maître participe au groupe CARP.

Une autre méthode de bascule est d'ajuster le compteur demotion CARP. Le compteur demotion est une mesure pour “rendre prêt” un hôte à devenir maître d'un groupe CARP. Par exemple, tandis qu'un hôte est en phase de démarrage, c'est une mauvaise idée pour lui de devenir le maître CARP jusqu'à ce que toutes les interfaces soient configurées, que tous les services réseaux soient démarrés, etc… Les hôtes annonçant une forte valeur demotion seront moins préférés pour être maître.

Un compteur demotion est enregistré dans chaque groupe d'interfaces auquel appartient l'interface CARP. Par défaut, toutes les interfaces CARP sont membres du groupe d'interface “carp”. La valeur courante du compteur demotion peut être vue en utilisant ifconfig(8) :

  # ifconfig -g carp
  carp: carp demote count 0

Dans cet exemple, le compteur associé au groupe d'interfaces “carp” est vu. Quand un hôte CARP s'annonce lui-même sur le réseau, il prend la somme des compteurs demotion de chaque groupe d'interfaces à laquelle appartient l'interface carp(4) et avertit que la valeur demotion devient la sienne.

Maintenant prenons l'exemple suivant. Deux pare-feux exécutant CARP avec les interfaces CARP suivantes :

  • carp1 - Service Comptabilité
  • carp2 - Employés réguliers
  • carp3 - Internet
  • carp4 - DMZ

L'objectif est de basculer juste les groupes carp1 et carp2 au pare-feu secondaire.

En premier, assignez chacune au groupe d'interfaces, dans ce cas nommé “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 le compteur demotion pour le groupe “internal” en utilisant 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 gracieusement sur les groupes carp1 et carp2 vers l'autre pare-feu dans le cluster bien que restant encore maître sur carp3 et carp4. Si l'autre pare-feu commence à annoncer lui-même une valeur demotion plus haute que 50, ou si l'autre pare-feu a arrêté de faire ses annonces, alors ce pare-feu prendra encore la maîtrise sur carp1 et carp2.

Pour revenir au premier pare-feu, inversez les changements :

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

Les services réseaux tels qu'OpenBGPD et sasyncd(8) utiliseront le compteur demotion pour s'assurer que le pare-feu ne devient pas maître jusqu'à ce que les sessions BGP soient établies et que les SA IPSec soient synchronisées.

Astuces de jeu de règles

Filtrer l'interface physique. Tant que PF est concerné, le trafic réseau vient de l'interface physique, non pas de l'interface virtuelle CARP (tel que, carp0). Ainsi, écrivez vos jeux de règles en accord. N'oubliez pas qu'un nom d'interface dans une règle PF peut être le nom d'une interface physique ou d'une adresse associée à l'interface. Par exemple, cette règle devrait être correcte :

pass in on fxp0 inet proto tcp from any to carp0 port 22

Mais remplacez fxp0 par carp0 ne fonctionnera comme désiré.

N'OUBLIEZ PAS de laisser passer proto carp et proto pfsync !

Autres références

Veuillez voir les autres sources pour plus d'informations :


Cette page est la traduction officieuse de la page “Firewall redundancy (CARP an pfsync) de la FAQ officielle d'OpenBSD.
En cas de doute, merci de vous y référer !

Si vous voulez participer à l'effort de traduction, merci de lire ce topic.