Sistema de Firewalls em Alta Disponibilidade e Balanceamento de Carga

der de Mattos Curso de Redes e Segurana em Sistemas Pontifcia Universidade Catlica do Paran Curitiba, maro de 2010
Resumo A disponibilidade um atributo para todos os servios, especialmente os que so providos atravs da internet/redes privadas e que signica que est disponvel para acesso. Alta disponibilidade est relacionada a provimento de servios que no podem parar, que devem estar sempre disponveis, mesmo com falhas de equipamentos, energia, conectividade ou qualquer outro tipo de adversidade. So tolerantes falhas. Se um sistema parar, poder ocasionar em prejuzo, principalmente em se tratando de operadores de Internet/conectividade, instituies nanceiras, sistemas de comrcio eletronico, dentre outros.

Introduo

O objetivo deste trabalho apresentar um sistema de rewalls operando em redundncia/alta disponibilidada e apto a realizar balanceamento de carga para aplicaes clientes. Apresenta-se dividido em 8 sees, na primeira(esta), a introduo. Na seo 2, uma apresentao sobre disponibilidade e seus fundamentos. Na seo 3, aspectos sobre rewalls. Na sesso 4, sobre balanceamento de carga. Na seo 5, a estrutura de base para o trabalho, o FreeBSD e o desenvolvimento/congurao do projeto. Na seo 6, aspectos relacionados ao funcionamento do sistema e administrao bsica dos softwares. Finalmente na seo 7, os prs e contras da estrutura apresentada e por m, a concluso, na seo 8. Quando uma pessoa acessa algum site ou servio na rede/Internet, ela quer uma resposta rpida, alta qualidade e acima de tudo, que esteja disponvel. A disponibilidade almejada tanto pela pessoa que possui um pequeno site e quer que ele seja visto, quanto uma grande corporao, que possui inmeros servios e precisa que estejam disponveis. A falta da disponibilidade pode gerar inmeros transtornos, sendo os maiores deles, depreciao da imagem e prejuzo nanceiro. Neste contexto, os sistemas computacionais podem ser agrupados em quatro categorias[12], de acordo com a aplicao pretendida: Computao de Propsito Geral, formado pela maior parte dos sistemas, que inclui aplicativos de usurio/prossional, so sistemas que podem parar, sem muito comprometer o curso normal das atividades(comumente resolvido com um restart do sistema) Sistemas de Alta Disponibilidade, formado por um conjunto de servios que podem ser acessados qualquer momento, e disponibilidade a mtrica para tais sistemas, atribuindo um nvel de tolerncia para indisponibilidades. Esto inclusos neste tem: sistemas bancrios e de telecomunicaes.

 Sistemas de Misso Crtica, formado pelos sistemas que possuem completa tolerncia falhas e no podem parar em hiptese alguma, como sistemas de tempo-real, sistemas de controle de trfego areo, militares e de usinas nucleares Sistema de Longa Vida, formado por sistemas com alta conabilidade e que, normalmente, so de manuteno extremamente cara e complexa, como sistemas de satlite e naves espaciais. Para no estar suscetvel a problemas de disponibilidade, empresas criam projetos, realizam treinamentos e, acima de tudo, realizam investimentos para chegar ao objetivo, estar acessvel e funcional. tens como este e outros sero abordados neste trabalho, que expe um modelo de sistema de rewalls, atuando de forma redundante(Sistema de Alta Disponibilidade), servindo de base para uma estrutura de provimento de servios redundantes e tolerante falhas.

Disponibilidade, Conabilidade e MTBF

A denio de conabilidade[12] a probabilidade de operao de um sistema, em um determinado perodo, sem apresentar falhas. apenas um dos muitos fatores que inuenciam a disponibilidade e mede a capacidade de um sistema funcionar sem interrupes durante o fornecimento de um servio/aplicao. O MTBF (mean time between failures) uma mtrica relacionada conabilidade, que mede qual o intervalo de tempo mdio entre duas falhas consecutivas(normalmente medido em horas). Alguns tipos de MTBF so: MTBF de hardware(tempo mdio entre falhas de hardware), MTBF de sistema(tempo mdio entre falhas de sistema, que podem ser minimizadas com a utilizao de hardware redundante), e MTBI(mean time between interruptions, que so falhas temporrias de sistema sem a realizao de reparos). O MTBF no indica exatamente quando a falha ir ocorrer(pois um valor baseado em anlise estatstica), porm em importante ser acompanhado, pois quanto mais tempo em atividade, maior a chance de apresentar problema.

2.1

Disponibilidade

A disponibilidade, em se tratando de sistemas computacionais, um fator muito desejado, tanto para provedores de servios quanto para clientes. A empresa que prov qualquer tipo de servio precisa oferecer mtricas e referncias a respeito do que ela faz para manter o servio disponvel. As mtricas so clculos que levam em conta um grande nmero de variveis, mas que ao m, resulta em um nmero em formato %(percentual). Este nmero explicita o quanto aquele servio esteve estvel no ltimo perodo de aferio. Uma prtica comum utilizar ferramentas/metodologias de gerenciamento para monitorar tais indicadores, levando uma desiganao muito utilizada, apresentada em contratos de fornecimento de servios, que o SLA(Service Level Agreement ou Nvel de Acordo de Servio). O SLA abrange, alm de disponibilidade, tolerncia falhas, performance, prioridade e incidncia de erros, e apresenta o % de disponibilidade do sistema. No controle de tudo est o gerenciamento de servios, que envolve inmeros aspectos, desde equipamentos at a satisfao do cliente.

2.2

Fundamentos de Disponibilidade

Disponibilidade geralmente medida pela taxa de tempo disponvel, que corresponde ao tempo aproximado de disponibilidade e representa a porcentagem de tempo que um sistema computacional est disponvel durante a vida til. Por outro lado, para obter o tempo de indisponibilidade(anual), a mtrica downtime pode ser calculada, de acordo com a seguinte frmula: Downtime(em minutos) = (1 T empoDisponivel) 365 24 60 (1)

O % de disponibilidade calculado da seguinte maneira: M T BF M T BF + M T T R Onde MTBF Mean Time Between Failures e MTTR Mean Time to Repair Disponibilidade = A tabela 1 apresenta os valores de disponibilidade em relao ao perodo de downtime: (2)

Tabela 1: Disponibilidade e Downtime Disponibilidade e Downtime 99% 3,65 dias 99,9% 8,76 horas 99,99% 52,6 minutos 99,999% 5,26 minutos 99,9999% 31,53 segundos 99,99999% 3,15 segundos

2.3

Conabilidade e Disponibilidade

Existe diferenas entre conabilidade e disponibilidade. Dependendo da situao, maiores benefcios podem ser obtidos com conabilidade ao invs da disponibilidade e vice-versa. Casos em que conabilidade mais importante ocorre quando os sistemas esto localizados em reas remotas e com manuteno cara. Embora disponibilidade seja funo da conabilidade e manutenabilidade, possivel sistemas de baixa conabilidade trabalhar em alta disponibilidade, fazendo uso de artifcios como redundncia de equipamentos(quantidade de equipamentos)(N + 1, N + 2, N + N) e redundncia de hardware dentro do equipamento(HDs em raid, fonte redundante, multiplas interfaces de rede, etc). A conabilidade mede a habilidade de um sistema operar continuamente sem interrupes. Um sistema computacional com alto MTBF indica que, em mdia, o sistema opera por longos perodos sem nenhuma interruo por falha de equipamento. Por outro lado, a disponibilidade mede a habilidade de um sistema suportar um determinado nvel de servio. Uma maneira aproximada(90 % de preciso) de converso de conabilidade para disponibilidade[12] a seguinte: t (1 R(t))dt t onde: R(t) a conabilidade de um sistema no perodo de tempo t, e dt o tempo de indisponibilidade(em horas). Disponibilidade = (3)

A conabilidade, R(t), de um sistema representa a probabilidade de um sistema no apresentar falhas em um perodo de tempo t. O valor de 1 - R(t) representa a probabilidade de um sistema apresentar falhas em um perodo de tempo t. Multiplicando 1 - R(t) por dt , aproxima-se o total de tempo indisponvel no mesmo perodo. O valor de t - ( 1 - R(t))dt apresenta o tempo total que um sistema est operando, durante o perodo de tempo t (uptime). Dividindo t - ( 1 - R(t)) dt pelo perodo de tempo total t, obtemos a disponibilidade total.

