Plan du site  
pixel
pixel

Articles - Étudiants SUPINFO

Mise en place de serveurs web en haute disponibilité avec HAProxy et pfSense

Par Samuel RENGASSAMY Publié le 26/10/2017 à 00:21:36 Noter cet article:
(0 votes)
Avis favorable du comité de lecture

I - Introduction

La plupart des routeurs domestiques proposent de base de nombreuses fonctionnalités. Parmi ces fonctionnalités on peut retrouver des fonctionnalités de pare-feu. Le problème avec ces routeurs est qu’ils n’intègrent que des fonctionnalités basiques pour un usage basique du périphérique et ne permettent pas de mettre en place une solution poussée.

C’est pourquoi en milieu professionnel on a tendance à se tourner vers des pare-feu et routeurs intégrant des fonctionnalités beaucoup plus poussées, permettant alors aux administrateurs réseaux de mieux sécuriser leur réseau et de fournir une meilleure qualité de service à leurs clients.

La plupart de ces solutions sont assez onéreuses alors que parfois peu de fonctionnalités sont réellement utilisées.

Dans cet article, nous allons voir comment mettre en place un routeur/pare-feu avec des fonctionnalités d’équilibrage de charge pour permettre l’accès à des serveurs web à l’aide de pfSense et HAProy.

II - Pare-feu

Pour faire simple, un pare-feu permet de sécuriser un réseau. Cependant, il faudra noter que les pares-feux connaissent certaines vulnérabilités lorsque les communications sont cryptées.

Par exemple, il est possible de filtrer certains sites ou mots-clés avec un pare-feu lorsque que ceux-ci passent par le protocole HTTP (port 80) car la requête est envoyée en clair et le pare-feu peut donc avec aise analyser toutes les données la composant.

En revanche si le trafic passe par le protocole HTTPS (port 443) via le protocole SSL (ou plus récent TLS), les données ne seront plus envoyées en clair, mais seront bel et bien chiffrées, rendant possible son décryptage uniquement par l’intermédiaire d’un certificat numérique. Nous ne détaillerons pas plus si ce n’est que pour dire que le client déchiffre les données reçues par le serveur grâce à la clé envoyée et le serveur de même, déchiffre les données envoyées par le client grâce à la clé de décryptage envoyée par celui-ci.

Par conséquent, une règle de pare-feu permettant de bloquer le mot-clé « facebook », sera inutile si le client y accède depuis https://facebook.

Néanmoins, il faut savoir qu’il reste malgré tout certaines solutions pour filtrer le trafic sécurisé. La solution la plus simple étant de bloquer le protocole HTTPS, vous l’aurez compris, quasiment tous les sites utilisent ce protocole et n’est donc pas viable, il est également possible de bloquer le trafic au niveau de la résolution DNS, cependant cette méthode reste peu flexible car elle demande la saisie manuelle des noms de domaine et dans le cas de la restriction de multiple enregistrements DNS, cela peut vite devenir une tâche fastidieuse.

.

Heureusement, plusieurs solutions existent et certains pares-feux intègrent une fonctionnalité de relayeur DNS permettant de réaliser un filtrage plus poussé en servant d’intermédiaire entre DNS et client. Bien évidemment de multiples autres techniques existent.

La plupart des pare-feu récents comme pfSense embarquent également de nombreuses fonctionnalités comme la possibilité de créer des tunnels, servir de proxy et bien d’autres.

III - Proxy

Un serveur mandataire ou serveur proxy, est un serveur jouant le rôle d’intermédiaire dans un réseau informatique ayant pour but de relayer des requêtes entre un client et un serveur.

Un serveur proxy possède de nombreuses fonctionnalités et permet entre autres de stocker en mémoire des données pour accélérer la navigation etc.

Tout comme un pare-feu, un proxy permet également de sécuriser un réseau en réalisant un filtrage et permet aussi de contourner un filtrage par exemple lors de l’accès à un site internet où seules certaines adresses IP publique sont autorisées, en passant par un proxy se trouvant dans un pays dont l’adresse IP publique est autorisée, un utilisateur peut facilement contourner cette restriction.

Bien évidemment, il reste possible de refuser la connexion à un serveur proxy effectuant une requête mais cela demande une saisie manuelle de chaque entrée.

Les proxys permettent également la connexion à un serveur de façon totalement anonyme, diminuant le risque de traçabilité, toutefois il est toujours possible de bloquer une requête anonyme avec un pare-feu.

IV - PfSense et HAProxy

