I. Présentation
La tolérance de panne (aussi appelée Fail-Over) est un processus visant à assurer une disponibilité constante et continue d’éléments réseaux. Dans le cas de PfSense, le Fail-Over va nous permettre de faire travailler plusieurs Pfsense en les regroupant derrière une IP virtuelle unique. Derrière cette adresse IP unique se positionneront deux ou plusieurs Pfsense, le principe est alors que si l’un des Pfsenses tombe, un autre est présent pour prendre le trafic à sa place et ce de manière invisible pour l’utilisateur car la même IP virtuelle sera toujours utilisée.
Le fail-over peut ici être utilisé pour les interfaces coté WAN comme coté LAN. On retrouvera le même principe de fonctionnement que les protocoles HSRP (Cisco) ou GLBP et VRRP pour les autres vendeurs réseaux.
II. Protocole CARP
Le protocole CARP (Common address redundancy protocol) est le protocole utilisé par Pfsense pour la mise en place d’un Fail-over, notons qu’il peut être utilisé par de nombreux systèmes OpenBSD, FreeBSD et également Debian/CentOS via UCARP. CARP est un protocole travaillant sur les couches 2 et 3 du modèle OSI. Dans son fonctionnement, on met dans un groupe plusieurs hôtes (groupe de redondance) qui partageront alors une même adresse IP et auront une adresse MAC dite “virtuelle”. Derrière cette adresse IP qui sera virtuelle se cacheront deux ou plusieurs hôtes parmi un maître qui prendra et traitera l’intégralité des requêtes en destination de l’IP virtuelle. Les hôtes du réseaux communiqueront entre eux afin de vérifier que le maître est toujours actif, s’il vient à tomber, l’hôte désigné comme esclave prendra le relais afin d’accueillir et de traiter le trafic en destination de l’adresse IP Virtuelle.
Ce genre de fonctionnement permet, si une passerelle tombe par exemple, de garder la même configuration en utilisant une passerelle physiquement différente car les deux ou plusieurs hôtes se “cacheront” derrière une IP unique. CARP est une alternative sécurisée aux protocoles HSRP ou VRRP car il implémente le SHA1-HMAC lors de ses échanges (appelé advertisment). Ceci bloquant, s’ils sont interceptés par un pirate, leur lecture et leur compréhension qui pourrait révéler des informations importantes sur le réseau.
Il est à noter que CARP supporte l’IPv4 et l’IPv6 et qu’un même hôte peut faire parti de plusieurs groupes de redondance à la fois.
III. Pfsync
Nous avons vu d’un peu plus près le protocole qui allait permettre à nos hôtes de se répartir les tâches dans le Fail-Over, Pfsense utilise également le protocole Pfsync dans son processus de mise en place du Fail-Over, Pfsync est un protocole utilisé pour synchroniser plusieurs machines exécutant le firewall Packet Filter, implémenté dans Pfsense.
Plus précisément, c’est par ce protocole que nous allons pouvoir gérer plusieurs hôtes via une seule interface, il fera en sorte par exemple de diffuser les états de connexion (fermée, ouverte, établies, …) entre le routeur maître et les routeurs esclaves permettant ainsi une reprise des états de connexions en cas de panne du maître et de reprise de l’esclave. Pfsync est un des composants essentiels de la mise en place d’un haute disponibilité sous Pfsense.
Les messages pfsync sont envoyés en mulicast, il est recommandé de mettre une interface dédiée au pfsync par soucis de sécurité. En effet, en étant à l’écoute sur ce canal multicast, un pirate peut recevoir les messages de créations, de mise à jour et de suppression des états de connexions et pourrait même se faire passer pour un routeur en envoyant des paquets pfsync afin de perturber le bon fonctionnement du Fail-Over.
IV. Configuration
Nous allons maintenant passer à la mise en place et la configuration de notre Fail-Over. On suivra le schéma suivant :
Schéma de départ, on dispose donc de deux Pfsense qui distribuent le réseau du LAN vers le WAN.
Nous allons donc ici faire en sorte de mettre en Fail-Over nos deux Pfsense de manière à ce que si l’un tombe, l’autre prenne le relais. Il partageront une IP virtuelle que nous configurerons. Le Pfsense Maître sera “Pfsense 1” et le Pfsense Esclave sera le “Pfsense 2“.
A. Ajout d’une interface Pfsync
Il est fortement recommandé, pour des raisons de sécurité comme indiqué un peu plus haut dans le tutoriel, de dédier un lien physique et une interface par hôte à la liaison pfsync. Nous allons donc, sur nos deux hôtes, suivre la procédure de création d’une interface que nous allons voir, pour la mise en place de ce nouveau lien, nous suivrons le schéma suivant :
On établie un lien Pfsync entre nos deux Pfsense
On se rend donc sur l’interface d’administration de notre Pfsense 1, il faut alors aller dans “Interfaces” puis “assign” :
Ajout d’une interface sous Pfsense
On va alors cliquer sur le petit formulaire avec un”+” qui va nous permettre d’ajouter une interface. Si cet icône n’apparaît pas, c’est que votre interface n’est pas détectée par le système, il faudra alors probablement le redémarrer :
Ajout d’une interface sous Pfsense
Une fois cette opération effectuée, on pourra voir notre nouvelle interface (nommée “OPT1″), il faudra alors l’assigner à une interface physique, on identifiera cette interface par son adresse MAC ou par le numéro qui lui est affecté par rapport à ceux déjà attribués, une fois la sélection faite, il faut cliquer sur “Save” en bas du tableau :
Assignation d’une interface physique
Nous allons ensuite cliquer sur le nom de notre interface OPT1 pour la configurer. On va commencer par cocher la case “Enable Interface” puis nous allons saisir les champs “Description, sélectionner “Static IPv4″ dans “IPv4 Configuration Type” et saisir l’IPv4 de notre interface dans la section “Static IPv4 Configuration” :
Configuration d’une nouvelle interface Pfsense
On validera en cliquant sur “Save” en bas de page. Par sécurité, Pfsense nous demande d’appliquer les changements, on cliquera donc sur “Apply changes” :
Demande d’application des modifications de la nouvelle interface
Cette procédure de création d’adresse est à répéter sur le deuxième Pfsense en adaptant l’IP bien entendu.
B. Activation de la synchronisation Pfsync
Maintenant que nos interfaces dédiées Pfsync sont prêtes, il va falloir les utiliser. On va pour cela aller dans “Firewall” puis dans “Virtual IPs” et enfin sélectionner l’onglet “CARP settings“. Sur le maître et sur l’esclave, nous cocherons “Synchronize States”. On va ensuite sélectionner “PFSYNC” comme interface de synchronisation (“Synchronize interface”), pour avoir un peu plus de sécurité, nous pourrons renseigner l’IP de l’interface Pfsync de l’hôte d’en face pour éviter les envois en multicast dans “pfsync Synchronize Peer IP”.
Pour le bloc XMLRPC Sync, on va cocher pour les deux hôtes les cases suivantes :
- Synchronize Firewall Schedules
- Synchronize rules
- Synchronize NAT
- Synchronize aliases
- Synchronize NAT
- Synchronize Static Routes
- Synchronize Virtual IPs
- Synchronize traffic shaper(queues)
- Synchronize traffic shaper(limiter)
- Synchronize traffic shaper(layer7)
Cela va permettre au maître d’envoyer les informations de routages, de filtrage et de translation à son ou ses esclaves afin qu’ils les récupèrent en direct et en état si celui-ci a un dysfonctionnement. Enfin, uniquement sur le Maître, nous allons renseigner l’IP de l’interface pfsync de l’esclave dans “Synchronize Config to IP” ainsi que le login et mot de passe. Étant donné que c’est le maître qui se synchronise vers l’esclave et non l’inverse, ce dernier paramétrage n’est pas à effectuer sur l’esclave :
Ajout du coté Pfsense Maître pour qu’il puisse envoyer les commandes de mises à jours à son esclave
On cliquera bien sur “Save” en bas de page pour valider :
Nous allons maintenant passer à la création de notre IP virtuelle, dans notre cas ce sera 10.1.2.5/28. La configuration n’est a effectuer que sur le maître du cluster qui, via le lien pfsync établie précédemment, va ensuite diffuser la configuration à ses esclaves. On va aller dans “Firewall” puis dans “Virtual Ips” et on va cliquer sur le petit “+” à droite du tableau pour créer notre adresse virtuelle :
Création de l’IP virtuelle du cluster
Ici, nous allons devoir choisir le protocole de synchronisation que nous souhaitons utiliser, CARP dans notre cas. Puis l’interface coté interface virtuelle, c’est à dire sur quel réseau va se situer l’IP virtuelle que nous souhaitons affecter au cluster, nous allons partir sur l’IP 10.1.2.5 qui sera donc du coté LAN, on sélectionnera donc “LAN” puis on saisira l’adresse IP virtuelle de notre cluster. On saisira également un mot de passe de groupe qui permettra de sécuriser les échanges ainsi qu’un numéro VHID (Virtual Host Identifier). On pourra également spécifier les valeurs de temps de synchronisation :
Par défaut, des règles sont mises en place pour bloquer certains trafics, étant donné que les liens Pfsync sont des interfaces uniquement dédiées à ce protocole, il ne sert à rien de mettre de filtrage particulier dessus (dans le cas d’une liaison non direct, on pourrait néanmoins l’envisager pour laisser passer uniquement le protocole Pfsync). On va donc se rendre dans “Firewall” puis dans “Rules” et on ira sélectionner l’interface “Pfsync” sur les deux hôtes :
Ajout d’une règle dans le Firewall pour les interfaces pfsync des deux hôtes
On va ajouter une règle permettant de tout laisser passer, il faudra pour cela simplement s’assurer de sélectionner “Pass” dans le premier champ puis dans le bas du formulaire sélectionner “any” au niveau des ports :
V. Vérification
Une fois que ces deux règles seront en place, les hôtes vont commencer à échanger sur leurs états et le maître va envoyer la configuration à son esclave. On pourra donc, sur cet esclave, aller voir si les configurations faites sur le maître sont présentes. On va par exemple aller dans “Firewall” puis dans “Virtual IPs” pour voir que l’esclave à bien la configuration de l’IP virtuelle que nous avons configurée sur le maître :
Configuration de l’IP virtuelle du cluster poussée par le maitre sur l’esclave
Dans un second temps, on pourra sur le maître et sur l’esclave (aussi appelé “backup” dans pfsense) aller dans “Status” puis dans “CARP (Fail-Over)” pour voir que les rôles sont bien affectés, par exemple l’aperçu que l’on aura sur l’esclave :
On voit ici sur le Pfsense esclave qu’il a bien le rôle de routeur “backup”, c’est à dire celui qui va prendre le relais en cas de défaillance du maitre.
Enfin, nous pouvons faire un test fonctionnel, nous allons pinguer l’IP virtuelle du cluster puis couper le Maître pour voir que l’IP virtuelle répond toujours et que l’esclave a bien pris le relais du cluster :
On voit donc la perte d’un paquet ICMP qui correspond au temps que le cluster met à réagir pour réaffecter le rôle de maître à l’esclave qui va alors gérer le trafic en attendant le retour du maître.