2.4

Manutenabilidade

Manutenabilidade,M(t), a probabilidade de um servio(manuteno) ser completado durante um perodo t. Se a manutenabilidade for de 0,95 para trs horas, signica que a probabilidade de o servio ser concludo em 3 horas de 95%. Uma alta conabilidade reduz a frequncia de falhas

de sistema e uma alta manutenabilidade reduz a durao de cada incidente de reparo, aumentando a taxa de disponibilidade. Comumente utilizada como mtrica de manutenabilidade, o MTTR o tempo mdio necessrio para o reparo completo(sem incluir o tempo de logstica, somente o tempo de substituio e ao tcnica).

Firewall

Firewall[14], nascido na dcada de 1980, um dispositivo participante de uma rede de computadores com objetivo de seletivamente, permitir ou negar a passagem de dados atravs dele, de um ponto outro da rede, de acordo com polticas/padres adotados. Abrange os equipamentos de ltros de pacotes e de proxy de aplicaes, associados a redes TCP/IP. Pode ser encontrado na forma de software e hardware, ou na combinao de ambos (neste caso, normalmente chamado de appliance). A complexidade de instalao depende do tamanho da rede, da poltica de segurana, da quantidade de regras que autorizam o uxo de entrada e sada de informaes e do grau de segurana desejado. Nos primrdios, o rewall era um ltro de pacotes do conjunto de protocolos TCP/IP(atua nas camadas 2/enlace e 3/rede do modelo OSI), utilizado para criao de listas de acesso e no checava o estado de conexes TCP, apenas poderiam ser criadas regras do tipo: Restringir trfego baseado no endereo IP de origem ou destino; Restringir trfego atravs da porta (TCP ou UDP) do servio. Posteriormente, foi criado o rewall de estado, que armazena o estado das conexes e ltra com base nesse estado(estados: novas conexes, estabelecidas, relacionadas a outras existentes; Firewall Statefull), podendo ser criadas regras do tipo: Restringir trfego baseado no endereo IP de origem ou destino. Restringir trfego atravs da porta (TCP ou UDP) do servio. Restringir o trfego para incio de conexes. Restringir o trfego de pacotes que no tenham sido iniciados a partir da rede protegida. Restringir o trfego de pacotes que no tenham nmero de sequncia corretos. Uma nova propoposta, mais recente que o rewall de estados gateway de aplicao/balanceador de carga, tambm conhecido como rewall de aplicao ou rewall proxy, que compreende um sistema capaz de receber uma conexo, decodicar protocolos na camada de aplicao e interceptar a comunicao entre cliente/servidor para aplicar regras de acesso e posterior permisso/seleo do servidor de destino. Entre as funcionabilidades, inclui: Todas as regras do rewall de estados Restringir acesso FTP a usurios annimos Restringir acesso HTTP para portais de entretenimento Restringir acesso a protocolos desconhecidos na porta 443(HTTPS). J os rewalls de ltima gerao prov soluo comercial para redes de comunicao TCP/IP. Realiza SPI(Stateful Packet Inspection), inspecionando pacotes e trfego de dados baseado nas caractersticas de cada aplicao, nas informaes associadas a todas as camadas do modelo OSI (e no apenas na camada de rede ou de aplicao) e no estado das conexes e sesses ativas, realiza preveno de intruso para ns de identicar o abuso do protocolo TCP/IP mesmo em conexes aparentemente legtimas, e DPI (Deep Packet Inspection), associando as funcionalidades do SPI com as tcnicas dos dispositivos IPS(Intrusion Prevention System).

Balanceamento de Carga

O balanceamento de carga(LB)[13] promove a distribuio de uxo de acesso para dois ou mais servidores, links, processadores, ou outros tipos de recursos. A utilizao do sistema de LB melhora a conabilidade e redundncia, j que uma de suas principais funes compor clusters/farms de servidores(alm de promover alta disponibilidade), permitindo uma diviso de carga entre os participantes. O sistema LB muito utilizado para aplicaes web(e-commerce principalmente), prover servios de FTP, DNS, NTP, dentre outros. Dentre as principais caracetrsticas, encontram-se: Garantir a persistncia das sesses Dividir a carga de maneira assimtrica Acelerao SSL Proteo de ataques de negao de servio Compresso, cache e segurana HTTP Checagem do estado dos participantes de um clustet/farm(se um participante no estiver respondendo corretamente, removido do pool) Filtragem de contedos Fila de prioridade Firewall/IPS Para desempenhar o papel de LB, o escolhido foi o relayd[6]. O relayd um software livre, que atua nas camadas 3 ou 7 do modelo ISO/OSI, capaz de encaminhar e dinamicamente redirecionar conexes que esto chegando em um host. Atua como balanceador de carga, gateway de aplicao ou proxy transparente. capaz de monitorar a disponibilidade de um grupo de hosts e de servios especcos comuns ao grupo. Quando opera realizando redirecionamento em camada 3, ele trabalha em conjunto com o PF, interagindo dinamicamente com as regras/tabelas de rewall. Na modalidade de relay, opera em camada 7, de maneira individual(no necessita do PF), permitindo a ltragem no nvel de aplicao e de protocolos especcos.

Estrutura

Dentre os fatores importantes para a elaborao deste trabalho, alta disponibilidade, baixo investimento e ROI(return on investimet) so os principais. Optou-se por uma estrutura de servidores de plataforma CISC(Complex Instruction Set Computer) AMD64/x86_64(estrutura de 64 bits proposta pela fabricante AMD, compatvel com o conjunto de instrues mais antigo, denominado i386, proposto pela Intel na dcada de 1980). Como caracterstica estrutural de equipamento, foi optado por servidores com disco e fonte redundante(que justamente so os componentes que mais apresentam falhas), com garantia de 36 meses e tempo de resoluo(contrato rmado com o fornecedor, que estabelece um prazo para a resoluo da falha de hardware) de 24 horas e congurado para operao em rack de 1U(1 unidade de rack). Caractersticas de processador, memria e capacidade de disco foram optados por, respectivamente, 1 processador de quatro ncleos e 2GHz, 2GB de memria RAM e disco SAS de 10K RPM e 73GB de espao. Na parte de rede, foram escolhidas 3 interfaces Intel gigabit(2 integradas no servidor e 1 placa pci com 1 interface), devido ao desempenho melhorado por caractersticas de processamento que estas placas possuem(no FreeBSD estas placas so reconhecidas como em0, em1, em2..., devido ao nome do mdulo do kernel, alis, todas as placas de rede nos sistemas BSD adotam como identicao para elas, o nome do mdulo de rewall que implementa a comunicao com o dispositivo de hardware).

5.1

FreeBSD

Na sequncia do trabalho, o sistema operacional escolhido para gerenciar toda a estrutura o FreeBSD [7], que um Sistema Operacional BSD UNIX avanado, com principal objetivo ser muito eciente[4]. Com mais de trinta anos de contnuo desenvolvimento, melhorias e otimizaes, prov um sistema de rede avanado, seguro e de alta performance, utilizado como base para inmeros sitemas de acesso massivo. O FreeBSD um sistema muito robusto, de farta documentao disponvel, que possui um sistema muito eciente de gerenciamento de processos, alocao de memria, utilizao de cpu, uma das melhores pilhas TCP/IP[10], dentre outras inmeras qualidades. Amplamente utilizado para prover servios de DNS, e-mail, ftp, www, rewalls e roteamento. Serve como base de desenvolvimento para fabricantes como Apple, Cisco, Juniper, NetApp, e outras grandes, e utilizado por inmeras empresas para publicao de contedo na web, como Yahoo!, Apache, Sony, Netcraft, Onda(Curitiba). Licenciado sob a licenca BSD[9], permite que seu cdigo fonte seja alterado sem a necessidade de publicar as alteraes realizadas, possibilitando s empresas, desenvolver produtos, comercializ-los, sem ter que divulgar o cdigo fonte editado.

5.2

FreeBSD e Firewall

