Mise en place failover

kalistyan

Bonjour à toutes et tous :)

Contexte : Pro, il s'agit d'un environnement virtuel (ESXi 5.5). 1 VM pfSense / Datastore.

Besoin : mise en place d'une solution redondée.

Schéma :

WAN : 1 IP publique (OVH)

LAN : une seule interface

SYNC : interface dédiée à la synchronisation.

Autres interfaces : virtual IP address => 192.168.xxx.254/24 (vhid1) Interface => LAN Type => CARP Advertising Frequency => Base 1 / Skew 0

Aliases => Ports => Web 80, 443

Règles NAT :

WAN TCP * * WAN address Web(alias) 192.168.xxx.80 Web(alias) Reverse Proxy

Règles Firewall :

WAN IPv4/ICMP * * WAN address * * none Autoriser PING

WAN IPv4/TCP * * WAN address 8088 * none WebGui

LAN * * * LAN Address 8088 * * Anti-Lockout Rule

SYNC IPv4* * * * * * none Autoriser tout le trafic sur l'interface HA (règle ajoutée sur les deux firewall)

Question : Est-il possible de monter une solution HA avec seule IP WAN ?

Logs et tests : Logs ok, la synchronisation fonctionne bien! La slave prend bien le relais…

Problème rencontré : Cela concernant l'accès à la GUI (quand les deux vm sont allumées) depuis l'ip publique c'est la roulette russe!!! Je tombe sur l'une ou l'autre VM…

Configuration des deux VM :

pfSense01 (master)

1 adressage WAN publique 37.xxx.xxx.xxx/32
1 adressage LAN en 192.168.XXX.251/24
1 adressage SYNC en 10.1.1.1

pfSense02 (slave)
1 adressage WAN publique 37.xxx.xxx.xxx/32
1 adressage LAN en 192.168.XXX.252/24
1 adressage SYNC en 10.1.1.2

Tatave

salut salut

depuis quelle ip vous faite votre requettes ? si vous avez défini correctement votre cluster en FO vous ne devriez vous loguer que sur l ip-lan du maitre pour realiser les paramétrages et de temps en temps via l ip de l esclave pour l'install des modules ou forcer une maintenance sur celui ci

si vous passez par l ipV lan c est logique que vous ayez un coup l une ou l autre machine suivant vos paramètres de esxi

NB pour la plupart d'entre nous ne sommes pas partisant de l usage de pf en mode virtualisé pour des raisons évidentes et mainte fois explicité (faire recherche sur le forum) privilégiez pf en dur en amont, pour du test je ne serais pas aussi catégorique mes certains de mes camarades.

Cordialement.

ccnet

Contexte : Pro, il s'agit d'un environnement virtuel (ESXi 5.5). 1 VM pfSense / Datastore.

En vous avez installé cela comment en ce qui concerne les Vswitch et les cartes physiques ?

kalistyan

Salut,

vSwitch 0 => vmNIC0 = WAN = aucune modification de config.

vSwitch 1 => Aucun adaptateur = LAN = activé mode promiscuous (mode espion en fr). Ceci afin de permettre l'utilisation d'une IP virtuelle (celle du cluster) avec adresses MAC différentes.

ccnet

On installe un firewall pour des raisons de sécurité.
On installe et configure un cluster pour des raisons de sécurité.
Et ensuite on saborde le tout avec une configuration réseau complètement inadaptée. Il est notoire que ce paramètre, actif pas défaut sur ESX, doit être désactivé. L'idée de placer un cluster de firewall sur le même ESX ne tient pas. Une des fonctions de base du cluster c'est de ce prémunir des défaillances hardware, même si ce n'est pas la seule.
Je ne revient pas sur l'ineptie du firewall virtualisé. Tout cela ne donne qu'une illusion de sécurité.
Une vraie solution HA nécessite des moyens matériels, des adresses ip, des liens empruntant des chemins physiques différents. Tout ce que vous pourrez faire c'est minorer certains risques, mais si c'est pour les augmenter par des configuration inadaptées cela n'a pas de sens.
Il faut revoir votre approche sur la base d'une bonne maîtrise des risques.

