[resolu] - fail over + vlan + loadbalancer

Juve

Je pense qu'il faut que tu te poses quelques question quant à ton architecture. C'est un problème de fondamentaux.

As-tu réfléchi à ce qu'est un bridge et à quel niveau (OSI) il travail ?
Dès lors est-ce que bridge et CARP peuvent cohabiter ?
Qu'arrive t-il dans un réseau ou deux bridges relient les mêmes zones :-) ?

Dès que tu auras ces réponse tu auras alors la réponse à tous tes problèmes.

verash

Merci Juve c'est exactement les question qu'il fallait que je me pose…

En effet le bridge travaille au niv 2 (heu, je crois), et donc il transfer tout...
Le carp traivaille au niveau 3 (et 2 en fait, mais options pas applicables a pfsense), et pour lui il comprend pas que du fait du bridge entre les int "wan" et "lan', il y a toujours une continuté ou plus simplement une boucle...

Il est donc imperatif de faire un interface physique propre pour le carp (heartbeat), meme si je me suis dit qu'en isolant le port du switch sur le lan, il comprendrait la subtilité...

J'ai lu qu'il etait possible apres sur le swtich d'isolé totalement les port ou le proto carp passe...en enlevant le spanningtree...je ne sais pas si cela peut s'appliquer, mais en tout cas des demain je change l'archi en mettant le heartbeat sur des int separé physiquement...

Merci...

titofe, merci aussi de l'info, car evidement j'ai du pptp (pas openvpn), et je ferai attention sur le prot...

Juve

Tu as une conception trop "linux HA" du fonctionnement de pfSense.

Il n'y a pas de heartbeat.

Il ya trois briques dans un cluster pfsense:

la première s'appelle CARP, il s'agit d'une implémentation libre du standard VRRP au sein des OS BSD. Lorsque tu utilises CARP, chaque interface portant une adresse CARP se met alors à diffuser une annonce (pour le maître) et à écouter les annonces (pour l'esclave). il y a donc échange d'annonces sur chaque interface utilisant CARP.
la seconde s'appelle pfSync, il s'agit d'un protocole (utilisant la multidifusion) d'échange d'informations (le contennu de la table des états TCP/UDP)entre les noeuds d'un cluster. La bonne pratique consiste à utiliser une interface ou vlan dédié au passage de ce protocole (pour des raisons de sécurité et pour limiter le champs de la multidifusion). Si ce lien est coupé, en aucun cas le cluster basculera, il y aura simplement désynchronisation des états de sessions et lors d'une bascule les sessions en cours seront perdues.
-la troisième est pfSense lui même et plus particulièrement son mécanisme de synchronisation de la configuration (routes, rules, alias, nat etc.) utilisant le standard XML-RPC over HTTP ou HTTPS.

Dans ton cas il faut oublier le niveau 2 (bridge) et construire une architecture à base de routage (niveau 3).

Bonne chance.

verash

Merci Juve pour toutes ces infos precieuses…Je comprend beaucoups mieux ou sont mes problèmes...

Resultat :

Le cluster fonctionne, si j'en coupe un, le second prend le relais...Par contre j'ai encore un problème avec lePFsync, puisque si depuis le "wan", je pingue le "lan", cela fonctionne sauf lorsque ca coupe cela ne prend pas le relais...et lorsqu'il revient, le pingue refonctionne...

Donc conclusion et d'apres ces informations qui sont super importantes et merci a toi, le PfSync ne fonctionne pas...car il ne prend pas le erlais des états de connexion...ils continuent a envoyer sur le meme pf...

Je planche donc encore dessus...

Pour finir, ca fontionne vraiment bien, mais il est vrai qu'il a fallu que je change tout l'adressage reseaux derriere les PF...

J'espere que dans une version ultérieure du pf, il sera possible d'individualisé les int pour justement faire du bridge de vlan tout en ayant la possibilité de faire du carp sur d'autres vlan partageant le meme interfaces physiques...

En tous les cas, merci juve pour ces explications...

codercrack

Tu voit verash on devrait peut être pensé un peu moins linux !!! (ca va être dur ) lol
Mais Juve des informations très pertinentes !!!