Em se tratando de servio de rede, o FreeBSD muito competente[2]. Para atuar como rewall, a mesma coisa. capaz de trabalhar com 3 softwares diferentes para desempenhar tal funo[11], IPFILTER (tambm conhecido como IPF), IPFIREWALL (tambm conhecido como IPFW), e OpenBSD PacketFilter[3](tambm conhecido como PF). O FreeBSD tambm possui 2 sistemas de controle de trfego, ALTQ(Alternate Queuing) e dummynet. Dummynet trabalha de maneira incorporada ao IPFW, assim como ALTQ com PF. Tambm possvel a utilizao mesclada das estruturas de rewall e controle de trfego[11], no abordada neste trabalho. A razo para o FreeBSD operar com mltiplos sistemas de rewall permitir que cada pessoa trabalhe de acordo com a preferncia e de acordo com as necessidades. Alguns preferem, por exemplo o IPFILTER para tratar regras de NAT e FTP, devido facilidade de criao das regras. Para o trabalho em questo, o rewall adotado o PF. O PF foi portado do OpenBSD para o FreeBSD em 2003 e em 2004, foi lanada a verso 5.3 do FreeBSD com PF j integrado ao sistema, utilizando ALTQ para prover QoS(qualidade de servio). Junto com o PF, outros dois sistemas trabalham em conjunto: o PFLOG[1] e o PFSYNC[8]. O pog o responsvel pelo tratamento/arquivamento dos logs gerados pelo PF. J o pfsync faz um trabalho mais elaborado. Ele cria uma interface de rede pfsync, responsvel por monitorar todas as alteraes processadas na tabela de estados do PF(o trfego de pfsync encaminhado atravs da interface real ao qual ele est mapeado, enviando os dados ao endereo multicast 224.0.0.240. Como s existem dois rewall, o master envia ao backup. Se existissem mais que dois rewalls ligados com pfsync, todos os backups receberiam as tabelas de conexo do rewall via multicast). Desta maneira, todas as conexes ativas em um rewall podem ser sincronizadas com outro rewall e permitir que, se um rewall parar, outro pode assumir sem que qualquer conexo ativa seja perdida.

5.3

FreeBSD em Alta Disponibilidade

O FreeBSD, um sistema focado em desempenho e uma caracterstica que implementa um sistema de alta disponibilidade incorporada por ele, a partir da verso 5.4, o CARP(Common Address Redundancy Protocol). O carp[3] um protocolo multicast que permite mltiplos hosts compartilhar um ou mais endereos IP, sendo um destes hosts o master que responde por todos os pacotes destinados ao grupo e os demais atuam como backup(se o master/principal falhar, o backup assume). Para o correto funcionamento do CARP, as seguintes linhas devem ser adicionadas ao arquivo /etc/sysctl.conf e aplicadas ao sistema:

net.inet.carp.allow=1 net.inet.carp.preempt=1 net.inet.carp.log=1

#faz com que se 1 interface carp cair, todas as outras #passam para backup e o outro firewall assume. #ativa a gerao de logs pelo carp

Pode ser utilizado tanto para disponibilidade quanto para balanceamento de carga. Mas a utilizao do carp por si s no faz o tabalho completo, pois a funo dele manter o IP ativo e disponvel. E as conexes que estavam ativas no momento da "falha", foram perdidas? a que entra em cena o pf/pfsync. O conjunto PF + CARP + PFSYNC permite que dois sistemas funcionem de modo redundante e em alta disponibilidade. Se um falhar o outro assume. Ainda falando em disponibilidade, para prover um sistema

5.4

Desenvolvimento

Para a elaborao do projeto, foram necessrios 2 servidores(descritos anteriormente), instalados com o FreeBSD. Detalhes de como instalar, atualizar, recompilar o kernel, realizar otimizaes e demais informaes relacionadas ele, podem ser obtidas acessando o handbook no site: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html. A gura 1 ilustra o modelo da estrutura pretendida.

carp0

FW1 em0
em2 pfsync

em0 em2

FW2

em1

em1

carp1

carp2

cluster/farm SMTP

cluster/farm WEB

Figura 1: Estrutura em Alta Disponibilidade

Tomados os 2 servidores j instalados, com o ports[11] instalado e o sistema operacioanl atualizados, para ativar as funcionalidades pretendidos necessrio recompilar o kernel(ncleo) do FreeBSD, com a incluso dos seguintes mdulos/opes: device pf device pflog device pfsync device vlan device carp options ALTQ options ALTQ CBQ options options options options options options options #(habilita o PF) #(habilita a gerao de logs no PF) #(habilita o sincronismo entre 2 sistemas PF) #(habilita o suporte vlan, no utilizado) #(habilita o suporte a CARP) #(habilita o suporte ao altq) #(habilita o suporte ao controle de fila CBQ #Class Based Queuing ) ALTQ RED #(habilita o suporte ao controle de congestionamento RED #Random Early Detection ) ALTQ RIO #(habilita o suporte ao controle de congestionamento RIO #Random Early Detection In and Out) ALTQ HFSC #(habilita o suporte ao controle de fila hierrquica HFSC #Hierarchical Fair Service Curve Packet Scheduler) ALTQ PRIQ #(habilita o suporte ao controle de fila PRIQ #Priority Queuing ) ALTQ NOPCC #(habilita o suporte sistemas SMP - multiprocessados) DEVICE POLLING #(habilita o tratamento de dispositivos atravs de POLLING) HZ=1000 #(define a granularidade do timer do sistema(em 1ms), #melhora o tratamento de taxa de trfego alta)

Com o kernel pronto, parte-se para a instalao do software relayd. Para realizar a instalao, foi utilizado o ports, da seguinte maneira: root# cd /usr/ports/net/relayd root# make install clean (entrar no diretrio do software que se deseja instalar) (baixa o cdigo fonte do software da internet, compila, instala e limpa o que restou do processo de compilao)

O passo seguinte habilitar a inicializao/execuo dos servios. No arquivo /etc/rc.conf, deve ser adicionado: pf_enable="YES" pf_rules="/path/to/pf.conf" pf_program="/sbin/pfctl" pfsync_enable="YES" pfsync_syncdev="em2" pflog_enable="YES" pflog_logfile="/var/log/pflog" pflog_program="/sbin/pflogd" gateway_enable="YES" relayd_enable="YES" #(permite a execuo do PF) #(localizao do arquivo que define regras) #(local que est o pfctl - controla o PF) #(permite a execuo do PFSYNC) #(interface de rede que o PFSYNC utilizar) #(para ativar a criao de logs no PF) #(local onde o PF gravar os logs) #(local que est o binrio pflog) #(habilita ao de gateway/router) #(habilita a execuo do relayd)

A congurao de rede outro ponto fundamental e que deve ser realizada com muita ateno. Como se trata de uma estrutura complexa, existe vrios detalhes que precisam ser ajustados de modo a garantir o funcionamento do sistema. A estrutura de rewalls compreende dispor de dois servidores trabalhando em alta disponibilidade, um servidor(chamado aqui de fw1) ser escolhido para operar como master e o outro(chamado de fw2) ser o backup. A tabela 2 apresenta o relacionamento de IPs[5] com interfaces utilizadas:

Tabela 2: Endereamento de Rede Endereamento de Equipamento Interface Gateway default FW1 em0(WAN) FW1 em1(LAN) FW1 carp0 FW1 carp1 FW1 carp2 FW1 em3(pfsync) FW2 em0(WAN) FW2 em1(LAN) FW2 carp0 FW2 carp1 FW2 carp2 FW2 em3(pfsync) SMTP1 X SMTP2 Y WEB1 Z WEB2 W Cliente Remoto K teste WEB1 Cliente Remoto K teste WEB2 Rede IP/Netmask 192.0.2.254/24 192.0.2.1/24 198.51.100.1/24 192.0.2.3/24 198.51.100.3/24 198.51.100.4/24 203.0.113.1/30 192.0.2.2/24 198.51.100.2/24 192.0.2.3/24 198.51.100.3/24 198.51.100.4/24 203.0.113.2/30 198.51.100.10/24 198.51.100.11/24 198.51.100.20/24 198.51.100.21/24 192.0.2.100/24 192.0.2.101/24

