Prevenir les interruptions de service sur un Firewall
11 réponses
xavier
Bonjour,
Suite au gag de la màj foireuse de FreeBSD 4.10-p5 -> 4.11 (*), mon chef
me demande ce que j'ai pris comme mesures pour remettre debout le
firewall en cas de panne. Je veux dire à part aller chez moi rechercher
les bonnes sources et revenir compiler en single-user.
Evidemment, la solution royale est d'avoir une deuxième machine
identique, avec un rsync toutes les nuits. Irréalisable ici
d'immobiliser une machine qui ne servira probablemnt jamais.
Et de toutes façons, vu le fonctionnement de l'administration, si je
stocke une machine, ou même simplement des cartes réseau, il arrivera un
jour où elles auront besoin d'être utilisée ailleurs - par ex: panne au
mois de novembre, achats gelés donc destockage.
Pour l'instant je pense simplement à un disque SCSI amovible (cold-plug,
le boîtier coûte une 30aine d'Euros) avec un rsync à chaque mise à jour.
D'autres idées ?
Merci,
XAv
(*) voir <41fa854d$1@groumpf.org>. Il semble que l'update de IPF en
3.4.35 ne soit pas vraiment le bienvenu.
--
Xavier HUMBERT
INJEP - NetBSD, parce que je le vaux bien
(Xavier HUMBERT), le lun. 31 janv. 2005 11:40:26, écrivait ceci:
Bonjour, Salut,
Evidemment, la solution royale est d'avoir une deuxième machine identique, avec un rsync toutes les nuits. Irréalisable ici d'immobiliser une machine qui ne servira probablemnt jamais. D'autres idées ?
Une autre partition en mirroring, bootée en cas de défaillance de la première : même machine, mêmes cartes
-- Embryon de site : http://gilles.ronsin.free.fr Nouvelle astuce : Script de création de raccourcis cible http://gilles.ronsin.free.fr/#targetlnk Il est impossible pour un optimiste d'être agréablement surpris.
Evidemment, la solution royale est d'avoir une deuxième machine
identique, avec un rsync toutes les nuits. Irréalisable ici
d'immobiliser une machine qui ne servira probablemnt jamais.
D'autres idées ?
Une autre partition en mirroring, bootée en cas de défaillance de la
première : même machine, mêmes cartes
--
Embryon de site : http://gilles.ronsin.free.fr
Nouvelle astuce : Script de création de raccourcis cible
http://gilles.ronsin.free.fr/#targetlnk
Il est impossible pour un optimiste d'être agréablement surpris.
(Xavier HUMBERT), le lun. 31 janv. 2005 11:40:26, écrivait ceci:
Bonjour, Salut,
Evidemment, la solution royale est d'avoir une deuxième machine identique, avec un rsync toutes les nuits. Irréalisable ici d'immobiliser une machine qui ne servira probablemnt jamais. D'autres idées ?
Une autre partition en mirroring, bootée en cas de défaillance de la première : même machine, mêmes cartes
-- Embryon de site : http://gilles.ronsin.free.fr Nouvelle astuce : Script de création de raccourcis cible http://gilles.ronsin.free.fr/#targetlnk Il est impossible pour un optimiste d'être agréablement surpris.
T0t0
"Xavier HUMBERT" wrote in message news:1gr93rl.1a14z9b4dijlsN%
Pour l'instant je pense simplement à un disque SCSI amovible (cold-plug, le boîtier coûte une 30aine d'Euros) avec un rsync à chaque mise à jour.
D'autres idées ?
Passer sous OpenBSD avec pf_sync et carp, et deux firewalls :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Xavier HUMBERT" <xavier@injep.fr> wrote in message
news:1gr93rl.1a14z9b4dijlsN%xavier@injep.fr
Pour l'instant je pense simplement à un disque SCSI amovible (cold-plug,
le boîtier coûte une 30aine d'Euros) avec un rsync à chaque mise à jour.
D'autres idées ?
Passer sous OpenBSD avec pf_sync et carp, et deux firewalls :-)
--
Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
"Xavier HUMBERT" wrote in message news:1gr93rl.1a14z9b4dijlsN%
Pour l'instant je pense simplement à un disque SCSI amovible (cold-plug, le boîtier coûte une 30aine d'Euros) avec un rsync à chaque mise à jour.
D'autres idées ?
Passer sous OpenBSD avec pf_sync et carp, et deux firewalls :-)
-- Posted via Mailgate.ORG Server - http://www.Mailgate.ORG
MaXX
Gilles RONSIN wrote:
Une autre partition en mirroring, bootée en cas de défaillance de la première : même machine, mêmes cartes
bonjour, personnellement je ne trouve pas l'idée géniale dans ce cas. Le pépin s'est produit pendant un upgrade de 4.10 vers 4.11, un miroir répliquerait le problème instantanément rendant les 2 disques inutilisables. Tant qu'à utiliser un deuxième disque dans la bécanne, je ne le monterais que le temps de faire une syncro (peu importe la méthode), double avantage, une forme passive de tolérence des pannes (de disque) et si la machine est compromise ET qu'on s'en rend compte avant une syncro on peut revenir à l'état initial facilement et prendre les mesures nécéssaires sur une machine "saine".
C'est pas parfait, ni aussi joli qu'une deuxième machine (tolérence des pannes complète), mais ce n'est pas très couteux...
Bonne journée... MaXX
Gilles RONSIN wrote:
Une autre partition en mirroring, bootée en cas de défaillance de la
première : même machine, mêmes cartes
bonjour,
personnellement je ne trouve pas l'idée géniale dans ce cas. Le pépin s'est
produit pendant un upgrade de 4.10 vers 4.11, un miroir répliquerait le
problème instantanément rendant les 2 disques inutilisables.
Tant qu'à utiliser un deuxième disque dans la bécanne, je ne le monterais
que le temps de faire une syncro (peu importe la méthode), double avantage,
une forme passive de tolérence des pannes (de disque) et si la machine est
compromise ET qu'on s'en rend compte avant une syncro on peut revenir à
l'état initial facilement et prendre les mesures nécéssaires sur une
machine "saine".
C'est pas parfait, ni aussi joli qu'une deuxième machine (tolérence des
pannes complète), mais ce n'est pas très couteux...
Une autre partition en mirroring, bootée en cas de défaillance de la première : même machine, mêmes cartes
bonjour, personnellement je ne trouve pas l'idée géniale dans ce cas. Le pépin s'est produit pendant un upgrade de 4.10 vers 4.11, un miroir répliquerait le problème instantanément rendant les 2 disques inutilisables. Tant qu'à utiliser un deuxième disque dans la bécanne, je ne le monterais que le temps de faire une syncro (peu importe la méthode), double avantage, une forme passive de tolérence des pannes (de disque) et si la machine est compromise ET qu'on s'en rend compte avant une syncro on peut revenir à l'état initial facilement et prendre les mesures nécéssaires sur une machine "saine".
C'est pas parfait, ni aussi joli qu'une deuxième machine (tolérence des pannes complète), mais ce n'est pas très couteux...
Bonne journée... MaXX
xavier
Gilles RONSIN wrote:
Une autre partition en mirroring, bootée en cas de défaillance de la première : même machine, mêmes cartes
Ah oui, mais non... La machine fait mailhub filtrant, et proxy-cache. Le surcoût d'un miroir en terme d'accès disque n'est pas envisageable.
XAv -- Xavier HUMBERT INJEP - NetBSD, parce que je le vaux bien
Gilles RONSIN <nomail@please.invalid> wrote:
Une autre partition en mirroring, bootée en cas de défaillance de la
première : même machine, mêmes cartes
Ah oui, mais non... La machine fait mailhub filtrant, et proxy-cache. Le
surcoût d'un miroir en terme d'accès disque n'est pas envisageable.
XAv
--
Xavier HUMBERT
INJEP - NetBSD, parce que je le vaux bien
Une autre partition en mirroring, bootée en cas de défaillance de la première : même machine, mêmes cartes
Ah oui, mais non... La machine fait mailhub filtrant, et proxy-cache. Le surcoût d'un miroir en terme d'accès disque n'est pas envisageable.
XAv -- Xavier HUMBERT INJEP - NetBSD, parce que je le vaux bien
Alain Montfranc
Le 31/01/2005, Xavier HUMBERT a supposé :
Et de toutes façons, vu le fonctionnement de l'administration, si je stocke une machine, ou même simplement des cartes réseau, il arrivera un jour où elles auront besoin d'être utilisée ailleurs - par ex: panne au mois de novembre, achats gelés donc destockage.
Je connais ce genre de situation. Un moyen de faire passer la chose est de dissocier deux fonctions de la même machine en faisant 2 machines distinctes, failover l'une de l'autre. Des pistes : - firewall - cache DNS - proxy http - proxy mail etc...
Comme ca tu as une sécurité par redondance en justifiant la machine excedentaire par une fonctionalité nécessaire.
En général ca passe :-D
(meme chose pour les budgets, comme ca quand on te "coupe" 50% de ton budgets tu peux qd meme faire les choses, sans oublier de re-reclamer l'argent l'année suivante pour ne pas que ce pseudo-gonflage ne se voit trop ;-))
AM
Le 31/01/2005, Xavier HUMBERT a supposé :
Et de toutes façons, vu le fonctionnement de l'administration, si je
stocke une machine, ou même simplement des cartes réseau, il arrivera un
jour où elles auront besoin d'être utilisée ailleurs - par ex: panne au
mois de novembre, achats gelés donc destockage.
Je connais ce genre de situation. Un moyen de faire passer la chose est
de dissocier deux fonctions de la même machine en faisant 2 machines
distinctes, failover l'une de l'autre. Des pistes :
- firewall
- cache DNS
- proxy http
- proxy mail
etc...
Comme ca tu as une sécurité par redondance en justifiant la machine
excedentaire par une fonctionalité nécessaire.
En général ca passe :-D
(meme chose pour les budgets, comme ca quand on te "coupe" 50% de ton
budgets tu peux qd meme faire les choses, sans oublier de re-reclamer
l'argent l'année suivante pour ne pas que ce pseudo-gonflage ne se voit
trop ;-))
Et de toutes façons, vu le fonctionnement de l'administration, si je stocke une machine, ou même simplement des cartes réseau, il arrivera un jour où elles auront besoin d'être utilisée ailleurs - par ex: panne au mois de novembre, achats gelés donc destockage.
Je connais ce genre de situation. Un moyen de faire passer la chose est de dissocier deux fonctions de la même machine en faisant 2 machines distinctes, failover l'une de l'autre. Des pistes : - firewall - cache DNS - proxy http - proxy mail etc...
Comme ca tu as une sécurité par redondance en justifiant la machine excedentaire par une fonctionalité nécessaire.
En général ca passe :-D
(meme chose pour les budgets, comme ca quand on te "coupe" 50% de ton budgets tu peux qd meme faire les choses, sans oublier de re-reclamer l'argent l'année suivante pour ne pas que ce pseudo-gonflage ne se voit trop ;-))
AM
Olivier Tharan
* Xavier HUMBERT (31 Jan 2005 10:40:26 GMT):
Suite au gag de la màj foireuse de FreeBSD 4.10-p5 -> 4.11 (*), mon chef me demande ce que j'ai pris comme mesures pour remettre debout le firewall en cas de panne. Je veux dire à part aller chez moi rechercher les bonnes sources et revenir compiler en single-user.
Utilise VRRP entre les deux pare-feux, et teste tes mises à jour sur une machine moins critique (on suppose que tu n'as pas le budget pour un truc propriétaire tournant sur FreeBSD de toute façon sous forme de boîte noire).
Solution libre : Freevrrpd. Un exemple ici : http://redundancy.redundancy.org/fbsd_lb.html
-- olive
* Xavier HUMBERT <xavier@injep.fr> (31 Jan 2005 10:40:26 GMT):
Suite au gag de la màj foireuse de FreeBSD 4.10-p5 -> 4.11 (*), mon chef
me demande ce que j'ai pris comme mesures pour remettre debout le
firewall en cas de panne. Je veux dire à part aller chez moi rechercher
les bonnes sources et revenir compiler en single-user.
Utilise VRRP entre les deux pare-feux, et teste tes mises à jour sur une
machine moins critique (on suppose que tu n'as pas le budget pour un
truc propriétaire tournant sur FreeBSD de toute façon sous forme de
boîte noire).
Solution libre : Freevrrpd.
Un exemple ici : http://redundancy.redundancy.org/fbsd_lb.html
Suite au gag de la màj foireuse de FreeBSD 4.10-p5 -> 4.11 (*), mon chef me demande ce que j'ai pris comme mesures pour remettre debout le firewall en cas de panne. Je veux dire à part aller chez moi rechercher les bonnes sources et revenir compiler en single-user.
Utilise VRRP entre les deux pare-feux, et teste tes mises à jour sur une machine moins critique (on suppose que tu n'as pas le budget pour un truc propriétaire tournant sur FreeBSD de toute façon sous forme de boîte noire).
Solution libre : Freevrrpd. Un exemple ici : http://redundancy.redundancy.org/fbsd_lb.html
-- olive
Dominique Blas
MaXX wrote:
Gilles RONSIN wrote:
Une autre partition en mirroring, bootée en cas de défaillance de la première : même machine, mêmes cartes
bonjour, personnellement je ne trouve pas l'idée géniale dans ce cas. Le pépin s'est produit pendant un upgrade de 4.10 vers 4.11, un miroir répliquerait le problème instantanément rendant les 2 disques inutilisables. C'est un peu le << souci >> des miroirs.
Mais tolérance de panne ne signifie pas pour autant absence de sauvegarde. Faut pas confondre !
Je pense effectivement que de nombreuess personnes réagissent en se disant : j'ai un mirroir local et une machine en partage de charge, je n'ai plus rien à craindre. Ben si, ça améliore la disponibilité mais certainement pas l'intégrité des données.
db
-- email : usenet blas net
MaXX wrote:
Gilles RONSIN wrote:
Une autre partition en mirroring, bootée en cas de défaillance de la
première : même machine, mêmes cartes
bonjour,
personnellement je ne trouve pas l'idée géniale dans ce cas. Le pépin
s'est produit pendant un upgrade de 4.10 vers 4.11, un miroir répliquerait
le problème instantanément rendant les 2 disques inutilisables.
C'est un peu le << souci >> des miroirs.
Mais tolérance de panne ne signifie pas pour autant absence de sauvegarde.
Faut pas confondre !
Je pense effectivement que de nombreuess personnes réagissent en se disant :
j'ai un mirroir local et une machine en partage de charge, je n'ai plus
rien à craindre.
Ben si, ça améliore la disponibilité mais certainement pas l'intégrité des
données.
Une autre partition en mirroring, bootée en cas de défaillance de la première : même machine, mêmes cartes
bonjour, personnellement je ne trouve pas l'idée géniale dans ce cas. Le pépin s'est produit pendant un upgrade de 4.10 vers 4.11, un miroir répliquerait le problème instantanément rendant les 2 disques inutilisables. C'est un peu le << souci >> des miroirs.
Mais tolérance de panne ne signifie pas pour autant absence de sauvegarde. Faut pas confondre !
Je pense effectivement que de nombreuess personnes réagissent en se disant : j'ai un mirroir local et une machine en partage de charge, je n'ai plus rien à craindre. Ben si, ça améliore la disponibilité mais certainement pas l'intégrité des données.
db
-- email : usenet blas net
Cedric Blancher
Le Tue, 01 Feb 2005 02:47:01 +0000, Olivier Tharan a écrit :
Utilise VRRP entre les deux pare-feux
VRRP, c'est sympa en effet, mais sur IPv4. VRRP sur IPv6 est breveté par Cisco. D'où la création de CARP.
--
les débilos qui ont décrété qu'il fallait tout éteindre pendant le w.e.!! define(`Y2K_Auto_Purge_Queue',`True')dnl
define(`Y2K_Auto_Murge_Admin',`True')dnl -+- fyr in Guide de l'admin pervers - "Ne pas gâcher son nouvel an" -+-
Le Tue, 01 Feb 2005 02:47:01 +0000, Olivier Tharan a écrit :
Utilise VRRP entre les deux pare-feux
VRRP, c'est sympa en effet, mais sur IPv4. VRRP sur IPv6 est breveté par
Cisco. D'où la création de CARP.
--
les débilos qui ont décrété qu'il fallait tout éteindre pendant le w.e.!!
define(`Y2K_Auto_Purge_Queue',`True')dnl
define(`Y2K_Auto_Murge_Admin',`True')dnl
-+- fyr in Guide de l'admin pervers - "Ne pas gâcher son nouvel an" -+-
Le Tue, 01 Feb 2005 02:47:01 +0000, Olivier Tharan a écrit :
Utilise VRRP entre les deux pare-feux
VRRP, c'est sympa en effet, mais sur IPv4. VRRP sur IPv6 est breveté par Cisco. D'où la création de CARP.
--
les débilos qui ont décrété qu'il fallait tout éteindre pendant le w.e.!! define(`Y2K_Auto_Purge_Queue',`True')dnl
define(`Y2K_Auto_Murge_Admin',`True')dnl -+- fyr in Guide de l'admin pervers - "Ne pas gâcher son nouvel an" -+-
Fabrice
* Xavier HUMBERT (31 Jan 2005 10:40:26 GMT):
Suite au gag de la màj foireuse de FreeBSD 4.10-p5 -> 4.11 (*), mon chef me demande ce que j'ai pris comme mesures pour remettre debout le firewall en cas de panne. Je veux dire à part aller chez moi rechercher les bonnes sources et revenir compiler en single-user.
Utilise VRRP entre les deux pare-feux, et teste tes mises à jour sur une machine moins critique (on suppose que tu n'as pas le budget pour un truc propriétaire tournant sur FreeBSD de toute façon sous forme de boîte noire).
Solution libre : Freevrrpd. Un exemple ici : http://redundancy.redundancy.org/fbsd_lb.html
Attention, en 4.10 avec des interfaces bge tu peux t'assoir sur VRRP.
Solution UCARP mais ne compile que sur une version TRES précise de FreeBSD.
FAbrice
* Xavier HUMBERT <xavier@injep.fr> (31 Jan 2005 10:40:26 GMT):
Suite au gag de la màj foireuse de FreeBSD 4.10-p5 -> 4.11 (*), mon chef
me demande ce que j'ai pris comme mesures pour remettre debout le
firewall en cas de panne. Je veux dire à part aller chez moi rechercher
les bonnes sources et revenir compiler en single-user.
Utilise VRRP entre les deux pare-feux, et teste tes mises à jour sur une
machine moins critique (on suppose que tu n'as pas le budget pour un
truc propriétaire tournant sur FreeBSD de toute façon sous forme de
boîte noire).
Solution libre : Freevrrpd.
Un exemple ici : http://redundancy.redundancy.org/fbsd_lb.html
Attention, en 4.10 avec des interfaces bge tu peux t'assoir sur VRRP.
Solution UCARP mais ne compile que sur une version TRES précise de FreeBSD.
Suite au gag de la màj foireuse de FreeBSD 4.10-p5 -> 4.11 (*), mon chef me demande ce que j'ai pris comme mesures pour remettre debout le firewall en cas de panne. Je veux dire à part aller chez moi rechercher les bonnes sources et revenir compiler en single-user.
Utilise VRRP entre les deux pare-feux, et teste tes mises à jour sur une machine moins critique (on suppose que tu n'as pas le budget pour un truc propriétaire tournant sur FreeBSD de toute façon sous forme de boîte noire).
Solution libre : Freevrrpd. Un exemple ici : http://redundancy.redundancy.org/fbsd_lb.html
Attention, en 4.10 avec des interfaces bge tu peux t'assoir sur VRRP.
Solution UCARP mais ne compile que sur une version TRES précise de FreeBSD.
FAbrice
xavier
Fabrice wrote:
Attention, en 4.10 avec des interfaces bge tu peux t'assoir sur VRRP.
Ca n'est pas grave, le FW va passer prochainement en 5.3, et adieu IPF.
Et là, il y aura évidemment un dump avant :-)
XAv -- Xavier HUMBERT INJEP - NetBSD, parce que je le vaux bien
Fabrice <f.bruelpasdepub@wanadoo.fr> wrote:
Attention, en 4.10 avec des interfaces bge tu peux t'assoir sur VRRP.
Ca n'est pas grave, le FW va passer prochainement en 5.3, et adieu IPF.
Et là, il y aura évidemment un dump avant :-)
XAv
--
Xavier HUMBERT
INJEP - NetBSD, parce que je le vaux bien