PfSense est un routeur/pare-feu open source basé sur le système d’exploitation FreeBSD (Système d’exploitation UNIX libre). Comme tout pare-feu, il permet de créer des règles de trafic sur le réseau et permet entre autres d’avoir un contrôle sur les flux entrants et sortant.

Il peut également permettre de créer une connexion sécurisée entre deux hôtes via un tunnel IPSec ou encore via VPN.

pfSense intègre de nombreuses fonctionnalités tel que le proxy inversé qui contrairement au serveur proxy basique, permet aux utilisateurs internet d’accéder à un réseau interne mais pas que !

Un proxy inverse peut aussi avoir des fonctionnalités de répartition de charge entre divers serveurs, qui par définition permet d’éviter à un serveur d’être surchargé par un nombre de requêtes.

.

Dans cet article nous n’utiliserons pas la fonctionnalité de proxy inverse de pfSense mais celle de HAProxy (High Availability Proxy), qui est beaucoup plus rapide dans la gestion des requêtes et la répartition de charge.

Dans le cadre de la haute disponibilité, la répartition de charge est une étape très importante car elle permet d’assurer la continuité de services car si un serveur venait à recevoir énormément de requêtes il y a de fortes chances que le délai de réponse soit beaucoup plus long et dans le pire des cas, qu’il tombe.

V - Topologie

Dans cet article nous allons permettre à un client d’accéder à un serveur web distant situé dans un réseau interne. Les clients passeront donc par les pare-feu/proxy inversés pour accéder à un serveur web.

Nous utiliserons HAProxy pour s’occuper de la répartition de charge entre les deux serveurs web afin de permettre de multiples connexions simultanées sans engendrer de perte de performance.

Dans votre logiciel de virtualisation, créez deux sous réseaux, l’un ayant accès à Internet et l’autre non. Dans mon cas sous VMWare, j’ai créé un sous-réseau NAT pour simuler l’accès Internet et un autre en Host-Only.

VI - Installation

Pour cet article nous utiliserons une machine virtuelle pfSense, et deux distributions linux, nous utiliserons Debian.

VI.1 - Pare-feu pfSense

Notre premier serveur pfSense fera l’interface avec le client, le client accède aux serveurs web situés à New York ou Texas de façon transparente.

La dernière version en date est le 2.4 sortie récemment, on peut la retrouver via ce lien pour la télécharger en 32 ou 64 bits. : https://www.pfsense.org/download/

Si vous avez un processeur supportant le jeu d’instructions 64 bits, préférez la version AMD64 pour obtenir de meilleures performances.

Préférez l’ISO pour procéder à l'installation directement.

En termes de configuration requise, je fais tourner Pfsense sur une VM disposant d'un processeur, 512 Mo de RAM et 8Go de disque, Pfsense se contente de très peu, nous le verrons plus loin.

Lors de la configuration de la machine virtuelle, veillez à ce qu’il y ait deux adaptateurs réseaux.

.

Le premier servira à l’interface WAN, on aura une carte permettant d’accéder à Internet, ici on utilisera du NAT et en LAN une carte réseau qui nous permettra d’administrer localement notre serveur, pour cet adaptateur, créez un réseau privé. Par défaut l’administration depuis l’interface WAN est désactivée car il serait dommage d’accorder à un tiers d’administrer notre routeur.

Lors du démarrage de l'ordinateur avec le CD ou l'ISO monté, un menu de boot apparaît. Selon les besoins on peut choisir de démarrer Pfsense avec certaines options activées. Si aucune touche n'est appuyée, Pfsense bootera avec les options par défauts (choix 1) au bout de 8 secondes.

L'installation démarre, dès le premier écran nous pouvons régler différents paramètres notamment la police le type de clavier que l’on utilisera, ici on choisira notre clavier français AZERTY.

Après avoir sélectionné le clavier, il est possible de le tester en choisissant Test puis si cela vous convient, sélectionnez Continue.

Dans l’écran qui suit, choisissez Auto(UFS) si vous ne voulez pas partitionner de façon particulière le disque dur pour passer à la suite.

Si tout s’est correctement passé, dans l’écran qui suit choisissez NO puis REBOOT pour redémarrer la machine.

Une fois la machine redémarrée, vous arriverez à cet écran

Nos deux cartes réseaux sont bien reconnues, par défaut, une interface leur est automatiquement affectée, pour vérifier que vos interfaces correspondent bien à la bonne carte réseau, entrez 1. Vous verrez alors dans l’écran qui suit, l’adresse MAC correspondante à chaque interface.