Bravo !!!

verash

Codercrack, faut que je te voit pour ma parabole…ca va cest moins linux...

Bon sinon blague a part, toujours problemes sur la reprise des etats de connexion...je planche dessus, s'il y en a qui ont deja galeré dessus, peut etre pourront-ils me dire ou il avait mal conf des trucs...car ca doit etre evidement ca...une mauvaise conf qq part...

verash

Bon voici les news :

Le fail over fonctionne sur les wan et lan (plusieurs vlan de chaque cote des interfaces "wan" et "lan"
le carp fonctionne sur les wan et lan
le load balancing fonctionne sur les wan et lan

Si cela interesse qqun je pourrai mettre en ligne (sur ce post) comment j'ai fait…

Sinon maintenant ca fonctionne presque...et oui dernier probleme que je viens d'identifier :

Sur les rules du firewall, meme en mettant "pass any to any" sur tous les interfaces, il me bloque des requetes...aleatoirement...mais jamais pour les pings par exemple...

Par contre sur outlook j'ai des deco toutes les 2 minutes, et si je fait une exploration via windows, idem...

Dans les logs j'ai "@229 block drop out log quick all label "Default deny rules"

1ere question : Pourquoi bloquer les interfaces en sortie ??? Il me semblait (enfin c'est ce que je fait depuis quelques annees), qu'il ne afllait appliquer les rules sur un firewall qu'en entrer…et eviter de le faire en sortie pour ne pas se retrouver avec un tas de regles a suivre...Cela m'a donc posé un gros problème, car il drop mes paquets apres qu'il soit passer dans ma moulinette...(et oui si j'applique des regles en entrer, cela fait redondant de les appliquer en sortie aussi...)...

J'ai trouvé un contournement qui ne me satisfait pas, mais voila :

Je suis allé dans le fichier /tmp/rules.debug, et la dernière ligne de ce fichiers (enfin les 2) sont "block in/out log quick all label "Default deny rule"

ue fois commenté (juste pour le out evidement), cela fonctionne correctement...sans cela, cela ne fonctionne plus...

Cette regle doit bien venir de qq part, puisque a chaque modif, la ligne se Décommente...le fichier d'origine est /cf/conf/config.xml...mais rien dedans ne s'applique a un DENY ALL...

Qqun pourrait-il me dire ou se trouve cette regle de deny out , afin que je la supprime pour moi, car a mon sens inutile, puisque j'ai des regles de firewall en entré...

Merci une fois de plus...

verash

Bon ben pire qu'avant, maintenant quand je tape l'adresse de mon premier pfsense j'arrive sur sa page d'acces, et quand je tape l'adresse du second pfsense je tombe sur l'adresse du premier…

le second pfsense n'est plus accessible...sauf en mode ssh...pffffffffffffffffffffff...

verash

bon ben pour info voila la crotte precedente…

j'ai fait du nat et j'ai syncro les regles...sauf que comme j'accede a l'interface graphique par le wan, j'avais fait une redirection par le lan...sauf que l'adresse du lan etait diferente sur les 2 pf...resultat, impossible d'aller sur le second pf...alors j'ai changer le nat...et oublié de changer la redirect...resultat plus de pf...lol...

.!.

Juve

A un moment il faut abandonner ;D

Pour info, pfSense ne filtre pas en sortie des interfaces….

verash

ouais des fois faut abandonner…j'y suis retourné et j'ai resolu le pb en 15 minutes...

sinon je pensais ca aussi, mais en regardant le fichier /tmp/rules_debug, la derniere ligne est

"block in log quick all label "Default deny rule"
"block out log quick all label "Default deny rule"

j'en conclue qu'il filtre en entré et en sortie par defaut...En entré un deny all c'est normal, mais en sortie je ne voit pas la raison, mais il doit y en avoir une, surtout que "label" je ne sais pas trop ce que ca veux dire, pour moi cela signifie "label"...heu bon ok je sors...

je pensais donc que label voulait dire "tous les interfaces"...En tout cas en commantant cette ligne (temporaire puisque a chaque sauvegarde de regles il faut le recommenté...), cela fonctionne parfaitement...