Para congurar o sistema de rede no fw1, deve ser adicionado ao arquivo /etc/rc.conf o seguinte contedo: defaultrouter="192.0.2.254" #rota/gateway default hostname="fw1.teste.com.br" #hostname associado ao firewall/LB 1, no domnio teste.com.br ifconfig_em0="inet 192.0.2.1 netmask 255.255.255.0" #(onde ifconfig_em0 a interface, inet 192.0.2.1 o IP e #netmask 255.255.255.0 a mscara de rede) ifconfig_em1="inet 198.51.100.1 netmask 255.255.255.0" ifconfig_em2="inet 203.0.113.1 netmask 255.255.255.252" #(esta interface est ligada ao fw2 atravs de um cabo cross) cloned_interfaces="carp0 carp1 carp2" #(Esta entrada cria as interfaces virtuais carp0, carp1 e carp2) ifconfig_carp0="vhid 100 advskew 10 pass @abc0 10.0.0.3/29" #(onde ifconfig_carp0 a interface virtual, vhid 100 o id #da interface virtual, advskew 10 o valor de peso para a eleio #master/backup - quanto menor o valor, mais prioridade de virar master, #pass @abc} a senha utilizada para permitir a autenticao #entre o carp de dois servidores, e 10.0.0.3/29 o ip virtual) ifconfig_carp1="vhid 101 advskew 10 pass @abc1 198.51.100.3/24" ifconfig_carp2="vhid 102 advskew 10 pass @abc2 198.51.100.4/24"

No fw2: defaultrouter="192.0.2.254" ifconfig_em0="inet 192.0.2.2 netmask 255.255.255.0" ifconfig_em1="inet 198.51.100.2 netmask 255.255.255.0" ifconfig_em2="inet 203.0.113.2 netmask 255.255.255.252" cloned_interfaces="carp0 carp1 carp2" ifconfig_carp0="vhid 100 advskew 100 pass @abc0 192.0.2.3/24" ifconfig_carp1="vhid 101 advskew 100 pass @abc1 198.51.100.3/24" ifconfig_carp2="vhid 102 advskew 100 pass @abc2 198.51.100.4/24" Aps congurada a rede, o prximo passo congurar o relayd, a princpio para realizar balanceamento de carga para dois servios escolhidos, SMTP(Simple Mail Tranfer Protocol - envio de e-mails) e HTTP. Para SMTP, a congurao focada no princpio de redirect, presente no relayd. Para o HTTP, relay. O funcionamento do redirect bem simples, fazendo uso de uma regra de rewall(PF) rdrto e redirecionando(com persistncia de estados) aos hosts ativos nas tabelas especcas. O rewall/LB(daqui pra frente chamado de LB) passa a mapear um IP e porta pertencente ele. Qualquer conexo entrante que chega ao LB direcionada ao IP/porta interceptada, redirecioando o servio pretendido ao host do cluster/farm que dever receber a conexo no momento. O host processa a requisio e a retorna ao LB, que responder ao cliente que solicitou a requisio. A gura 2 ilustra como ocorre a comunicao.

Cluster/farm IP_1

IP_2

IP_3

2
IP_4

LB

IP_5

Figura 2: Modelo de redirect

As estapas 1, 2, 3 e 4 correspondem : 1 - A requisio sai do cliente com IP_1 e destino ao servio(IP virtual presente no LB) de IP_3. 2 - Ao chegar ao LB, este manipula os pacotes e altera o endereo de destino, de IP_3 para IP_4 ou IP_5. 3 - O servidor(agora origem) que recebeu a requisio responde ao solicitante(destino), IP_1, envaminhando os dados ao LB. 4 - Ao chegar no LB, este manipula os pacotes novamente e altera o endereo de origem para IP_3 e envia a resposta ao cliente. Na modalidade de relay(proxy), a forma como o LB trabalha mais complexa. O relayd ir encaminhar o trfego entre cliente e servidor, em contraste ao redirecinamento, ele ir criar um socket que escutar e aceitar conexes entrantes, em um IP e portas denidos na congurao. Qualquer conexo realizada no IP/porta ser tratado como se o LB fosse o servidor, ele far o

10

proxy das conexes(ao mesmo tempo que realizar uma conexo com o host que dever receber a requisio) e ele passar a intermediar a relao cliente/servidor, operando em camada 7(tambm chamado de gateway de aplicao ou proxy de camada 7). O propsito da funo relay prover um balanceamento de carga avanado, baseado em caractersticas especcas de protocolos, tais como cabealhos HTTP, acelerao SSL ou manipular outros protocolos em nvel de aplicao. A gura 3 ilustra como ocorre a comunicao.
Cluster/farm LB IP_1 IP_4 IP_2 IP_3

2
IP_5

Figura 3: Modelo de relay

As estapas 1 e 2 correspondem : 1 - A requisio sai do cliente com IP_1 e destino ao servidor(IP virtual presente no LB) de IP_3. Ao chegar ao LB, o LB realiza um proxy(mantendo ativa a conexo do cliente ele). Posteriormente, encaminhar os dados de resposta dos servidores(IP_4 ou IP_5) ao cliente de IP_1. 2 - partir LB(que mantm a conexo do cliente e faz proxy da conexo), este realiza uma conexo de sada com o servidor que dever responder solicitao(IP_4 ou IP_5, de acordo com a poltica de balanceamento) e encaminha os dados do cliente remoto ao servidor, operando em camada 7. Quando o servidor responder(responder ao IP_3) ao LB, este encaminhar os dados ao cliente remoto de IP_1. Para congurar o relayd, deve ser criado/editado o arquivo /usr/local/etc/relayd.conf com as seguintes opes: ################################################################################# ## GLOBAL ################################################################################# interval 5 #tempo entre checagem dos hosts, em segundos timeout 1000 #tempo que aguarda a resposta da checagem, em milisegundos prefork 8 #nmero de processos(quando opera em relay) que trata o relay de #conexes log updates #grava em log apenas as atualizaes. Por padro grava os logs em #syslog ################################################################################# ################################################################################# ## HOSTS ################################################################################# SMTP1="198.51.100.10" #IP do servidor SMTP1 SMTP2="198.51.100.11" #IP do servidor SMTP2 WEB1= "198.51.100.20" #IP do servidor WEB1 WEB2= "198.51.100.21" #IP do servidor WEB2

11

################################################################################# ################################################################################# ## BIND DE SERVIO ################################################################################# smtp="198.51.100.3" #IP virtual alocado no LB, que receber as requies #destinadas ao servio de SMTP. web= "198.51.100.4" #IP virtual alocado no LB, que far proxy das requisies #destinadas ao servio HTTP. ################################################################################# ################################################################################# ## TABELAS ################################################################################# table <SMTP> { $SMTP1, $SMTP2 } #tabela que contm os servidores que iro #responder pelo servio de SMTP. No exemplo em #questo, uma conexo ir para o servidor SMTP1 #e a prxima para o SMTP2(em torno de 50% das #conexes para cada um e de acordo com a poltica # de balanceamento). Se a entrada fosse: #table <SMTP> { $SMTP1, $SMTP1, $SMTP2 },o SMTP1 #receberia em torno de 66% e o SMTP2, 34% das #conexes. table <WEB> { $WEB1, $WEB2 } ################################################################################# ################################################################################# ## AES ################################################################################# redirect SMTP #funo de redirect para SMTP(SMTP um #label qualquer) { listen on $smtp port 25 #onde listen on $smtp port 25 significa que o #relayd "escutar" no IP $smtp e na porta 25 TCP tag RELAYD_SMTP #onde tag RELAYD_SMTP marca as conexes por ele #atendidas, para ser tratadas pelo firewall PF

forward to <SMTP> port 25 mode roundrobin check tcp #onde forward to <SMTP> port 25 significa que as #conexes recebidas sero encaminhadas aos #participantes da tabela <SMTP> na porta 25, #mode roundrobin significa que as conexes #encaminhadas tabela <SMTP> sero balanceadas #da forma round-robin entre os participantes } protocol "WWW" { #Define um protocolo utilizado como template #para aes e configuraes para o relay

12

tcp { nodelay, socket buffer 65536 } #Define como protocolo o TCP e utiliza as opes: nodelay(recomendada #para prevenir delay/atraso em conexes que encaminham steram de dados, #socket buffer 65536 define o tamanho do buffer de recebimento e envio #em 65kbytes, afetando o tamanho da janela TCP } relay "WWWforward" { listen on $web port 80 #define a funo relay, com label WWWforward