Si cela correspond bien, faites simplement Ctrl + C pour annuler. Sinon vous entrez le nom de l’interface correspondante

De retour au menu sélectionnez 2 pour configurer les adresses IP des adaptateurs réseaux.

Si vous obtenez une adresse IP de façon automatique depuis votre fournisseur, laissez l’interface WAN en DHCP, par défaut l’adresse IP publique est renouvelée automatiquement auprès de votre fournisseur d’accès internet sauf si vous avez demandé à ce qu’elle soit statique car en effet, en situtation réelle un utilisateur accède à un site Internet depuis son nom de domaine et non par IP.

Dans cette démonstration nous allons affecter une adresse IP à notre interface WAN et LAN.

Je rappelle que dans mon cas, mon réseau Internet est le 192.168.11.0/24 et mon réseau LAN 192.168.136.0/24

Mon interface WAN a pour IP 192.168.11.3, de masque 255.255.255.0 et bien évidemment, il ne faut pas oublier d’indiquer la passerelle par défaut pour l’accès extérieur.

Si vous ne la connaissez pas, repassez en DHCP, vous pourrez configurer l’IP statique plus tard. Sous VMWare, allez dans Virtual Network Editor et cliquez sur NAT Settings.

Réitérez la procédure cette fois-ci pour configurer l’interface LAN. Notez que contrairement à l’interface WAN, il ne vous est pas proposé d’affecter une IP de manière automatique.

L’interface LAN est configurée avec l’adresse 192.168.136.3/24

Nous pouvons maintenant administrer notre serveur pfSense !

Par défaut le login est admin et le mot de passe pfsense

Si votre interface WAN est bien configurée, vous aurez en page d’accueil, un message vous indiquant de quand a eu lieu la dernière recherche de mise à jour.