Tatave

salut salut

J'ai quelques questions qui me taraude :

Pourquoi virtualisez vous pf ?
- - Pour tester ces fonctionnalités ?
- - Pour le mettre en production au sien d'un réseau complétement virtualisé ?
- - Ou est l 'intérêt de virtualiser pf en FO si vous n'avez qu'un serveur esxi ?

Dans le cadre de tests de montage d'un pf la virtualisation est une solution, sauf que vous rajoutez des problématiques supplémentaires inhérentes à la virtualisation en générale.

Vous désirez faire du FO sur un lien internet (wan) ok. cela est parfaitement réalisable je le fais depuis quelques années avec un lien internet sauf qu il faut être bien conscient que si votre lien tombe tout votre réseau n'est plus connecté à l'extérieur, c'est là ou l'on va ajouter un lien internet en plus.

Cordialement.

kalistyan

@ccnet:

On installe un firewall pour des raisons de sécurité.
On installe et configure un cluster pour des raisons de sécurité.

Nous sommes d'accord.

@ccnet:

L'idée de placer un cluster de firewall sur le même ESX ne tient pas. Une des fonctions de base du cluster c'est de ce prémunir des défaillances hardware, même si ce n'est pas la seule.

Dans mon cas si, car le serveur n'a pas de raid. Comme indiqué plus haut, chaque pfSense sera sur un Datastore différent.
Cette "solution" ne couvre bien entendu que la panne des disques.

@ccnet:

Une vraie solution HA nécessite des moyens matériels, des adresses ip, des liens empruntant des chemins physiques différents. Tout ce que vous pourrez faire c'est minorer certains risques, mais si c'est pour les augmenter par des configuration inadaptées cela n'a pas de sens.

Vous avez oublié un détail important, le budget… :) Et dans mon cas, il est limité.

@Tatave:

Pourquoi virtualisez vous pf ?

Question de budget…

@Tatave:

Pour tester ces fonctionnalités ?

Non

@Tatave:

Pour le mettre en production au sien d'un réseau complétement virtualisé ?

Oui

@Tatave:

Ou est l 'intérêt de virtualiser pf en FO si vous n'avez qu'un serveur esxi ?

Comme indiqué plus haut, chaque pfSense sera sur un Datastore différent.
Cette "solution" ne couvre bien entendu que la panne des disques.

@Tatave:

Vous désirez faire du FO sur un lien internet (wan) ok.

Oui

@Tatave:

cela est parfaitement réalisable je le fais depuis quelques années avec un lien internet sauf qu il faut être bien conscient que si votre lien tombe tout votre réseau n'est plus connecté à l'extérieur, c'est là ou l'on va ajouter un lien internet en plus.

Dans votre cas, vos pfSense pointe sur un routeur ?
Comme indiqué plus haut, je ne souhaite pas redonder le lien WAN. ;)

jdh

(Ce fil part en c…) J'avais vu ce fil avec l'effort initial du formulaire mais je n'avais pas le temps de répondre ...

Quelques idées :

NE PAS virtualiser en production un firewall (et a fortiori un cluster de firewall) : permet d'éviter de perdre du temps : est ce firewall ? est ce la virtualisation ? ai-je la compétence de mise en oeuvre ?
failover = 2 firewall avec 1 master et 1 slave, le slave est prêt à prendre le relais 'presque instantanément'
le failover nécessite une interface de synchro : ne pas synchroniser via le WAN ni le LAN !
pour chaque interfaces, il FAUT 3 adresses ip par interface : 1 par firewall + 1 du 'cluster' = celle connue officiellement, le CARP basculera automatiquement du master au slave, les ip 'cluster'
en sortie, attention à configurer la sortie utilisant l'ip de cluster, et non celle de WAN = celle DU firewall !
éviter d'accéder avec une ip de firewall : utilisez les ip cluster !
sur WAN, un switch : les 2 firewall + le routeur WAN
sur LAN, chaque firewall est connecté au même switch LAN
sur DMZ (=SYNCHRO), un câble croisé si pas de machines, sinon un switch avec les 2 firewall et les serveurs