#onde listen on $web port 80 significa que o #relayd "escutar" no IP $web na porta 80 TCP protocol "WWW" #define a utilizao do protocolo WWW no relay forward to <WEB> port 80 mode loadbalance timeout 600 check tcp #onde forward to <WEB> port 80 significa que #as conexes recebidas sero encaminhadas aos #participantes da tabela <WEB> na porta 80, #mode loadbalance significa que as conexes #encaminhadas tabela <SMTP> sero balanceadas #de acordo com a carga recebida entre os #participantes(balanceia as conexes de sada #entre os hosts ativos e aptos, baseada no #nome da tabela hash, no endereo de origem e #destino e na porta correspondente.)

} ################################################################################# Na sequncia, necessria a congurao do PF[8][1], para permitir a correta interao com o relayd e a passagem dos dados destinados aos servidores e demais trfegos liberados. Para isso, deve ser editado/criado o arquivo /etc/pf.conf com as seguintes entradas(a congurao a mesma para os 2 LB): ################################################################################# ## GLOBAL ################################################################################# set limit { states 200000, frags 100000, src-nodes 130000 } #configura limites mximos aceitveis para a tabela de estados do #do firewall: 200000 de estados, 100000 de fragmentos, e 130000 origens #diferentes de conexo set block-policy return #configura a poltica padro de bloqueio set loginterface em0 #configura como interface que monitora a gerao de logs a WAN(em0) set debug urgent #ativa a opo de debug urgent set timeout { interval 10, frag 30 } set timeout { tcp.first 60, tcp.opening 30, tcp.established 3600 } set timeout { udp.first 20, udp.single 10, udp.multiple 15 } set timeout { icmp.first 11, icmp.error 6 } set timeout { other.first 40, other.single 20, other.multiple 30 } #configurao para tratamento de timeouts para TCP, UDP, ICMP e outros

13

scrub in all fragment reassemble no-df scrub out all random-id #ativa normalizao de pacotes fragmentados tando para entrada quanto #para sada do firewall ################################################################################# ## GLOBAL ################################################################################# ################################################################################# ## TABELAS/MACROS ################################################################################# ## INTERFACES ################################################################################# wan= "em0" #macro que atribui WAN como em0 lan= "em1" #macro que atribui LAN como em1 syncpf= "em2" #macro que atribui PFSYNC/syncpf como em2 ################################################################################# ## REDES ################################################################################# table <admin> { 192.0.2.0/24 } #tabela que define uma rede administrativa table <firewall> { 192.0.2.0/30, 198.51.100.0/30, 198.51.100.4, 203.0.113.0/30 } #tabela que define os IPS do firewall table <invalidos> { 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 } #tabela que define redes invlidas ################################################################################# ## SERVIDORES ################################################################################# smtp1="{ 198.51.100.10 }" #macro que atribui smtp1 como 198.51.100.10 smtp2="{ 198.51.100.11 }" #macro que atribui smtp2 como 198.51.100.11 web1= "{ 198.51.100.20 }" #macro que atribui web1 como 198.51.100.20 web2= "{ 198.51.100.21 }" #macro que atribui web2 como 198.51.100.21 ################################################################################# ## GRUPOS ################################################################################# smtp= "{ $smtp1, $smtp2 }" #macro que atribui SMTP como grupo de smtp1 e smtp2 web= "{ $web1, $web2 }" #macro que atribui SMTP como grupo de web1 e web2 ################################################################################# ## CARPS ################################################################################# carp_smtp="{ 198.51.100.3 }" #macro que atribui carp_smtp como 198.51.100.3 carp_web= "{ 198.51.100.4 }" #macro que atribui carp_web como 198.51.100.4 ################################################################################# ## Tabelas de Portas ################################################################################# portas_lixo="135 137 139 445" #portas de trfego bloqueado

14

################################################################################# ## TABELAS #################################################################################

################################################################################# ## QoS/FILAS ################################################################################# ##QoS padrao para UPLOAD. no ser necessrio o controle de download ################################################################################# altq on { em0 } hfsc bandwidth 1Gb qlimit 500 queue { default, servio } #ativa confrolador de banda altq, na interface em0, com poltica de controle #de fila hierrquica HFSC, largura de banda de 1Gbps, qlimit(nmero de #pacotes mantidos em fila) de 500, e 2 filas definidas, default e servio queue default bandwidth 10Mb qlimit 75 priority 2 hfsc\ ( default realtime 10Mb upperlimit 10Mb red ) #a fila default definida com 10Mbps, fila de 75 pacotes, prioridade 2 #(entre 1 e 7, quanto maior, mais prioridade), utiliza como poltica de #controle de fila hierrquica HFSC, fila default, com garantia de 10Mbps e #limite de 10Mbps com poltica de descarte RED queue servico bandwidth 600Mb qlimit 300 priority 7 hfsc\ ( linkshare 600Mb upperlimit 600Mb red ) { smtp, web, ssh } #fila servio, com 600Mbps, 300 pacotes de tamanho de fila, prioridade 7, #controle de fila hierrquica, permite compartilhar entre suas duas subfilas #600Mbps e limite de 600Mbps, compoltica de descarte RED e define trs #subfilas, smtp, web e ssh queue smtp bandwidth 250Mb qlimit 300 priority 6 hfsc\ ( realtime 250Mb red upperlimit 500Mb red ) #fila smtp, com 250Mbps, fila de 300 pacotes de tamanho, prioridade 6, #controle de fila hierrquica, com garantia de 250Mbps, poltica de descarte #RED, limite de utilizao compartilhada de at 500Mbps e poltica de #descarte RED. O RED pode ser utilizado tanto para linkshare, quanto realtime, #quanto para upperlimit. queue web bandwidth 250Mb ( queue ssh bandwidth 100Mb ( qlimit 300 priority 5 hfsc\ realtime 250Mb red upperlimit 500Mb red ) qlimit 300 priority 7 hfsc\ realtime 100Mb red upperlimit 600Mb red )

################################################################################# ## QoS/FILAS #################################################################################

################################################################################# ## DIRECIONAMENTOS #################################################################################

15

## Relayd rdr-anchor "relayd/*"

#Ativa o redirecionamento, utilizado pelo relayd

################################################################################# ## DIRECIONAMENTOS ################################################################################# ################################################################################# ### REGRAS ################################################################################# ## ADMIN ################################################################################# pass in quick on $wan inet proto 1 from <admin> to any keep state queue ssh #icmp, regra para aceitar ping da rede admin, com manuteno de estados #a diretiva quick faz com que a regra, ao ser validada por algum trfego, #seja aplicada. Caso contrrio, todas as regras sero percorridas e apenas a #ltima validada ser aplicada. Em resumo, com quick, ao encontrar o 1o match #ele aplica e sai, seno, o ltimo match ser acplicado. pass quick on { $wan carp0 } inet proto tcp from <admin> to any port ssh \ modulate state queue ssh #ssh, regra para permitir acesso ssh da rede admin, com manuteno de estados #e criar nmeros iniciais de sequncia randmica de alta qualidade para #as conexes TCP e previne ataques de tempestades de ACK. A diretiva queue ssh #associa a regra fila definida no ALTQ para QoS. pass quick from <firewall> to any keep state queue ssh #permite que o firewall alcance qualquer outro equipamento via ssh ################################################################################# ## LIBERA ENTRE FIREWALLS ################################################################################# pass quick on $syncpf proto pfsync keep state pass quick on { $wan $lan carp0 carp1 carp2 } proto carp modulate state queue ssh pass quick on { $wan $lan carp0 carp1 carp2 } proto IGMP modulate state queue ssh pass quick on $syncpf from 203.0.113.0/30 to any keep state queue ssh ################################################################################# ## BLOQUEIOS PADRAO DE PORTAS LIXO ################################################################################# block return-icmp in log quick inet proto tcp from any to any port \ { $portas_lixo } label "BLOCK PORTAS LIXO " block return-icmp in log quick inet proto udp from any to any port \ { $portas_lixo } label "BLOCK PORTAS LIXO " block return-icmp out log quick inet proto tcp from any to any port \ { $portas_lixo } label "BLOCK PORTAS LIXO " block return-icmp out log quick inet proto udp from any to any port \ { $portas_lixo } label "BLOCK PORTAS LIXO " block in quick log proto tcp from any to any port { $portas_lixo } \ label "BLOCK PORTAS LIXO "