Etant donné que nous avons affecté une adresse IP de réseau privé à notre interface WAN (voir https://tools.ietf.org/html/rfc1918) , il nous faudra autoriser l’utilisation de celle-ci. Par défaut, une adresse IP dite publique est une adresse IP n’ayant pas comme préfixe 192.168, 172.16 ou 10/8.

Pour cela rendez-vous dans les paramètres de l’interface

Et désélectionnez l’avant dernière option, sauvegardez, puis appliquez.

Si vous n’êtes pas en DCHP, le serveur DNS permettant au réseau interne de communiquer avec l’extérieur n’est pas défini, il faudra le définir, dans System>General Setup. Appliquez et sauvegardez.

C’est tout pour cette partie, nous reviendrons plus tard dessus pour configurer notre load balancer.

VI.2 - Serveurs web

Nous allons maintenant passer à la configuration de nos serveurs web.

Dans cet article on utilisera Debian pour son côté universel, vous trouverez l’iso à cette adresse : https://www.debian.org/CD/http-ftp/

Lors de la création de la machine virtuelle, affectez un adaptateur réseau à la machine de sorte à ce qu’elle soit sur le même réseau local que l’adaptateur réseau local de notre pfSense.

Notre interface WAN fait partie du réseau 192.168.136.0/24.

Après avoir défini les paramètres linguistiques et les paramètres utilisateurs ainsi que le partitionnement du disque, le système téléchargera le reste des fichiers nécessaires.

Vous serez amenés à configurer le réseau, ce même si vous aviez activer le service DHCP sur l’interface LAN du routeur. La principale raison est que pfSense demande en LAN de ne pas saisir de passerelle par défaut.

Vous pouvez être confrontés à cet écran, choisissez Non et configurez comme ci-dessous.

Vous pouvez également avoir un autre message d’erreur indiquant qu’il est impossible d’accéder au serveur FTP. Retournez dans le menu et choisissez Configurer le réseau, puis Configurer le réseau moi-même

Suivez l’assistant, entrez une adresse IP disponible sur le réseau local, en passerelle par défaut, mettez l’adresse locale du pare-feu pfSense, et en DNS pareil.

Une fois que les paquets téléchargés, installez un serveur web.

https://doc.ubuntu-fr.org/installer_un_serveur_debian

Nos deux serveurs web auront respectivement les adresses IP 192.168.136.4/24 et 192.168.136.5/24

Vous pouvez vérifier vos paramètres en tapant la commande

nano /etc/network/interfaces

VI.3 - Répartition de charge

Maintenant que nos deux serveurs web et notre pfSense installés, nous allons maintenant passer à la partie de l’équilibrage de charge.

Comme je l’ai expliqué plus haut, l’objectif d’une répartition de charge est avant tout de permettre aux différents serveurs d’un réseau faisant partis d’un même pool de ne pas être surchargés pour permettre aux clients finaux d’avoir un service avec de très faibles délais de réponse lors de l’envoi d’une requête.

.

Pour mettre en place le load balancing, il vous faudra télécharger le paquet HAProxy pour pfSense.

Rendez-vous alors à la page de gestion des paquets située dans le menu System > Package Manager

Le Package Manager permet l’installation de différents paquets conçus pour être utilisés et accessibles directement depuis l’interface d’administration de pfSense.

Pour installer un nouveau paquet, il suffit de cliquer sur l’onglet Available Packages et de rechercher le paquet souhaité.

NB : La liste des paquets présents dans le package manager est une liste non exhaustive du nombre de paquets existants pour pfSense. Seuls les paquets vérifiés sont disponibles depuis le package manager. https://doc.pfsense.org/index.php/Installing_FreeBSD_Packages

Une fois le paquet HAProxy installé vous aurez un récapitulatif qui s’affichera, vous indiquant les différentes étapes de l’installation. En cas d’échec, vérifiez que l’interface WAN ait bien accès à Internet et que le serveur distant contenant les différents paquets soit à jour et bien configuré.

Vous constaterez alors qu’une nouvelle option HAProxy a fait son apparition dans le menu Services

Il ne reste plus qu’à configurer notre répartiteur de charge !

VII - Configuration

VII.1 - Backend

Dans l’onglet Backend, cliquez sur le bouton Add, puis ajoutez affectez un nom à ce Backend.

Le Backend permet de définir la liste des serveurs qui seront sujets au balancement et définir son algorithme.

Inutile de dire que plus il y aura de serveurs, meilleure sera répartie la charge.

.

Dans la partie Server list, ajoutez un serveur à balancer en cliquant sur la petite flèche.

Le mode active, indique que le serveur sera utilisé dans le balancement.

Le mode backup, indique que le serveur sera utilisé lorsque les autres serveurs seront indisponibles. Par exemple, si jamais tous vos serveurs tombent, pour ce serveur de backup pourrait afficher une version plus ancienne de vos fichiers, il servira de failover.

Le mode inactive, indique que le serveur ne sera pas utilisé.

Nos serveurs web tournant sur le port 80, nous ne configurerons pas les options SSL. On laissera également le champs Weight vide car nos deux serveurs ont les mêmes capacités. En revanche si l’on avait un serveur plus puissant que l’autre, le champs Weight deviendrais utile dans la mesure ou plus sa valeur est élevée, plus le nombre de requêtes qu’il recevra sera élevé par rapport aux autres serveurs du pool.

Ensuite il nous faudra sélectionner un mode de balancement.

En choisissant :

  • None : S’il n’y a qu’un seul serveur ou si vous voulez passer en avancé.

  • Round robin : Les requêtes seront balancées aux serveurs web chacun leur tour. C’est le plus simple

  • Static round robin : Utilise moins de ressources que Round robin basique, la seule différence c’est que si jamais vous voulez modifier à chaud le poids d’un des serveurs, il ne sera pas pris en compte.

  • Least Connections : Le serveur qui a le moins de requêtes redirigés vers lui sera privilégié lors du round robin sur les différents groupes de serveurs. Recommandé pour de longues sessions.

  • Source : HAProxy vérifie l’adresse IP du client pour lui permettre d’atteindre toujours le même serveur. Recommandé lorsque les clients refusent les cookies.

Nous utiliserons le Round Robin pour cet article.

Plus bas, vous avez également la possibilité de créer des ACL (Acces Control List). Les ACL permettent de réaliser des actions en fonction de certaines conditions (exemple : bloquer une requête, sélectionner un serveur, vérifier une authentification), etc.

Expliquer le fonctionnement des ACL serait trop long, pour plus d'informations sur les ACL, vous pouvez consulter cette adresse  : https://www.haproxy.com/documentation/aloha/7-0/haproxy/acls/

Ensuite, vous avez la possibilité de gérer la façon dont laquelle vous voulez que HAProxy vérifie que chacun des serveurs soient disponible au balancement.

A intervalle régulier le service se chargera de vérifier que les serveurs sont bien actifs pour ne pas renvoyer un client à un serveur non opérationnel.

HAProxy n’est pas limité aux serveurs web ! Vous pouvez tout à fait faire du balancement entre des serveurs MySQL par exemple et HAProxy se chargera de vérifier que la connexion à la base de données est bien disponible. Dans notre cas, on choisira le protocole HTTP.

Vous pouvez définir ensuite un intervalle de vérification. Par défaut pour http, l’intervalle est de 1 seconde.

Après vous pouvez indiquer la méthode qui sera utilisée pour tester la disponibilité du serveur en fonction du protocole défini plus haut.

Et enfin, par défaut HAProxy envoie une requête à la racine du serveur défini, si par exemple vous voulez que HAProxy pointe sur http://serveur_web/test plutôt que http://serveur_web/ indiquez le dans le champ correspondant.

A la fin de la page vous trouverez une section Statistics. Cela permet depuis l’IP définie dans le frontend de consulter les statistiques.

.

NB : En production il est recommandé de définir une authentification pour l’accès à cette page dans les options suivantes ou tout simplement de ne pas cocher cette case.

VII.2 - Frontend

Maintenant que notre Backend est configuré, le plus important reste la configuration du frontend.

Le frontend vous permet d'indiquer à HAProxy la façon dont laquelle les requêtes doivent être gérées.

Pour cela, cette fois-ci on va cliquer sur l’onglet frontend et cliquer sur Add.

Comme pour le backend, donnez un nom au frontend, puis dans Status, choisissez Active pour indiquer qu’il sera actif sinon la configuration ne sera pas chargée par HAProxy lors du démarrage du service.

Au niveau du champs External address, vous avez la possibilité de choisir l’adresse à laquelle ce frontend fonctionnera. On choisira WAN address (IPv4), port 80.

Plus bas vous avez la possibilité d’indiquer le nombre maximal de connexions que doit supporter ce frontend, dans le type on choisira http.

Comme pour le backend, il est possible de créer des ACL. Au niveau frontend cela peut vous permettre d’effectuer divers contrôles. Par exemple, si votre site web est en HTTPS et que le client renvoie un certificat HTTPS erroné, vous avez la possibilité de lui affecter backend autre que celui par défaut. Il est également possible de rediriger la requête ou tout simplement la refuser.

Encore une fois, nous ne détaillerons pas plus les ACL car on ne les utilisera pas, cependant sachez qu’il est aussi possible de créer des ACL personnalisés.

A la section Default Backend, on choisira le backend que l’on vient de créer.

Plus bas encore, vous avez une section Avancée avec diverses options où vous pourrez activer « forwarfor » pour renvoyer l’IP originale du client.

Sans cette option, l’adresse IP du serveur pfSense sera renvoyée aux serveurs de balancement en tant qu’adresse client, cela peut être utile si vous voulez vérifier que la requête est au préalable passé par le pare-feu.

Sauvegardez et appliquez les changements.

Maintenant que la configuration est terminée rendez-vous dans l’onglet Settings, et cochez la case Enable HAProxy.

Plus bas vous avez la possibilité de définir le nombre de connexions que HAProxy supportera, il s’agit du nombre total de requêtes qui passeront par le service HAProxy. Ces connexions clientes seront gardées en mémoire.

Par exemple pour 10 000 connexions, HAProxy allouera un minimum de 488 Mo de mémoire.

Pour terminer cochez la case Reload Behaviour. Si vous vous souvenez, lors de l’installation j’avais énoncé le fait qu’une interface WAN possède une IP publique et que sauf cas spécial, cette IP était renouvelée auprès du fournisseur d’accès internet après expiration du bail.

En cochant cette case, on indique à HAProxy qu’il doit arrêter tous les processus lorsqu’un changement d’adresse IP est détecté et ce sur n’importe quelle interface.

Si jamais vous veniez à modifier votre IP Statique et que le service tourne, il serait également intéressant d’arrêter les processus en cours sinon HAProxy aura une mauvaise configuration et les requêtes seront mal interprétées.

Sauvegardez les changements et appliquez pour démarrer les services HAProxy.

VII.3 - Stats

HAProxy permet d'accéder aux statistiques du service depuis l'interface de pfSense, pour ce faire lorsque vous vous rendez dans le service HAProxy, cliquez sur l'onglet Stats.

Ces divers stats vous serviront à avoir plus d'informations sur l'état des serveurs ainsi que celui du service.

Parmi ces stats vous pourrez entre autres savoir :

  • Si les serveurs sont disponibles et si le la méthode de check fonctionne correctement

  • La quantité de ressources utilisées par le service

  • Un bref résumé de votre configuration de front end et backend

  • Un bref resumé des paramètres généraux si l'option a été activée.

Vous avez remarqué qu’il y avait un formulaire en bas de page ?

HAProxy vous donne la possibilité d’agir sur vos serveurs depuis cette page.

Vous avez la possibilité de :

  • Modifier l’état d’un serveur

  • Modifier son statut

  • Supprimer les sessions existantes

Ces modifications n’auront aucun impact sur vos serveurs balancés. Ces modifications affecteront uniquement le comportement de HAProxy. Si par exemple vous passez l’état d’un serveur à MAINT, il passera en mode maintenance et HAProxy ne redirigera plus de requêtes vers ce serveur.

Cela vous permettra de rendre virtuellement un serveur indisponible sans avoir à toucher à vos configurations.

Place au test !

VII - Tests

Pour cette dernière partie, nous allons tester notre solution.

Nous avons vu que nos serveurs sont bien à l’état READY et sont en ligne depuis notre page de statistiques. Nous avions également configuré le frontend pour qu’il puisse écouter sur l’interface WAN des nouvelles connexions avant de les rerouter.

Pourtant, lorsque l’on accède à l’adresse IP supposée publique du serveur pfSense, rien ne se passe.

En tant que pare-feu, pfSense refuse logiquement toute requêtes venant de l’extérieur, mais si on ne peut pas y accéder pourquoi avoir fait tout cela me direz-vous.

Eh bien n’oublions pas qu’il s’agit d’un pare-feu ! Pour autoriser les requêtes venant de l’extérieur, il faut donc créer une règle.

Pour cela dans le menu Firewall, vous trouverez un sous menu Rules et c’est ici que nous allons définir nos règles de pare-feu.

Par défaut, une seule règle concernant l’interface WAN existe, celle permettant de bloquer les adresses IP sources correspondant à RFC1918, les adresses de réseaux privés et les fausses adresses IP.

On crée donc une nouvelle règle de pare-feu et on la configure comme tel

Nous avons autorisé les connexions sur l’interface WAN pour le port 80. Interface et port sur lequel tourne notre frontend.

Réessayez à nouveau d’accéder à l’adresse WAN, et ça marche !

Si vous avez installé Apache en tant que serveur web, modifiez la page de démonstration d’un des serveurs web située dans :

/var/www/html/index.html

Et vous verrez que le Round robin, fonctionne bien car la page renvoyée diffère chaque fois que vous rafraichissez la page.

Maintenant, retournez à la page de statistiques de HAProxy et changez l’état d’un des serveurs en tant que MAINT. Vous remarquerez que l’un des serveurs web ne renvoie plus sa page et pour cause, HAProxy l’a virtuellement rendu indisponible au balancement.

IX - Conclusion

En conclusion, nous avons mis en place avec pfSense et HAProxy deux serveurs web en haute disponibilité, retenez que pfSense ne se limite pas à être un simple pare-feu mais est composé d'un panel de fonctionnalités et de packages vous permettant d'administrer votre réseau de la façon dont vous voulez.

Cependant, il ne s'agit là que de la version open-source de pfSense et qu'ils existent d'autres solutions beaucoup plus performantes mais également des pare-feu physique vendus par la société NETGATE.

Notre architecture contient malgré tout un problème car elle a un SPOF(Single Point of Failure) car nous n'avons qu'un seul pare-feu jouant le rôle de load balancer. Bien évidemment il est possible de mettre en place une architecture beaucoup plus poussée en faisant communiquer deux pare-feu pfsense sur sites distant à travers IPSEC.

A ce moment nous pourrons placer plusieurs serveurs web en balancement depuis de multiples sites distants tout en ayant un stockage décentralisé répliqué sur plusieurs sites

Merci d’avoir suivi cet article.

A propos de SUPINFO | Contacts & adresses | Enseigner à SUPINFO | Presse | Conditions d'utilisation & Copyright | Respect de la vie privée | Investir
Logo de la société Cisco, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société IBM, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sun-Oracle, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Apple, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Sybase, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Novell, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Intel, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Accenture, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société SAP, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Prometric, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo de la société Toeic, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management Logo du IT Academy Program par Microsoft, partenaire pédagogique de SUPINFO, la Grande École de l'informatique, du numérique et du management

SUPINFO International University
Ecole d'Informatique - IT School
École Supérieure d'Informatique de Paris, leader en France
La Grande Ecole de l'informatique, du numérique et du management
Fondée en 1965, reconnue par l'État. Titre Bac+5 certifié au niveau I.
SUPINFO International University is globally operated by EDUCINVEST Belgium - Avenue Louise, 534 - 1050 Brussels