Visite também: UnderLinux ·  VivaOLinux ·  LinuxSecurity ·  Dicas-L ·  NoticiasLinux ·  SoftwareLivre.org ·  [mais] ·  Efetividade ·  Linux in Brazil ·  Floripa  

Firewalls virtualizados em Xen


“Estou usando Xen para para-virtualizar firewalls. São 4 firewalls para cada máquina real, usando 2 placas de rede quad-port. Inclusive, fiz um sistema de backup para a estratégia.

Trecho: "Por ser uma empresa de telefonia e callcenter, cada cliente possui um ou mais tipos de link com a prestadora do serviço, criando assim uma rede local ou remota onde trabalham os atendentes de telemarketing, ou por onde trafegam dados sigilosos. Afim de garantir a segurança e manter a simplicidade de manutenção, impactando ao mínimo no ambiente de produção e isolando qualquer tipo de problema, essas redes são separadas por firewalls independentes, que controlam o acesso entre o cliente e prestadora.

A solução utilizada seria ideal se não fosse a limitação física - consumo demasiado de espaço, racks, servers-select, e principalmente energia (atingindo o limite de seus geradores e no-breaks). Esse é o caso em que se aplicou a solução descrita nesse documento.

Como toda a tecnologia (ou toda a solução), há prós e contras. Citando imediatamente os contras - perde-se nesse momento a segurança do problema físico isolado (apesar de ser o menos comum dos problemas), pois a paralização de um hardware real implicará na paralização de N firewalls. Por fim, ainda é contra a configuração, que não é complexa ao extremo, nem tão simples como poderia ser e, para disolver essa parte do problema, uma estratégia de geração/restauração está contida nesse documento.

Cada hardware real comportará 4 firewalls para-virtualizados. Assim, conta-se como vantagem a redução do parque de máquinas em 75%, além de racks, servers-select e energia. Também as facilitações; a cada uma porta do server-select se acessa de maneira mais ágil o console de 4 firewalls.

Para contar com um ambiente ideal, as máquinas reais são computadores industriais e as placas ethernet, 2 quad-port. Ainda deve-se contar com 1 porta da rede onboard, afim de criar a rede das máquinas reais.

Cada firewall virtual terá uma reserva de 256MB de memória, ou seja - (4.256)+X para a dom0. A dom0 Não necessita de muita memória, porém para atingir algum valor acima de 1GB será necessário adquirir 3 pentes de 512MB ou 2 de 1GB."”


Enviado por Djames Suhanko (djames·suhankoΘgmail·com) - referência (phantomsystem.com.br).

Comentários dos leitores

Os comentários abaixo são responsabilidade de seus autores e não são revisados ou aprovados pelo BR-Linux. Consulte os Termos de uso para informações adicionais. Esta notícia foi arquivada, não será possível incluir novos comentários.
Comentário de msinhore
Lí o seu artigo e gostaria: Lí o seu artigo e gostaria de agregar um comentário para aumentar a segurança de sua rede de firewall: Não use bridges, use pciback para entregar o barramento PCI para o DomU, seria melhor e te daria isolamento físico de seus dispositivos.
Tem tb algumas coisas redundantes. O Xen tem um conjunto de scripts que te possibilita fazer praticamente todas as tarefas que vc já fez com os scripts que existem lá. Vc por exemplo, não precisa configurar as bridges na unha já que o Xen providencia isso.
Te indico este artigo (embora ainda inacabado) para vc ter alguns parametros:
http://wiki.xen-br.org/index.php?title=Rede_com_Xen_rodando_Firewall_e_DMZ_em_um_Debian_AMD64

Aproveito para te convidar para participar do grupo de usuários xen-br. No irc estamos na freenode. nosso wiki é wiki.xen-br.org e temos tb uma lista de discussão em pt_BR.

Abraços

--
Marco Sinhoreli

