Virtual ip (carp) avec une ip fail-over

ccnet

comment la configurer sur le firewall afin d'assurer une haute disponibilité

La haute disponibilité dans votre configuration relève du pur fantasme. Comment peut on prétendre à la haute disponibilité avec une seule machine physique connectée sur un seul réseau physique dans le même datacenter ?

ça a marché pendant un temps mais là, la règle ne fonctionne plus

j'ai attribué des ip aléatoire

Et les titulaires de ces ip vous y avez pensé ?
Et je ne parle même pas du firewall virtualisé. Vous seriez bien inspiré de revenir à une configuration classique qui fonctionne !
On ajoute, pour faire bonne mesure, un accès à l'interface d'administration sur l'interface Wan.

body4

La haute disponibilité dans votre configuration relève du pur fantasme. Comment peut on prétendre à la haute disponibilité avec une seule machine physique connectée sur un seul réseau physique dans le même datacenter ?

Désolé, mais je ne vous suis pas ? J'ai loué un serveur dédié chez OVH où j'ai installé un ESX et dans ce dernier, j'ai créé deux machines virtuelles avec pfsense.

Pour les adresses ip aléatoires… elles ne sont pas routable, elle ne sortent même pas de l'ESX.

Le but étant de créer une architecture virtuelle pour un projet annuel. Rien de réel.
On doit mettre des firewall en cluster et assurer une haute disponibilité.
Et pour pouvoir aller sur internet depuis mon ESX, j'ai du commander une IP Fail-Over

Tatave

Salut salut

Ce que voulait dire (je pense) ccnet, c'est que pour réellement avoir une archi virtualisée avec de la redondance il faut au minima deux hyperviseur qui se réplique l'un l'autre.
Personnellement je comprends l'idée de monter votre archi pour votre projet (je suis dans ce cas pour du maquettage).

Pour votre projet il est important d'avoir une carte (pour votre administration avec un ip qui ne sera connue que de vous, et deux cartes lesquelles vous aurez votre ip failover qui seront publique.

Cordialement.