NB : Que se passe-t-il avec une seul ip WAN publique ?
Il faut 3 adresses WAN : celle de chaque firewall + celle du cluster 'de référence'.
L'ip du clusteur doit être dans le réseau indiqué pour chaque WAN réelles du firewall !
Dans le cas d'une ligne SDSL avec routeur, je "triche" :
exemple, on me fournit 80.80.80.82 et un routeur/gateway 80.80.80.81 : le réseau est 80.80.80.80/30 (.80=réseau, .81=routeur, .82=WAN, .83=broadcast)
je triche en raisonnant avec le réseau 80.80.80.76/29 (.76=réseau, .83=broadcast) : je peux fixer WAN firewall1 =.78 et WAN firewall2=.79, et cluster = .82 !
J'ai bien noté que je ne pourrais causer avec 80.80.80.76-19 ... en espérant que ce n'est pas un client ou fournisseur !

Il est possible de gagner du temps avec du matériel physique : un firewall n'a pas besoin d'être super puissant, au contraire.

kalistyan

@jdh:

NB : Que se passe-t-il avec une seul ip WAN publique ?

Il faut 3 adresses WAN : celle de chaque firewall + celle du cluster 'de référence'.

L'ip du clusteur doit être dans le réseau indiqué pour chaque WAN réelles du firewall !

Pour information on me fournit ceci :

IP publique : 37.59.xxx.247

Passerelle : 37.59.xxx.254

Avec la configuration suivante, j'approche du but… Le basculement fonctionne, mais l'accès à internet finit par tomber quelques minutes après le passage sur le slave.
Pour information le NAT Outbound est en auto.

En manuel, je n'arrive pas à avoir l'avoir à internet depuis le réseau local... Je dois me tromper dans la règle! :-\

pfSense01 (master)

1 adressage WAN 37.xxx.xxx.xxx/32 ip publique
1 adressage LAN 192.168.XXX.251/24 réseau local
1 adressage SYNC 10.1.1.1 interface dédiée à CARP

pfSense02 (slave)
1 adressage WAN 37.xxx.xxx.xxx/32 ip publique
1 adressage LAN 192.168.XXX.252/24 réseau local
1 adressage SYNC 10.1.1.2 interface dédiée à CARP

Virtual IPs

10.2.2.1/24 WAN IP Alias IP WAN (local)
10.2.2.254/24 (vhid 2) WAN CARP IP WAN de référence

192.168.xxx.254/24 (vhid 1) LAN CARP IP LAN de référence

jdh

Les bases ne sont pas là … la lecture (et la préparation) est faible
Les infos ne sont pas là ... j'imagine qu'il s'agit d'une machine hebergée ...

kalistyan

@jdh:

Les bases ne sont pas là

Que voulez vous dire ?

@jdh:

La lecture (et la préparation) est faible.

Je ne comprends pas… Quant à la préparation j'ai suivi la charte...

@jdh:

Les infos ne sont pas là.

Je ne vois pas quoi donner d'autre… Pourriez vous être plus precis ?

@jdh:

j'imagine qu'il s'agit d'une machine hebergée.

Oui, d'où la configuration atypique…

jdh

Avec une machine hébergée, il n y a guerre de solution : on est tenté par la virtualisation si on veut avoir plusieurs serveurs ….
De là à faire du cluster de firewall virtualisés ...
Il est probable que si le firewall tombe, l'hôte (=la machine) est tombé ... et tous les serveurs.

Avec une machine hébergée, je ne ferais jamais de cluster de firewall, cela ne ferait que complexifier totalement inutilement et perdre de précieux Mo de mémoire ...

L'info de machine hébergée eut été souhaitable d'être précisée dès le début !

Tatave

salut salut

Bon je vais tenter de dépassionner le débat, si cela en est possible.

En résumé si j 'ai bien compris, vous désirer par le moyen de la virtualisation monter un cluster FO avec pfsense.
Vous rencontrer un soucis au niveau du gui qui a un coup l'addresse du maitre un coup celui de l'eslave.