16

block in

quick log proto udp from any to any port { $portas_lixo } \ label "BLOCK PORTAS LIXO " block out quick log proto tcp from any to any port { $portas_lixo } \ label "BLOCK PORTAS LIXO " block out quick log proto udp from any to any port { $portas_lixo } \ label "BLOCK PORTAS LIXO " ################################################################################# ## Protecoes anti spoof ################################################################################# block return-icmp in log quick inet from <invalidos> to any label "INVLIDOS" antispoof quick for lo0 pass quick on lo0 all #################################################################################

## SMTP ################################################################################# pass in quick on $wan inet proto tcp from any to $smtp port 25 synproxy state \ tagged RELAYD_SMTP queue smtp # Regra que interage com o RELAYD, tratando as conexes marcadas com a TAG # RELAYD_SMTP. A diretiva synproxy state fora a realizao do handshake # completo e cria um tratamento da conexo semelhante um proxy e ajuda a # prevenir problemas relacionados a ataques de envios de ACK/SYN. pass in quick on $wan inet proto tcp from any to $carp_smtp port 25 \ synproxy state tagged RELAYD_SMTP queue smtp ################################################################################# ## WEB/HTTP ################################################################################# pass in quick on $wan inet proto tcp from any to $web port 80 \ modulate state queue web pass in quick on $wan inet proto tcp from any to $carp_web port 80 \ modulate state queue web ################################################################################# ## RETORNO ################################################################################# pass out keep state ################################################################################# ## BLOQUEIA O RESTO ################################################################################# block log from any to any ################################################################################# ################################################################################# ### REGRAS #################################################################################

17

Funcionamento

O funcionamento do sistema complexo, porm simples de ser gerido e mantido. Como mensionado anteriormente, o FreeBSD apresenta farta documentao e de acesso facilitado atravs do site: http://www.freebsd.org. A operao bsica do sistema consiste em parar e iniciar servios e ajustes de congurao. Para manipular os servios de rede no FreeBSD, deve ser considerados dois pontos distintos: programas e servios que so nativos do SO e programas e servios instalados de terceiros. Todos os servios que j vm com o FreeBSD podem ser controlados a partir de /etc/rc.d/Nome_Do_Servico start|stop . . . , para servios como o pf, pfsync, pog, syslog, dentre outros. J os instalados(contrudos) por terceiros, estaro em outra localizao, em /usr/local/erc/rc.d/Nome_Do_Servico start|stop. . . , para softwares como relayd, net-snmp, postx, e outros. De incio, os dois LB podem ser ligados em qualquer ordem, apenas respeitando a congurao das interfaces de rede(a terceira interface/em2 ligada entre os dois LB via cabo crossover). Aps ligados, os dois LB devero possuir a seguinte sada(se ligado em portas gigabit de switch) para a execuo do comando ifcong (exceto para as interfaces CARP, que em um dos LB ter status MASTER e no outro BACKUP): em0: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=1db<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,POLLING,VLAN_HWCSUM,TSO4> ether 00:04:23:b1:e7:5c inet 192.0.2.1 netmask 0xffffff00 media: Ethernet autoselect (1000baseTX <full-duplex>) status: active em1: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=1db<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,POLLING,VLAN_HWCSUM,TSO4> ether 00:04:23:b1:e7:5d inet 198.51.100.1 netmask 0xffffff00 media: Ethernet autoselect (1000baseTX <full-duplex>) status: active em2: flags=8943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST> metric 0 mtu 1500 options=1db<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,POLLING,VLAN_HWCSUM,TSO4> ether 00:11:43:d9:a4:a2 inet 203.0.113.0.1 netmask 0xfffffffc media: Ethernet autoselect (1000baseTX <full-duplex>) status: active lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4 inet6 ::1 prefixlen 128 inet 127.0.0.1 netmask 0xff000000 pfsync0: flags=41<UP,RUNNING> metric 0 mtu 1460 pfsync: syncdev: em2 syncpeer: 224.0.0.240 maxupd: 128 carp0: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 192.0.2.3 netmask 0xffffff00 carp: MASTER vhid 100 advbase 1 advskew 10 carp1: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 198.51.100.3 netmask 0xffffff00 carp: MASTER vhid 101 advbase 1 advskew 10 carp2: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 198.51.100.4 netmask 0xffffff00 carp: MASTER vhid 102 advbase 1 advskew 10 No FW2, a sada do comando(para as interfaces CARP ) ser:

18

carp0: flags=49<UP,LOOPBACK,RUNNING> metric 0 inet 192.0.2.3 netmask 0xffffff00 carp: BACKUP vhid 100 advbase 1 advskew carp1: flags=49<UP,LOOPBACK,RUNNING> metric 0 inet 198.51.100.3 netmask 0xffffff00 carp: BACKUP vhid 101 advbase 1 advskew carp2: flags=49<UP,LOOPBACK,RUNNING> metric 0 inet 198.51.100.4 netmask 0xffffff00 carp: BACKUP vhid 102 advbase 1 advskew

mtu 1500 100 mtu 1500 100 mtu 1500 100

Assim, o FW1 responde pelo acesso entre as redes WAN e LAN, se caso alguma interface falhar(houver queda de link/camada 1 e 2), o FW2 assume em no mximo 2 segundos. Vale apena ressartar, que o processo de queda do FW1 e assumir do FW2 no interrompe/fecha conexes abertas, uma vez que todas as tabelas de conexes ativas do FW1 so enviadas ao FW2 via PFSYNC. Para obter o status do pf, pode ser executado o seguinte comando: root# /etc/rc.d/pf status Status: Enabled for 269 days 09:23:31 Interface Stats for bge0 Bytes In Bytes Out Packets In Passed Blocked Packets Out Passed Blocked State Table current entries searches inserts removals Counters match bad-offset fragment short normalize memory bad-timestamp congestion ip-option proto-cksum state-mismatch state-insert state-limit src-limit synproxy IPv4 12565507959096 25381148856613 23262007918 390198167 75395100311 176675512 Total 5634 238741295155 4352087757 4352098551 4357434853 0 373 6 11427 0 0 0 1558 126979 3725936 0 0 0 534631541 Debug: Urgent IPv6 166063 0 413 1624 0 0 Rate 10257.2/s 187.0/s 187.0/s 187.2/s 0.0/s 0.0/s 0.0/s 0.0/s 0.0/s 0.0/s 0.0/s 0.0/s 0.0/s 0.2/s 0.0/s 0.0/s 0.0/s 23.0/s

Caso seja necessria a inverso entre master e backup(realizar alguma manuteno ou por outro motivo qualquer), basta alterar a prioridade advskew do LB, atravs do comando ifcong, de acordo com as seguintes etapas:

19

1. descobrir qual o advskew de cada carp do LB atravs do comando: root# ifconfig que exibir a seguinte sada das interfaces carp para o LB1: carp0: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 192.0.2.3 netmask 0xffffff00 carp: MASTER vhid 100 advbase 1 advskew 10 carp1: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 198.51.100.3 netmask 0xffffff00 carp: MASTER vhid 101 advbase 1 advskew 10 carp2: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 198.51.100.4 netmask 0xffffff00 carp: MASTER vhid 102 advbase 1 advskew 10 e para o LB2: carp0: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 192.0.2.3 netmask 0xffffff00 carp: BACKUP vhid 100 advbase 1 advskew 100 carp1: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 198.51.100.3 netmask 0xffffff00 carp: BACKUP vhid 101 advbase 1 advskew 100 carp2: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 198.51.100.4 netmask 0xffffff00 carp: BACKUP vhid 102 advbase 1 advskew 100 2. alterar o advskew de modo que o valor para o LB2 seja menor que o LB1(alterando somente em LB1) root# ifconfig carp0 advskew 200 && ifconfig carp1 advskew 200 &&\ ifconfig carp2 advskew 200 3. conferir os resultados: em LB1: carp0: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 192.0.2.3 netmask 0xffffff00 carp: BACKUP vhid 100 advbase 1 advskew 200 carp1: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 198.51.100.3 netmask 0xffffff00 carp: BACKUP vhid 101 advbase 1 advskew 200 carp2: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 198.51.100.4 netmask 0xffffff00 carp: BACKUP vhid 102 advbase 1 advskew 200 e para o LB2: carp0: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 192.0.2.3 netmask 0xffffff00 carp: MASTER vhid 100 advbase 1 advskew 100