ps : je ne dois pas etre loin de la bonne info (sans parler de la problématique éthique de la virtualisation d'un pare feu qui a été plusieurs fois évoquée et débattu)

chris4916

Sans le contexte (projet / test etc… sans finalité de production) , ce design est effectivement surprenant même si il est, de mon point de vue, parfaitement concevable (voire souhaitable si l'objectif est de fournir de la haute dispo) d'avoir 2 firewall dans le même datacenter qui se connectent au même réseau physique.

Ce qui m'interpelle, c'est plus, comme le souligne Tatave, le coté ESX et le fait que cette plate-forme est accédée depuis internet ::)

Ce serait à mon avis bien plus simple dans un lab et encore plus simple avec 2 machines ;D dans un premier temps, histoire de ne pas superposer les problématiques liées à CARP à celles liées à ESX + OVH (i.e. accès à l'interface d'admin depuis l'extérieur etc...)

Dans ma compréhension, CARP signifie 6 interfaces réseau et 8 adresses IP

chaque FW dispose de:
=> son adresse physique interne
=> son adresse physique externet
=> une adresse sur le réseau de "heartbeat"
il y a en plus une adresse virtuelle flottante externe et une interne

ccnet

@body4:

Le but étant de créer une architecture virtuelle pour un projet annuel. Rien de réel.
On doit mettre des firewall en cluster et assurer une haute disponibilité.

Un post initial complet, décrivant correctement le contexte, est toujours souhaitable.
Cela dit en suivant les recommandations qui précèdent, vous éviteriez les complications inutiles.

chris4916

@ccnet:

@body4:

Le but étant de créer une architecture virtuelle pour un projet annuel. Rien de réel.
On doit mettre des firewall en cluster et assurer une haute disponibilité.

Un post initial complet, décrivant correctement le contexte, est toujours souhaitable.

L'effort de rédaction vaut ici largement le coup car ça peut permettre de soulever quelques questions.
Si l'objectif est la mise en œuvre de CARP, ça reste assez simple.
Si l'objectif est d'offrir, même de manière théorique, de la haute dispo, CARP n'y participe que partiellement. ça dépend vraiment du risque qu'on souhaite couvrir.

Par exemple ma description basique au dessus ne couvre "que" le risque d'arrêt d'un des 2 firewall. C'est déjà pas mal mais loin d'être suffisant dans les environnements où la haute disponibilité est vraiment requise car il y a également tous les risques associés à la connectivité (réseau et accès internet).
Et donc, même pour un exercice, des questions telles que la redondance des accès internet ou la redondance de l'infrastructure réseau autour du FW restent valides, au moins pour préciser le cadre du projet.

Si je reprends l'image utilisée pour illustrer mon propos sur les edge routers dans un autre sujet, le schéma de Cisco illustre bien que la connectivité à internet se compose de 2 FW mais également de 2 accès différents.
Du coup, dans la vraie vie, le jeu consiste à déployer CARP sur une plate-forme qui est au départ configurée pour faire du double WAN. C'est beaucoup plus drôle ;D ;D ;D

cisco_edge.jpg_thumb

ccnet

En complément de ce qui précède un document intéressant :
http://www.hsc.fr/ressources/presentations/adim13-22/ADIM-presentation_ISO22301.pdf
Dans ISO, si ma mémoire est bonne la distance minimale entre deux datacenters est 30km.

Et sur la nécessité d'avoir des accès différents, on s'assure aussi que les câbles et infrastructures opérateurs ne sont partagées, même NRA par exemple et câbles sous le même trottoir. Si cela n'est pas traité, toute votre architecture, aussi sophistiquées soit elle, tombe à l'eau avec un simple coup de pelleteuse mal placé.

Parler de haute disponibilité, c'est bien identifier les risques que l'on souhaite couvrir.

chris4916

@ccnet:

Parler de haute disponibilité, c'est bien identifier les risques que l'on souhaite couvrir.

+1 8)

body4

Pour votre projet il est important d'avoir une carte (pour votre administration avec un ip qui ne sera connue que de vous, et deux cartes lesquelles vous aurez votre ip failover qui seront publique.

A la location de mon serveur, on m'a effectivement communiqué une ip qui pointe directement sur ce dernier. Donc il n'y a que moi qui l'a connais. J'avais même tenter d'accéder à internet depuis des machines virtuelles avec cette ip mais ce n'était pas possible d'où le fait que j'ai acheté une IP-FO.

Malheureusement, je n'ai pas la possibilité d'ajouter une seconde carte réseau. J'en ai qu'une et mon budget est limité pour acheté un second serveur dédié.

De toute manière, je ne vois pas en quoi cela peut poser problème ? d'avoir tout sur une seule machine physique qui comprend une seule carte réseau physique. Ça doit être possible de faire une haute dispo avec deux machines virtuelles qui se partage l'ip fo achetée. Même si la configuration n'est pas faite pour un environnement de production.

Je comprends bien que dans une situation réelle, il faut avoir tout en double pour assurer une véritable haute disponibilité.

Voici ma configuration actuelle :

Serveur dédié avec un ESX : xxx.xxx.xxx.xxx <- IP publique qui me permet de m'y connecter
FW1
WAN : 176.31.117.230/24 (ip non routable) Passerelle : x.254
SYNC : 10.1.50.10/24 (utiliser pour carp)
Virtual IP (carp) : mon ip failover/32 (qui n'est pas dans le même range ip que celle de l'esx) et sa gateway est celle de l'esx
advskew 0

FW2:
WAN : 176.31.117.240/24 (ip non routable) Passerelle : x.254
SYNC : 10.1.50.20/24 (utiliser pour carp)
Automatiquement, il récupère la virtual ip du serveur 1
advskew 100

J'ai créé une règle sur le firewall 1 pour dire qu'il accepte toutes les connexions venant de mon ip publique (de chez moi) à accéder au service https depuis l'ip-fo et ça fonctionne. Enfin a peu près car il y a un problème, toutes les 5 secondes environs, je change de firewall, un coup ça me met sur le 1 puis sur le 2 puis le 1.. dans les logs j'ai cette erreur qui revient souvent : carp: preempting a slower master

chris4916

Ne serait-ce pas dû à un problème au niveau ESX qui ferait que chaque pfSense pense que c'est lui qui devrait être master car l'autre ne fonctionne pas correctement ?
Comment est configuré ton switch virtuel pour le heartbeat ?

Pour le reste, nous somme d'accord, un lab sur une VM peut fonctionner mais de mon point de vue, le passage de machine physique à VM ne devrait se faire que lorsque la solution au niveau physique est totalement validée car la couche VM présenté quand même des particularités et ajoute une couche de complexité supplémentaire. Mais au final ça doit marcher pour un PoC 8)

Tatave

Salut salut

Je pense que manifestement c'est un soucis de compréhension nous en sommes tous et toutes d'accord.

Les manques sont multiple ;

sur la virtualisation en général et particulièrement esxi précisément en premier.
sur les pare feux et particulièrement pfsense en deuxième.
sur les concepts théorique et pratique liées à la notion de haute disponibilité informatique.

Je vous conseillerais ;

en premier lieu (si vous le pouvez) en physique,
C'est a dire sur une machine avec 3 cartes (2 wan 1 lan) en vous référant à des tuto pour traitant du concept du FO/LB sur les liens wan1/2
en deuxième lieu de rajouter une deuxième machine pour faire du cluster pf (dans votres cas c'est avec 4 cartes sur chaque machine.
en troisième et ou en parallèle de vous servir de votre esxi distant avec la documentation qui n'est pas inexistante de monter votre projet.

Il est important de noter que vous n'etes pas le/la seul(e) à vous casser la tête avec ce type de projet de virtualisation et plus précisément d'un cluster pf mais pas que.