Bonjour à tous.
J'essaye de créer un firewall que je pourrais mettre en coupure sur un câble ethernet. J'ai choisi une petite machine avec deux sorties ethernet et j'ai configuré un bridge entre les deux interfaces. Cela me permet de faire ça de façon transparente sans rien changer au réseau dans lequel je m'insère. J'attribue ensuite une ip au bridge via le dhcp déjà présent sur le réseau, ce qui me permet d'administrer le firewall. Jusque là tout marche bien.
Maintenant j'aimerai redonder la bête. Donc j'ai mis une deuxième machine, câblé tout ça puis activé STP. Voilà un schéma de mon prototype actuel :
L1 ---- S1 ---- F1 ---- S2 ---- L2
| |
| ---- F2 ---- |
où L1 et L2 sont deux laptops qui jouent aux ping pong, S1 et S2 deux switchs et F1 et F2 les deux firewalls.
Maintenant la problématique, c'est que STP c'est vachement lent quand je débranche l'un des câbles S1-F1
ou F1-S2
. Il faut au minimum 30s avant que F2 ne prenne le relai. J'ai essayé de bouger les paramètres sethello
, setfd
et setmaxage
; j'ai mis respectivement 1, 4, 6 (les docs disent 1, 4, 4 possible mais brctl
refuse) mais ca ne semble pas changer grand chose.
J'ai regardé du coté de rstp
et mstp
mais ce n'est pas packagé, rstp
ne compile pas, j'ai réussi à compiler mstp
en trifouillant les headers mais ça n'a rien donné (la doc est mince, j'ai peut-être loupé quelque chose).
Deuxième point : lorsque je rebranche le câble, la connexion est également coupée (une trentaine de secondes également) avant rebasculement sur F1 (j'ai mis des priorités lors de la conf de STP). Soit c'est un inconvénient de STP, soit j'ai loupé quelque chose.
J'ai regardé du coté de keepalived/conntrackd mais je ne suis pas sur que cela puisse s'appliquer à mon cas.
Pensez vous que je doivent adapter le réseau d'insertion (mettre un réseau différent sur le lien L1-S1 et sur le lien S2-L2) ? C'est quelque chose que j'aimerais éviter. Est-ce que keepalived peut m'aider ? Une autre piste que je pourrais explorer ?
# commutateur ?
Posté par nono14 (site web personnel) . Évalué à 2.
6co pour les commutateurs ?
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
# firewall en bridge ?
Posté par NeoX . Évalué à 3.
J'ai du mal à saisir, ou alors j'ai mal appris
pour moi un firewall doit filtrer entre les deux interfaces,
si tu le montes en bridge, tu ne filtre plus rien, tu laisses passer de S1 vers S2.
si tu veux un firewall, il faut generalement faire du routage,
tu as alors R1 ton reseau sur le S1/L1,
et R2 sur S2/L2
là tu actives l'IP forwarding sur ta machine,
tu dis à L1 de parler à F1.1 quand il cherche à joindre R2, idealement F1.1 est la route par defaut de L1
tu dis à L2 de parler à F1.2 quand il cherche à joindre R1, ideelement F1.2 est la route par defaut de L2
ca c'etait pour le firewall.
pour le mode cluster,
je ne sais pas si c'est plus rapide, mais nous ici on utilise VRRP, le principe c'est que chaque F1/F2 dispose d'une IP sur S1 et sur S2, mais en utilise une 3e et 4e qu'ils se partagent et qui est la route par defaut des L1/L2.
quand F1 tombe, F2 le voit et reprend cette IP partagée (VIP) sur le reseau 1, et fait la meme chose sur le reseau 2
[^] # Re: firewall en bridge ?
Posté par IceCat (Mastodon) . Évalué à 2.
Un bridge transparent est un firewall en général avec 3 interfaces, deux sans IP et une de management.
Les interfaces restent en couche 2 en mode promiscuous, et il filtre ce que tu lui dis.
http://www.cisco.com/c/en/us/td/docs/security/asa/asa70/configuration/guide/config/fwmode.html#wp1194597
pfSense (entre autres) le fait très bien aussi.
Par contre je ne sais pas comment aider notre amis. On lit un peu partout sur le web de passer setfd à 0, mais apparemment brctl refuse…
[^] # Re: firewall en bridge ?
Posté par copapa . Évalué à 1.
Effectivement.
En mode bridge,
netfilter
voit quand même passer les trames et je peux appliquer les règles que je veux. Pour l'instant, je n'ai pas d'interface dédiée à l'administration, j'ai donné une ip à mon interfacebr0
pour réduire le jonglage avec de nombreux câbles. Je passerai à l'interface dédiée admin lorsque je serai satisfait.J'ai réussi à réduire un peu le délai en appliquant les recommandations de Cisco sur les paramètres : http://www.cisco.com/c/en/us/support/docs/lan-switching/spanning-tree-protocol/19120-122.html
Si je ne me trompe pas, j'ai un diamètre (dia) de 2, j'ai mis un hello à 1, ça me donne un
max_age
de 6 et unfd
de 5. J'obtiens un basculement entre 5 et 25s (valeurs extrêmes c'est plus souvent ~15s) mais ça reste un peu long.[^] # Re: firewall en bridge ?
Posté par KiKouN . Évalué à 2.
Pourrais-tu répondre au tout premier commentaire ? Plus précisément, quel type de switch utilise tu ?
Un switch administrable peut jouer. Il ne monte pas directement un interface par exemple.
[^] # Re: firewall en bridge ?
Posté par copapa . Évalué à 1.
Je n'avais pas compris la question en fait (maintenant c'est bon). Donc j'ai deux switch Netgear FS605 v3. Donc non administrables.
J'ai lu cette page : http://www.seattlecentral.edu/~dmartin/docs/bridge.html et j'en déduis (notamment dans la dernière partie "Alternatives") que si je remplace mes switchs par des switchs plus évolués (qui gèrent le Spanning Tree), je pourrais atteindre des délais bien plus réduits. Me trompé-je ?
[^] # Re: firewall en bridge ?
Posté par Kerro . Évalué à 2.
Si les 30 secondes sont à cause des switchs, pourquoi pas. Mais tu n'as pas vérifié ce point.
Il te faut t'assurer que tes switchs en sont bien la cause : tu vas voir dans les journaux de tes machines pour t'assurer que la bascule est bien prise en compte en 4 secondes par exemple. Si ce n'est pas le cas, tu peux changer tous les switchs du monde, ça n'y fera rien.
Une astuce pour que ce soit immédiat serait que la machine qui prend le relai émette vers le switch des trames Ethernet avec l'adresse MAC d'équipements ranchés du côté opposé (afin que le switch sache que l'équipement n'est plus sur le même port). Facile à dire. Je l'ai déjà fait pour une configuration toute simple et juste en test, donc aucune idée si ça tient dans le temps.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.