20

carp1: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 198.51.100.3 netmask 0xffffff00 carp: MASTER vhid 101 advbase 1 advskew 100 carp2: flags=49<UP,LOOPBACK,RUNNING> metric 0 mtu 1500 inet 198.51.100.4 netmask 0xffffff00 carp: MASTER vhid 102 advbase 1 advskew 100 Com a realizao deste processo, ocorreu a troca entre master e backup, sem perdas de conexes, nem momentos de indisponibilidade do sistema. Em relao ao relayd, este garante que a conectividade/acesso aos servidores, em caso de falha de um deles, no gere indisponibilidade completa do sistema, alis, ele manter o servidor que apresentou problema indisponvel, mandando todas as requisies para os demais servidores ativos. Para manipular o relayd, deve ser utilizado o programa relayctl, presente em /usr/local/sbin/relayctl. O status do funcionamento do relayd pode ser obtido executando: root# Id 0 10 20 21 0 11 22 23 relayctl show summary Type Name redirect SMTPSERVER table SMTP:25 host 198.51.100.10 host 198.51.100.11 relay WWWforward table WEB:80 host 198.51.100.20 host 198.51.100.21

Avlblty Status active active (2 hosts up) 100.00% up 100.00% up active active (2 hosts up) 100.00% up 100.00% up

A funo de habilitar/desabilitar algum host que faa parte de um cluster, por exemplo, remover o host 198.51.100.10(Id 20 do sumrio) do servio SMTP, pode ser feita da seguinte maneira: root# relayctl host disable 20 Para ver o resultado: root# Id 0 10 20 21 0 11 22 23 relayctl show summary Type Name redirect SMTPSERVER table SMTP:25 host 198.51.100.10 host 198.51.100.11 relay WWWforward table WEB:80 host 198.51.100.20 host 198.51.100.21

Avlblty Status active active (2 hosts up) disabled 100.00% up active active (2 hosts up) 100.00% up 100.00% up