Comentário de Suhanko
Preciosa dica!: Muito obrigado pela preciosa dica e obrigado pelo convite, Marco!

Comentário de MaxRaven
Parabens: Amigo, parabens pelo texto e pelo trabalho como um todo.
Confesso que sou usuário desktop apenas, entendo muito pouco da parte mais tecnica, mas como todo bom curioso sempre dou uma olhada nos varios aspectos da informática em geral, virtualização sempre me chamou a atenção, mas nunca entendi direito as verdadeiras formas de se utilizar o Xen, já havia visto outras, mas esse modo que usou achei bem interessante e muito bem explicada até mesmo para um leigo como eu.
[]'s
--
http://www.maxraven.info
Comentário de FlavioMachado
Uma sugestão para minimizar: Uma sugestão para minimizar indisponibilidade por problemas de hardware, seja defeito ou parada para manutenção, é usar alguma solução de HA (como o heartbeat, por exemplo) e usar a feature de migração de VMs "quasi-live" que o xen tem. Ele fica copiando as modificações em memória o tempo todo e, com um intervalo mínimo da ordem de algumas centenas de ms, a máquina termina o processo de migração e sobe em outra máquina.

Combinando com uma arquitetura de rede legal, você consegue garantia de disponibilidade, embora aumente custos (dobra o hardware). Mas no fim das contas consegue uma solução melhor que 1 firewall para cada máquina pois seriam necessárias 2x cada firewall para manter redundância também. Sei que a parada de um antes não afetava os outros mas é contrabalançada pelo segundo servidor que fornecerá uma solução melhor que a original.

No fim das contas, tudo é questão de quanto você quer gastar :)

Flávio
--
Registered Linux User #246886
LPI Level 1

"A fé remove montanhas mas eu ainda prefiro dinamite"

Comentário de Joel Cesar Zamboni
Pois é: Muito legal sua solução, parabéns!! Pena que tem uma porta aberta :)
Comentário de Suhanko
Porta aberta?: Que porta aberta?
Comentário de FlavioMachado
Que porta aberta? A do: Que porta aberta? A do heartbeat entre as máquinas, feita por uma interface dedicada, conforme indica o projeto Linux HA? Só não vi onde está a porta aberta. Sem stress, não estou brigando, estou realmente curioso para saber a falha.
--
Registered Linux User #246886
LPI Level 1

"A fé remove montanhas mas eu ainda prefiro dinamite

Comentário de msinhore
HA + Xen + heartbeat: Seria uma solução viável com o live-migration implementado pelo Xen. No estudo da época usei 2 nodos com heartbeat e drbd0.7 e Xen 3.0.3. Funcionou perfeitamente. Faltou implementar a parte do heartbeat para dar o comando xm migrate no momento de shutdown de um sistema ou no caso de crash o outro nodo deveria detectar a queda do serviço e reiniciar a vm (neste caso seria um start da vm completo).
Esta solução está documentada em http://wiki.xen-br.org/index.php?title=Xen-ha e acho que precisa ser atualizada já que o drbd está na versão 0.8 e suporte primary/primary agora e assim seria possível criar algo mais complexo.


--
Marco Sinhoreli

BR-Linux.org
Linux® levado a sério desde 1996. Notícias, dicas e tutoriais em bom português sobre Linux e Código Aberto. "A página sobre software livre mais procurada no Brasil", segundo a Revista Isto É.
Expediente
Sobre o BR-Linux
Enviar notícia ou release
Contato, Termos de uso
FAQ, Newsletter, RSS
Banners e selos
Anunciar no BR-Linux
BR-Linux apóia
LinuxSecurity, Tempo Real
Suporte Livre, Drupal
Verdade Absoluta
Pandemonium
Efetividade, Floripa.net
sites da comunidade
Ajuda
Moderação
Flames: não responda!
Publicar seu texto
Computador para Todos
Notícias pré-2004
Tutoriais, HCL pré-2004