Olá amigos,
A muito tempo que não tenho tido oportunidade de fazer um post por aqui, nem de desenvolver coisas novas, mas hoje isso vai mudar.
Como já sabem sou fervoroso adepto da virtualização, tendo toda a minha infraestrutura de laboratório em dois servidores.
Um destes elementos em ambos os sistemas é um cluster activo-activo de firewalling, que é a continuação do projecto de firewall transparente.
O esquema é algo como isto:
Ambos os sistemas estão permanente activos, distribuindo a carga entre eles, e assegurando que em caso de falha de um dos nós físicos (ou virtuais) o nó sobrevivente terá a capacidade de garantir conectividades futuras e existentes, sem ser necessário um reconnect (por exemplo para sessão de ssh).
Para tal o material que foi necessário, alem dos virtualizadores claro, foram duas instâncias de servidores virtuais linux (cada um com 4 interfaces ethernet).
Como sempre utilizei OpenSUSE 11.1, compilado através do OpenSUSE factory (JeOS).
Os componentes em avulso foram:
- Fwbuilder 4.0 para gerar regras de Firewall (http://www.fwbuilder.org/)
- Conntrackd para garantir que as ligações de firewall estabelecidas são replicadas em ambos os nós da firewall (http://conntrack-tools.netfilter.org/)
- VRRP – Implementação de Virtual Router Redundant Protocol (http://off.net/~jme/vrrpd/)
Na pratica, a FWbuilder apenas constrói as regras de forma a suportar os acesos, e em seguida replica para ambos os nós.
Será sempre necessário que seja atribuído endereçamento para cada das interfaces de ambos os nós (a excepção de interfaces ethernet que sejam elementos de bridge’s). P.exp:
br0 Link encap:Ethernet HWaddr 00:0C:29:3C:E0:78
inet addr:172.16.0.240 Bcast:172.16.0.255 Mask:255.255.255.0
eth2 Link encap:Ethernet HWaddr 00:00:5E:00:01:01
inet addr:172.16.1.245 Bcast:172.16.1.255 Mask:255.255.255.0
e
br0 Link encap:Ethernet HWaddr 00:0C:29:3C:E0:79
inet addr:172.16.0.241 Bcast:172.16.0.255 Mask:255.255.255.0
eth2 Link encap:Ethernet HWaddr 00:00:5E:00:01:02
inet addr:172.16.1.246 Bcast:172.16.1.255 Mask:255.255.255.0
E ainda terão de reservar um terceiro IP que será o vosso endereço VIP (Virtual IP que receberá o pedido, e que sendo independente dos sistemas é gerido pelo VRRP ao nível de userspace do sistema).
Assim sendo, e após construírem as regras que as vossas necessidades exigem, será necessário activarem os elementos necessários para as gateways virtuais.
Estes endereços são activados pelos VRRP’s:
Por exemplo:
/apps/webapp/vrrpd/vrrpd/vrrpd -i br0 -v 1 172.16.0.254 -n
/apps/webapp/vrrpd/vrrpd/vrrpd -i eth2 -v 1 172.16.1.254
Pf notem que no caso das interfaces em bridge (br’s), como o sistema de bridge já efectua a gestão de mac address, tem que se indicar ao vrrpd que não é ele a efectuar o controlo dos mac’s através da flag -n. Sem esta flag a interface bridged irá entrar em loop e falhar.
No caso de interfaces normais, a gestão pode ser efectuada pelo vrrpd (no caso deste exemplo a eth3).
Finalmente, é necessário que ambos os sistemas saibam que ligações estão a ser asseguradas naquele momento. Isto é efectuado através do conntrackd de uma forma totalmente transparente.
Lembrem-se que será necessário configurarem tanto o conntrackd como o vrrpd para comunicarem entre si, e que esta configuração terá de ser replicada ao nível das vossas regras de firewall (não queremos um deny ip any any se ainda não temos comunicação entre o vrrpd e/ou conntrackd).
Links úteis:
Cluster de Firewall com Heartbeat: http://www.fwbuilder.org/4.0/docs/users_guide/heartbeat_cluster.html
Cluster de Firewall para BSD’s e outros: http://www.fwbuilder.org/4.0/docs/users_guide/clusters.html
Cookbook para Firewalls com VRRP e outros: http://www.fwbuilder.org/4.0/docs/users_guide/cluster-cookbook.html
Cookbook para Firewalls com VRRP: http://www.fwbuilder.org/4.0/docs/users_guide/vrrpd_cluster.html
Howtoforge Cookbook para FWbuilder 4.0: http://howtoforge.net/new-features-in-firewall-builder-4.0
Já sabem. Se tiverem duvidas enviem-me mail para nuno at nuneshiggs.com
Abr.