Assim, o host 198.51.100.10 no recebe mais requisies, e todas as conexes sero tratadas apenas pelo 198.51.100.11(Com a realizao do procedimento, o servio no cou indisponvel e este artifcio pode ser utilizado para realizar manutenes nos servidores. Para retornar o servidor ao cluster: root# relayctl host enable 20 Para ver o resultado:

21

root# Id 0 10 20 21 0 11 22 23

relayctl show summary Type Name redirect SMTPSERVER table SMTP:25 host 198.51.100.10 host 198.51.100.11 relay WWWforward table WEB:80 host 198.51.100.20 host 198.51.100.21

Avlblty Status active active (2 hosts up) 100.00% up 100.00% up active active (2 hosts up) 100.00% up 100.00% up

6.1

Vericao do Funcionamento

A vericao do sistema funcionando pode ser vericada a partir da execuo do comando tcpdump, que exibir o trfego passante entre as interfaces de rede. Para o funcionamento do PFSYNC, no fw1, monitorando a interface que o pfsync mapeia, a em2: root# tcpdump -n -e -i em2 -c 5 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em2, link-type EN10MB (Ethernet), capture size 96 bytes 23:34:58.805728 00:11:43:d9:a4:a2 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 582: 203.0.113.0.1 > 224.0.0.240: pfsync 548 23:34:58.806227 00:11:43:d9:a4:a2 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 582: 203.0.113.0.1 > 224.0.0.240: pfsync 548 23:34:58.806406 00:11:43:d9:a4:a2 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 582: 203.0.113.0.1 > 224.0.0.240: pfsync 548 23:34:58.807678 00:11:43:d9:a4:a2 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 318: 203.0.113.0.1 > 224.0.0.240: pfsync 284 23:34:58.807735 00:11:43:d9:a4:a2 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 294: 203.0.113.0.1 > 224.0.0.240: pfsync 260 5 packets captured 247 packets received by filter 0 packets dropped by kernel No fw2: root1# tcpdump -n -e -i em2 -c 5 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em2, link-type EN10MB (Ethernet), capture size 96 bytes 23:49:30.391434 00:11:43:d9:a4:a2 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 582: 203.0.113.0.1 > 224.0.0.240: pfsync 548 23:49:30.391742 00:11:43:d9:a4:a2 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 582: 203.0.113.0.1 > 224.0.0.240: pfsync 548 23:49:30.392055 00:11:43:d9:a4:a2 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 582: 203.0.113.0.1 > 224.0.0.240: pfsync 548 23:49:30.392525 00:11:43:d9:a4:a2 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 582: 203.0.113.0.1 > 224.0.0.240: pfsync 548 23:49:30.393618 00:11:43:d9:a4:a2 > 01:00:5e:00:00:f0, ethertype IPv4 (0x0800), length 582: 203.0.113.0.1 > 224.0.0.240: pfsync 548 5 packets captured 382 packets received by filter 0 packets dropped by kernel

22

Para apresentar o funcionamento do sistema que atende o smtp, o trabalho maior, pois h necessidade de exibir mltiplos pontos de anlise de trfego: tcpdump na interface WAN do LB, para averiguar a requisio vinda de fora da rede: root# tcpdump -n -e -i em0 port 25 and host 192.0.2.100 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes 00:00:53.647346 00:83:08:00:a3:14 > 00:04:23:b1:e7:5c, ethertype IPv4 (0x0800), length 66: 192.0.2.100.49880 > 198.51.100.3.25: S 2226251592:2226251592(0) win 8192 <mss 1360,nop,wscale 2,nop,nop,sackOK> 00:00:53.647396 00:04:23:b1:e7:5c > 00:83:08:00:a3:14, ethertype IPv4 (0x0800), length 58: 198.51.100.3.25 > 192.0.2.100.49880: S 3696464286:3696464286(0) ack 2226251593 win 0 <mss 1360> 00:00:53.656561 00:83:08:00:a3:14 > 00:04:23:b1:e7:5c, ethertype IPv4 (0x0800), length 60: 192.0.2.100.49880 > 198.51.100.3.25: . ack 1 win 17680 00:00:53.656666 00:04:23:b1:e7:5c > 00:83:08:00:a3:14, ethertype IPv4 (0x0800), length 54: 198.51.100.3.25 > 192.0.2.100.49880: . ack 1 win 65535 00:00:53.690642 00:04:23:b1:e7:5c > 00:83:08:00:a3:14, ethertype IPv4 (0x0800), length 92: 198.51.100.3.25 > 192.0.2.100.49880: P 1:39(38) ack 1 win 65535 00:00:53.899986 00:83:08:00:a3:14 > 00:04:23:b1:e7:5c, ethertype IPv4 (0x0800), length 60: 192.0.2.100.49880 > 198.51.100.3.25: . ack 39 win 17642 6 packets captured 58957 packets received by filter 0 packets dropped by kernel tcpdump na interface LAN do LB, para averiguar qual servidor smtp est recebendo o trfego(SMTP1): root# tcpdump -n -e -i em1 port 25 and host 192.0.2.100 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on em1, link-type EN10MB (Ethernet), capture size 96 bytes 00:00:53.656592 00:04:23:b1:e7:5d > 00:22:19:d4:a2:43, ethertype IPv4 (0x0800), length 58: 192.0.2.100.49880 > 198.51.100.10.25: S 3960872231:3960872231(0) win 0 <mss 1360> 00:00:53.656640 00:22:19:d4:a2:43 > 00:04:23:b1:e7:5d, ethertype IPv4 (0x0800), length 60: 198.51.100.10.25 > 192.0.2.100.49880: S 3748023373:3748023373(0) ack 3960872232 win 65535 <mss 1360> 00:00:53.656658 00:04:23:b1:e7:5d > 00:22:19:d4:a2:43, ethertype IPv4 (0x0800), length 54: 192.0.2.100.49880 > 198.51.100.10.25: . ack 1 win 17680 00:00:53.690626 00:22:19:d4:a2:43 > 00:04:23:b1:e7:5d, ethertype IPv4 (0x0800), length 92: 198.51.100.10.25 > 192.0.2.100.49880: P 1:39(38) ack 1 win 65535 00:00:53.900009 00:04:23:b1:e7:5d > 00:22:19:d4:a2:43, ethertype IPv4 (0x0800), length 54: 192.0.2.100.49880 > 198.51.100.10.25: . ack 39 win 17642 5 packets captured 152990 packets received by filter 0 packets dropped by kernel tcpdump na interface do servidor smtp est recebendo o trfego(SMTP1): root# tcpdump -n -e -i xl0 port 25 and host 192.0.2.100 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes 00:00:53.656592 00:22:19:d4:a2:43 > 00:04:23:b1:e7:5d, ethertype IPv4 (0x0800), length 58: 192.0.2.100.49880 > 198.51.100.10.25: S

23

3960872231:3960872231(0) win 0 <mss 1360> 00:00:53.656640 00:04:23:b1:e7:5d > 00:22:19:d4:a2:43, ethertype IPv4 (0x0800), length 60: 198.51.100.10.25 > 192.0.2.100.49880: S 3748023373:3748023373(0) ack 3960872232 win 65535 <mss 1360> 00:00:53.656658 00:22:19:d4:a2:43 > 00:04:23:b1:e7:5d, ethertype IPv4 (0x0800), length 54: 192.0.2.100.49880 > 198.51.100.10.25: . ack 1 win 17680 00:00:53.690626 00:04:23:b1:e7:5d > 00:22:19:d4:a2:43, ethertype IPv4 (0x0800), length 92: 198.51.100.10.25 > 192.0.2.100.49880: P 1:39(38) ack 1 win 65535 00:00:53.900009 00:22:19:d4:a2:43 > 00:04:23:b1:e7:5d, ethertype IPv4 (0x0800), length 54: 192.0.2.100.49880 > 198.51.100.10.25: . ack 39 win 17642 5 packets captured 152990 packets received by filter 0 packets dropped by kernel Resultados semelhantes podemos obter para o servidor SMTP2, pois como o trfego balanceado, basta repetir o procedimento que quem ir responder s requisies ser o SMTP2. Para apresentao do funcionamento do sistema em relao ao relay(proxy), no se faz necessrio o monitoramento das interfaces, uma vez que a conexo realizada do cliente ao LB e do LB ao servidor. Sendo assim, o teste pode ser feito criando um arquivo de ndice em cada servidor web e acessado pelo cliente remoto atravs do comando telnet, da seguinte maneira: cliente# telnet 198.51.100.4 80 Trying 198.51.100.4... Connected to 198.51.100.4. Escape character is ^]. GET / HTTP1.1 HTTP/1.1 200 OK Date: Wed, 20 Mar 2010 15:49:19 GMT Server: Apache/2.0.63 (FreeBSD) Last-Modified: Wed, 20 Mar 2010 14:30:49 GMT ETag: "1e3403-31-484296ae8a640" Accept-Ranges: bytes Content-Length: 49 Connection: close Content-Type: text/plain OI, SOU O SERVIDOR WEB1. Meu IP 198.51.100.20 Connection closed by foreign host.

Pode ser vericado que o servidor que atendeu requisio foi o WEB1. Repetindo o procedimento, a conexo ser respondida pelo WEB2(o IP do cliente remoto deve ser alterado, pois na poltica de balanceamento o IP de origem faz parte do processo. Se no for alterado, a o servidor que atendeu a primeira requisio que ir continuar a responder. O IP foi mudado para 192.0.2.101) cliente# telnet 198.51.100.4 80 Trying 198.51.100.4... Connected to 198.51.100.4. Escape character is ^]. GET / HTTP1.1

24

HTTP/1.1 200 OK Date: Wed, 20 Mar 2010 15:51:19 GMT Server: Apache/2.0.63 (FreeBSD) Last-Modified: Wed, 20 Mar 2010 14:35:49 GMT ETag: "1e3403-31-4842979830d80" Accept-Ranges: bytes Content-Length: 49 Connection: close Content-Type: text/plain OI, SOU O SERVIDOR WEB2. Meu IP 198.51.100.21 Connection closed by foreign host. Com isso, os testes realizados comprovam o funcionamento proposto para o sistema.

Prs e Contras
O modelo de sistema apresentado neste trabalho possui como pontos fortes: A robustez(proporcionada pelo FreeBSD) Baixo custo de implantao(utiliza hardware que pode ser adquirido com facilidade no mercado e softwares open-source) Sem limitaes de tratamento de dados, que restrita capacidade do hardware(no h necessidade de licenciamento de acordo com a demanda de processamento/utilizao) Pode ser customizado de acordo com as necessidades(pois o cdigo-fonte aberto), alm de permitir a agregao de novos servios(que podem ser instalados nos equipamentos) e a integrao com outras ferramentas e sistemas Como pontos fracos: A necessidade de conhecimento avanado em sistemas UNIX(FreeBSD) Tempo de implementao maior do que se adquirido um sistema pronto(appliances e softwares) Inexistncia de um "fornecedor/fabricante"que realize suporte e atendimento

Concluso

O presente trabalho reuniu um conjunto de ferramentas e as integrou com suscesso em uma soluo, que permite criar e manter sistemas em alta disponibilidade e que possam ser implementados com certa facilidade, atingindo os objetivos mensionados na seo 1 Uma procura crescente por solues como esta est se tornando mais comum no mercado, pois o crescimento de sites de e-commerce, de relacionamento, da quantidade de domiclios e pessoas que acessam servios na Internet, dentre outros, exige que os sistemas que promovam a conectividade no pare, no que indisponvel e no apresente perda de desempenho. Esta soluo(ou boa parte dela) est em uso pelo Provedor Onda, fornecendo redundncia/alta disponibilidade para sistemas de e-mail, de portais de e-commerce, sistemas ERP e bancos de dados que trabalham em regime de misso-crtica. Como continuidade da atividade desenvolvida, pode-se melhorar a contruo do sistemas, utilizando, alm de rewall/balanceador de carga, links redundantes independentes, switches redundantes e outras alternativas/equipamentos que permitam tornar a soluo ainda mais robusta.

25

Referncias
[1] Jacek Artymiak. Building Firewalls with OpenBSD and PF. Jacek Artymiak, segunda edition, Novembro 2003. [2] Denis Augusto de Souza. FreeBSD - O Poder dos Servidores em suas Mos. Novatec, Julho 2009. [3] Theo Deraadt. Openbsd website, acessado em 20 de Maro 2010. http://www.openbsd.org. [4] Marshall Kirk McKusick e George V. Neville-Neil. The Design and Implementation of the FreeBSD Operating System. Addison-Wesley Professional, Agosto 2004. [5] Jari Arkko; Michelle Cotton e Leo Vegoda. Rfc5737 - ipv4 address blocks reserved for documentation, acessado em 20 de Maro de 2010. http://tools.ietf.org/html/rfc5737. [6] Reyk Floeter. Relayd, acessado em 20 de Maro de 2010. http://spootnik.org/relayd/. [7] The FreeBSD Foundation. http://www.freebsd.org. The freebsd project, acessado em 20 de Maro de 2010.

[8] Peter N.M. Hansteen. The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall. No Starch Press, Janeiro 2008. [9] William Hoskins. The 4.4bsd copyright, acessado em 20 de Maro de 2010. http://www.freebsd.org/copyright/license.html. [10] Greg Lehey. The Complete FreeBSD. OReilly Media, quarta edition, Abril 2003. [11] The FreeBSD Documentation Project. Freebsd handbook, acessado em 20 de Maro de 2010. http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/index.html. [12] Enrique Vargas. High availability fundamentals. http://www.sun.com/blueprints/1100/HAFund.pdf. Sun BluePrints, Maro Maro de de 2000. 2010. 2010.

[13] Wikipedia. Load balancing, acessado em 20 de http://en.wikipedia.org/wiki/Load_balancing_(computing). [14] Wikipedia. The wikipedia, acessado http://pt.wikipedia.org/wiki/Firewall. em 20 de

26