Haute disponibilité et publication

1. Qu’est-ce que la haute disponibilité ?

La haute disponibilité (High Availability - HA) permet d’assurer la continuité de service en cas de défaillance d’un nœud pfSense. Elle permet à un système de rester opérationnel en cas de panne d’un composant. Elle repose principalement sur l’utilisation du protocole CARP (Common Address Redundancy Protocol) pour le partage d’une adresse IP virtuelle, ainsi que sur la synchronisation des configurations via XMLRPC.

Pour pfSense, point d’entrée critique du réseau, une panne peut impacter toute l’entreprise. La haute disponibilité vise donc à garantir un service disponible en continu, même en cas de défaillance matérielle ou logicielle.

2. Enjeux de disponibilité et coût d’une panne

1. Principes du Multi-WAN

pfSense peut gérer simultanément plusieurs connexions internet (WAN) de types différents :

2. Failover et load balancing

1. Architecture HA

La haute disponibilité vise à garantir un service disponible en continu, même en cas de panne d’un composant. Elle passe par une architecture redondée et synchronisée en temps réel entre plusieurs nœuds. Pour les environnements critiques où la continuité de service est impérative, pfSense offre une architecture de haute disponibilité fondée sur un mécanisme de clustering. L’objectif est de garantir un basculement automatique quasi instantané entre deux pare-feu, sans perte de connectivité ni interruption perceptible.

Exemple avec pfSense en haute disponibilité

Deux pare-feu pfSense physiques, un nœud principal et un nœud secondaire, partagent une adresse IP virtuelle via CARP. Les configurations sont répliquées via XMLRPC, et les états des connexions sont synchronisés via pfsync. Si le nœud principal tombe, le nœud secondaire prend le relais en moins d’une seconde. Les connexions TCP actives sont préservées : le basculement est totalement transparent pour les utilisateurs.

2. Les composants : CARP, pfsync et XMLRPC

1. Prérequis techniques

Pour réaliser une configuration HA efficace, il faut réunir les éléments suivants :

Dans le cadre de cet ouvrage, les deux pare-feux sont nommés pfsense20 pour le nœud principal et pfsense37 pour le nœud secondaire. Le plan d’adressage retenu est le suivant, et il est utilisé de manière homogène dans tout le chapitre.

2. Configurer l’interface de synchronisation

Pour configurer l’interface de synchronisation, il est nécessaire de définir une interface dédiée, nommée ici SYNC sur les deux équipements, avec une adresse IP statique sur chaque nœud. Cette interface servira à la réplication de la configuration et à la synchronisation des états de connexion. Elle ne porte aucune passerelle et n’est routée vers aucun autre réseau.

Le nom d’hôte n’apparaissant pas sur les pages de configuration d’interface de pfSense, chaque capture est identifiée par sa légende.

Interface de synchronisation du nœud principal pfsense20

Interface de synchronisation du nœud secondaire pfsense37

1. Valider le basculement CARP

Avant de tester, le schéma suivant résume le processus de basculement.

Processus de basculement CARP

La validation se déroule ensuite en sept étapes, du contrôle statique vers le test en conditions réelles.

Nœud principal placé en maintenance CARP

Nœud secondaire MASTER

Une variante plus brutale consiste à couper physiquement l’interface WAN ou à débrancher le nœud principal. Elle valide en plus le comportement...

1. Sécuriser CARP, pfsync et XMLRPC

Lors de la configuration de la haute disponibilité avec CARP, il est nécessaire de définir un mot de passe partagé, le Virtual Host ID password. Ce mot de passe sécurise la communication entre les deux nœuds qui partagent une adresse IP virtuelle. Il en va de même pour la synchronisation XMLRPC, qui réplique automatiquement la configuration du pare-feu principal vers le nœud secondaire.

Il est impératif d’utiliser un mot de passe long, aléatoire et complexe, afin d’empêcher toute tentative d’injection, d’interception ou de synchronisation malveillante entre les deux pare-feux. Évitez absolument les mots de passe par défaut ou faciles à deviner.

Durcir les règles de l’interface SYNC

Les règles autorisant CARP, pfsync et XMLRPC ont été créées...

1. Combiner Multi-WAN et CARP

Dans une architecture Multi-WAN avec CARP, chaque nœud pfSense dispose de ses propres connexions WAN afin de garantir la redondance à la fois au niveau du pare-feu et au niveau des accès internet.

Le résultat est une protection contre la panne du serveur et contre la panne d’un lien internet. La disponibilité théorique atteint alors 99,99 %.

2. Déployer CARP avec plus de deux nœuds

CARP supporte plus de deux nœuds, mais cette configuration est rarement utilisée en pratique.

Si le nœud 1 tombe, le nœud 2 devient MASTER. Si le nœud 2 tombe à son tour, le nœud 3 prend le relais. Cette configuration est utile pour les environnements très critiques, notamment ceux qui visent un niveau de disponibilité proche de 99,999 %.

1. Rôle de HAProxy dans pfSense

HAProxy (High Availability Proxy) est un load balancer et reverse proxy open source, essentiel pour publier, sécuriser et répartir le trafic applicatif vers plusieurs serveurs internes. Dans pfSense, il permet de mettre en place un reverse proxy performant, capable de gérer les connexions HTTP et HTTPS, de répartir les requêtes entre plusieurs backends, de vérifier l’état des serveurs et de centraliser certaines fonctions comme la terminaison SSL. Il s’intègre ainsi naturellement dans les architectures où la disponibilité, la performance et la sécurité des services web sont des enjeux importants.

Le tableau suivant précise la différence entre load balancing réseau et load balancing applicatif.

Fonctionnalités principales de HAProxy

2. Cas d’usage et alternatives

1. Principe d’une DMZ en sandwich

La DMZ (DeMilitarized Zone), ou zone démilitarisée, joue le rôle de zone tampon entre Internet et le réseau interne. Elle accueille les services accessibles depuis l’extérieur tout en assurant leur isolement vis-à-vis des postes utilisateurs et des bases de données internes. Ainsi, même si un service en DMZ est compromis, l’attaquant reste bloqué et ne peut pas progresser facilement dans l’infrastructure.

Pour améliorer encore cette isolation, on peut mettre en place une architecture dite « en sandwich », reposant sur deux pare-feu pfSense distincts. Le premier est placé entre Internet et la DMZ, et contrôle les flux entrants. Le second est situé entre la DMZ et le réseau interne, et protège les services critiques ainsi que les utilisateurs.

2. Rôle des zones WAN, DMZ et LAN

Chaque zone de l’architecture a un rôle spécifique et des caractéristiques de sécurité particulières. Comprendre ces rôles est essentiel pour mettre en place des règles de filtrage appropriées.