Comme j'ai tenté de vous l'expliquer au sujet du gui, si vous tape sur l ip virtual (carp) du lan ou toutes autres ivp qu'il pourrait y a voir vous aurez ce type de comportement. Pour bien administrer un cluster, j'entends par là les intervention de maintenance et autre opérations du genre, vous devez passer pour les ip des interface physique des machines soit dans votre exemple la carte réseau lan du votre maitre qui s'il est bien paramétrer doit synchroniser les paramètres sur l'esclave tout les x temps.
Il faut bien comprendre que l'ipv est la pour que les utilisateurs ou applications utilisatrices passe par elle de manière transparentes comme si elles passaient par une interface physique mais qui avec ce mon mécanisme propres bascule d'une machine à l'autre les flux sans que les utilisateurs ou application en soient conscientes.

Pour revenir sur le sujet de la virtualisation de pfsense, comme je l'ai évoqué, il est communément acté que pour une mise en production n'est pas une solution sécure.

Personnellement la virtualisation de ce type de solution, je ne l'utilise que pour valider telle ou telle fonctionnalité avant de passer sur une machine physique.

Pour revenir sur le cout d'une machine cela ne va pas chercher loin non plus, rappelez vous que c'est du BSD qui peut fonctionner même sur de l'embarqué (no screen/no keyb) gérable en console pour les param de départ et via le gui en second, voir en ssh pour ceux qui savent ou ils mettent les doigts (je ne suis pas là moi non plus)

Donc pour revenir à votre cluster FO , je vous renvoie sur ce lien qui est assez judicieux pour le choix matériel http://www.firewallhardware.it/en/pfsense_selection_and_sizing.html qui coté budget donne un cout d'environ 200/300€ si l'on fait du home-made neuf ou de récupération

une carte mère micro atx ==> 35/50 € (avec carte réseau intégrée et vidéo aussi)
un cpu avec dissipateur ==> 35/50€
de 2 à 4 go ram 35/50€
un hdd 35/50 €
un boitier avec alim 35/50€
deux cartes réseau en plus (une pour le lan et une pour la synchro) 15/20€ unitée
accessoires
-5 cables , deux vers votre routeur, deux vers votre switch lan et enfin un croisé pour la synchro
-1 switch sur votre partie lan

il n'y a pas là de quoi casser trois pattes à un canard, c'est de la machine fait maison, et même avec du matériel de récupération c'est faisable le temps que vous ayez le budget pour passer sur du boitier buildé pour comme se qui est proposer sur ici http://store.pfsense.org/VK-T40E/ qui est a quelques chose près du même budget mais moins modulaire que le home-made.

Souvenez vous aussi qu'avoir un pare-feu en haute disponibilité, il faut en avoir l'utilité et qu'il faut aussi penser à faire de même pour le reste du coeur de réseau (services fournie au users compris) donc pour les paranos et comme l'a fait remarqué jdh si le virtualisateur tombe tout tombe.

doubler votre lien exterieur (2 wan)
doubler vos liens entre les deux wan
doubler vos liens entre les deux pf
doubler vos liens vers le lan
doubler votre switch.

Ca, c'est pour le la partie Pf mais pour les machines en arrières c'est la même chose, vous pouvez toujours jouer sur le nombre de machines physiques en mettant un esxi en réplication mais là aussi on attaque un autre monde, il n'est pas aisé même quand l'on connait de ne pas faire une erreur qui potentiellement couter cher à tout le monde.

Ma dernière question est le jeu en vaut il la chandelle ?
si oui mettez les moyens en commençant par passer sur un vrai cluster physique pf (home made / constructeur, peut importe) et votre outils de virtualisation en arrière que vous pourrez toujours doubler par après.

Mais surtout et le rejoint mes camarades. Ne pas mettre l'un (pf) dans l'autre (esxi), vous aurez une meilleur sécurité pour vos données et vous services fournis.

Que vos machines soient hébergés ou pas, dans votre cas OVH a des solutions adaptées à vos besoins et si cela n'est pas disponible, vous pourrez toujours en discuter avec eux, ils savent de quoi ils parlent et maitrisent leurs sujets.

Cordialement.