carp pfsync

8/4/2019 Carp Pfsync

1/26

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 atravsda internet/redes privadas e que significa que est disponvel para acesso. Alta disponibilidade estrelacionada 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 emse tratando de operadores de Internet/conectividade, instituies financeiras, sistemas de comrcioeletronico, dentre outros.

1 Introduo

O objetivo deste trabalho apresentar um sistema de firewalls operando em redundncia/altadisponibilidada 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 apresen-tao sobre disponibilidade e seus fundamentos. Na seo 3, aspectos sobre firewalls. Na sesso4, sobre balanceamento de carga. Na seo 5, a estrutura de base para o trabalho, o FreeBSD e odesenvolvimento/configurao do projeto. Na seo 6, aspectos relacionados ao funcionamento dosistema e administrao bsica dos softwares. Finalmente na seo 7, os prs e contras da estruturaapresentada e por fim, 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 pessoaque 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 inmerostranstornos, sendo os maiores deles, depreciao da imagem e prejuzo financeiro.

Neste contexto, os sistemas computacionais podem ser agrupados em quatro categorias[12], deacordo com a aplicao pretendida:

Computao de Propsito Geral, formado pela maior parte dos sistemas, que inclui aplicativosde usurio/profissional, so sistemas que podem parar, sem muito comprometer o curso normaldas atividades(comumente resolvido com um restart do sistema)

Sistemas de Alta Disponibilidade, formado por um conjunto de servios que podem ser aces-sados qualquer momento, e disponibilidade a mtrica para tais sistemas, atribuindo umnvel de tolerncia para indisponibilidades. Esto inclusos neste tem: sistemas bancrios e de

telecomunicaes.

1


2/26

Sistemas de Misso Crtica, formado pelos sistemas que possuem completa tolerncia falhase no podem parar em hiptese alguma, como sistemas de tempo-real, sistemas de controle detrfego areo, militares e de usinas nucleares

Sistema de Longa Vida, formado por sistemas com alta confiabilidade e que, normalmente, sode manuteno extremamente cara e complexa, como sistemas de satlite e naves espaciais.

Para no estar suscetvel a problemas de disponibilidade, empresas criam projetos, realizamtreinamentos e, acima de tudo, realizam investimentos para chegar ao objetivo, estar acessvel efuncional. tens como este e outros sero abordados neste trabalho, que expe um modelo desistema de firewalls, atuando de forma redundante(Sistema de Alta Disponibilidade), servindo debase para uma estrutura de provimento de servios redundantes e tolerante falhas.

2 Disponibilidade, Confiabilidade e MTBF

A definio de confiabilidade[12] a probabilidade de operao de um sistema, em um determi-nado perodo, sem apresentar falhas. apenas um dos muitos fatores que influenciam a disponibi-

lidade e mede a capacidade de um sistema funcionar sem interrupes durante o fornecimento deum servio/aplicao.O MTBF (mean time between failures) uma mtrica relacionada confiabilidade, 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), MTBFde sistema(tempo mdio entre falhas de sistema, que podem ser minimizadas com a utilizao dehardware redundante), e MTBI(mean time between interruptions, que so falhas temporrias desistema sem a realizao de reparos).

O MTBF no indica exatamente quando a falha ir ocorrer(pois um valor baseado em anliseestatstica), porm em importante ser acompanhado, pois quanto mais tempo em atividade, maiora chance de apresentar problema.

2.1 Disponibilidade

A disponibilidade, em se tratando de sistemas computacionais, um fator muito desejado, tantopara provedores de servios quanto para clientes. A empresa que prov qualquer tipo de servioprecisa oferecer mtricas e referncias a respeito do que ela faz para manter o servio disponvel. Asmtricas so clculos que levam em conta um grande nmero de variveis, mas que ao fim, resultaem um nmero em formato %(percentual). Este nmero explicita o quanto aquele servio esteveestvel no ltimo perodo de aferio.

Uma prtica comum utilizar ferramentas/metodologias de gerenciamento para monitorar taisindicadores, 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 incidnciade erros, e apresenta o % de disponibilidade do sistema. No controle de tudo est o gerenciamentode 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 tempoaproximado de disponibilidade e representa a porcentagem de tempo que um sistema computacionalest 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)

2


3/26

O % de disponibilidade calculado da seguinte maneira:

Disponibilidade =MTBF

M T B F + M T T R(2)

Onde MTBF Mean Time Between Failures e MTTR Mean Time to Repair

A tabela 1 apresenta os valores de disponibilidade em relao ao perodo de downtime:

Tabela 1: Disponibilidade e Downtime

Disponibilidade e Downtime

99% 3,65 dias99,9% 8,76 horas99,99% 52,6 minutos99,999% 5,26 minutos99,9999% 31,53 segundos

99,99999% 3,15 segundos

2.3 Confiabilidade e Disponibilidade

Existe diferenas entre confiabilidade e disponibilidade. Dependendo da situao, maiores bene-fcios podem ser obtidos com confiabilidade ao invs da disponibilidade e vice-versa. Casos em queconfiabilidade mais importante ocorre quando os sistemas esto localizados em reas remotas ecom manuteno cara. Embora disponibilidade seja funo da confiabilidade e manutenabilidade, possivel sistemas de baixa confiabilidade trabalhar em alta disponibilidade, fazendo uso de artifcios

como redundncia de equipamentos(quantidade de equipamentos)(N + 1, N + 2, N + N) e redun-dncia de hardware dentro do equipamento(HDs em raid, fonte redundante, multiplas interfaces derede, etc). A confiabilidade mede a habilidade de um sistema operar continuamente sem interrup-es. Um sistema computacional com alto MTBF indica que, em mdia, o sistema opera por longosperodos sem nenhuma interruo por falha de equipamento. Por outro lado, a disponibilidade medea habilidade de um sistema suportar um determinado nvel de servio. Uma maneira aproximada(90% de preciso) de converso de confiabilidade para disponibilidade[12] a seguinte:

Disponibilidade =t (1 R(t))dt

t(3)

onde: R(t) a confiabilidade de um sistema no perodo de tempo t, e

dt o tempo de indisponibilidade(em horas).

A confiabilidade, R(t), de um sistema representa a probabilidade de um sistema no apresentarfalhas em um perodo de tempo t. O valor de 1 - R(t) representa a probabilidade de um sistemaapresentar falhas em um perodo de tempo t. Multiplicando 1 - R(t) por dt , aproxima-se o totalde tempo indisponvel no mesmo perodo. O valor de t - ( 1 - R(t))dt apresenta o tempo totalque 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 duranteum perodo t. Se a manutenabilidade for de 0,95 para trs horas, significa que a probabilidade deo servio ser concludo em 3 horas de 95%. Uma alta confiabilidade reduz a frequncia de falhas

3


4/26

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

3 FirewallFirewall[14], nascido na dcada de 1980, um dispositivo participante de uma rede de compu-

tadores com objetivo de seletivamente, permitir ou negar a passagem de dados atravs dele, de umponto outro da rede, de acordo com polticas/padres adotados. Abrange os equipamentos defiltros 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 fluxo de entrada e sada deinformaes e do grau de segurana desejado.

Nos primrdios, o firewall era um filtro 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 checavao 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 firewall de estado, que armazena o estado das conexes e filtra combase nesse estado(estados: novas conexes, estabelecidas, relacionadas a outras existentes; FirewallStatefull), 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 firewall de estados gateway de aplicao/balanceadorde carga, tambm conhecido como firewall de aplicao ou firewall proxy, que compreende umsistema capaz de receber uma conexo, decodificar protocolos na camada de aplicao e interceptara comunicao entre cliente/servidor para aplicar regras de acesso e posterior permisso/seleo doservidor de destino. Entre as funcionabilidades, inclui:

Todas as regras do firewall 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 firewalls de ltima gerao prov soluo comercial para redes de comunicao TCP/IP.Realiza SPI(Stateful Packet Inspection), inspecionando pacotes e trfego de dados baseado nascaractersticas de cada aplicao, nas informaes associadas a todas as camadas do modelo OSI (eno apenas na camada de rede ou de aplicao) e no estado das conexes e sesses ativas, realizapreveno de intruso para fins de identificar o abuso do protocolo TCP/IP mesmo em conexesaparentemente legtimas, e DPI (Deep Packet Inspection), associando as funcionalidades do SPIcom as tcnicas dos dispositivos IPS(Intrusion Prevention System).

4


5/26

4 Balanceamento de Carga

O balanceamento de carga(LB)[13] promove a distribuio de fluxo de acesso para dois ou maisservidores, links, processadores, ou outros tipos de recursos. A utilizao do sistema de LB melhoraa confiabilidade e redundncia, j que uma de suas principais funes compor clusters/farmsde 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 serviosde 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, queatua nas camadas 3 ou 7 do modelo ISO/OSI, capaz de encaminhar e dinamicamente redirecionarconexes que esto chegando em um host. Atua como balanceador de carga, gateway de aplicaoou proxy transparente. capaz de monitorar a disponibilidade de um grupo de hosts e de serviosespecficos comuns ao grupo. Quando opera realizando redirecionamento em camada 3, ele trabalha

em conjunto com o PF, interagindo dinamicamente com as regras/tabelas de firewall. Na modalidadede relay, opera em camada 7, de maneira individual(no necessita do PF), permitindo a filtragemno nvel de aplicao e de protocolos especficos.

5 Estrutura

Dentre os fatores importantes para a elaborao deste trabalho, alta disponibilidade, baixo in-vestimento e ROI(return on investimet) so os principais. Optou-se por uma estrutura de servidoresde plataforma CISC(Complex Instruction Set Computer) AMD64/x86_64(estrutura de 64 bits pro-posta 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 re-dundante(que justamente so os componentes que mais apresentam falhas), com garantia de 36meses e tempo de resoluo(contrato firmado com o fornecedor, que estabelece um prazo para aresoluo da falha de hardware) de 24 horas e configurado para operao em rack de 1U(1 unidadede rack). Caractersticas de processador, memria e capacidade de disco foram optados por, res-pectivamente, 1 processador de quatro ncleos e 2GHz, 2GB de memria RAM e disco SAS de 10KRPM e 73GB de espao. Na parte de rede, foram escolhidas 3 interfaces Intel gigabit(2 integradasno servidor e 1 placa pci com 1 interface), devido ao desempenho melhorado por caractersticasde 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 BSDadotam como identificao para elas, o nome do mdulo de firewall que implementa a comunicao

com o dispositivo de hardware).

5


6/26

5.1 FreeBSD

Na sequncia do trabalho, o sistema operacional escolhido para gerenciar toda a estrutura oFreeBSD [7], que um Sistema Operacional BSD UNIX avanado, com principal objetivo ser muitoeficiente[4]. Com mais de trinta anos de contnuo desenvolvimento, melhorias e otimizaes, provum 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 sis-tema muito eficiente de gerenciamento de processos, alocao de memria, utilizao de cpu, umadas melhores pilhas TCP/IP[10], dentre outras inmeras qualidades. Amplamente utilizado paraprover servios de DNS, e-mail, ftp, www, firewalls e roteamento. Serve como base de desenvolvi-mento para fabricantes como Apple, Cisco, Juniper, NetApp, e outras grandes, e utilizado porinmeras 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 depublicar 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 firewall,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), eOpenBSD PacketFilter[3](tambm conhecido como PF). O FreeBSD tambm possui 2 sistemasde controle de trfego, ALTQ(Alternate Queuing) e dummynet. Dummynet trabalha de maneiraincorporada ao IPFW, assim como ALTQ com PF. Tambm possvel a utilizao mesclada dasestruturas de firewall e controle de trfego[11], no abordada neste trabalho.

A razo para o FreeBSD operar com mltiplos sistemas de firewall permitir que cada pessoa

trabalhe de acordo com a preferncia e de acordo com as necessidades. Alguns preferem, por exemploo IPFILTER para tratar regras de NAT e FTP, devido facilidade de criao das regras. Para otrabalho em questo, o firewall adotado o PF. O PF foi portado do OpenBSD para o FreeBSD em2003 e em 2004, foi lanada a verso 5.3 do FreeBSD com PF j integrado ao sistema, utilizandoALTQ para prover QoS(qualidade de servio). Junto com o PF, outros dois sistemas trabalham emconjunto: o PFLOG[1] e o PFSYNC[8].

O pflog o responsvel pelo tratamento/arquivamento dos logs gerados pelo PF. J o pfsync fazum trabalho mais elaborado. Ele cria uma interface de rede pfsync, responsvel por monitorar todasas alteraes processadas na tabela de estados do PF(o trfego de pfsync encaminhado atravs dainterface real ao qual ele est mapeado, enviando os dados ao endereo multicast 224.0.0.240. Comos existem dois firewall, o master envia ao backup. Se existissem mais que dois firewalls ligados com

pfsync, todos os backups receberiam as tabelas de conexo do firewall via multicast). Desta maneira,todas as conexes ativas em um firewall podem ser sincronizadas com outro firewall e permitir que,se um firewall 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 umsistema de alta disponibilidade incorporada por ele, a partir da verso 5.4, o CARP(CommonAddress Redundancy Protocol). O carp[3] um protocolo multicast que permite mltiplos hostscompartilhar um ou mais endereos IP, sendo um destes hosts o master que responde por todos ospacotes 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:

6


7/26

net.inet.carp.allow=1net.inet.carp.preempt=1 #faz com que se 1 interface carp cair, todas as outras

#passam para backup e o outro firewall assume.net.inet.carp.log=1 #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 sistemasfuncionem 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), instaladoscom o FreeBSD. Detalhes de como instalar, atualizar, recompilar o kernel, realizar otimizaes edemais 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 figura 1 ilustra o mo-delo da estrutura pretendida.

Figura 1: Estrutura em Alta Disponibilidade

7


8/26

Tomados os 2 servidores j instalados, com o ports[11] instalado e o sistema operacioanl atualiza-dos, para ativar as funcionalidades pretendidos necessrio recompilar o kernel(ncleo) do FreeBSD,com a incluso dos seguintes mdulos/opes:

device pf #(habilita o PF)device pflog #(habilita a gerao de logs no PF)

device pfsync #(habilita o sincronismo entre 2 sistemas PF)device vlan #(habilita o suporte vlan, no utilizado)device carp #(habilita o suporte a CARP)options ALTQ #(habilita o suporte ao altq)options ALTQ CBQ #(habilita o suporte ao controle de fila CBQ -

#Class Based Queuing )options ALTQ RED #(habilita o suporte ao controle de congestionamento RED -

#Random Early Detection )options ALTQ RIO #(habilita o suporte ao controle de congestionamento RIO -

#Random Early Detection In and Out)options ALTQ HFSC #(habilita o suporte ao controle de fila hierrquica HFSC -

#Hierarchical Fair Service Curve Packet Scheduler)options ALTQ PRIQ #(habilita o suporte ao controle de fila PRIQ -#Priority Queuing )

options ALTQ NOPCC #(habilita o suporte sistemas SMP - multiprocessados)options DEVICE POLLING #(habilita o tratamento de dispositivos atravs de POLLING)options 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 (entrar no diretrio do software que se

deseja instalar)root# make install clean (baixa o cdigo fonte do software da

internet, compila, instala e limpa oque restou do processo de compilao)

O passo seguinte habilitar a inicializao/execuo dos servios. No arquivo /etc/rc.conf, deveser adicionado:

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

A configurao 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 demodo a garantir o funcionamento do sistema. A estrutura de firewalls compreende dispor de doisservidores 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:

8


9/26

Tabela 2: Endereamento de Rede

Endereamento de Rede

Equipamento Interface IP/Netmask

Gateway default - 192.0.2.254/24

FW1 em0(WAN) 192.0.2.1/24FW1 em1(LAN) 198.51.100.1/24FW1 carp0 192.0.2.3/24FW1 carp1 198.51.100.3/24FW1 carp2 198.51.100.4/24FW1 em3(pfsync) 203.0.113.1/30

FW2 em0(WAN) 192.0.2.2/24FW2 em1(LAN) 198.51.100.2/24FW2 carp0 192.0.2.3/24FW2 carp1 198.51.100.3/24

FW2 carp2 198.51.100.4/24FW2 em3(pfsync) 203.0.113.2/30

SMTP1 X 198.51.100.10/24SMTP2 Y 198.51.100.11/24

WEB1 Z 198.51.100.20/24WEB2 W 198.51.100.21/24

Cliente Remoto K 192.0.2.100/24teste WEB1

Cliente Remoto K 192.0.2.101/24

teste WEB2

Para configurar o sistema de rede no fw1, deve ser adicionado ao arquivo /etc/rc.conf o seguintecontedo:

defaultrouter="192.0.2.254" #rota/gateway defaulthostname="fw1.teste.com.br"

#hostname associado ao firewall/LB 1, no domnio teste.com.brifconfig_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"

9


10/26

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 configurada a rede, o prximo passo configurar o relayd, a princpio para realizar balan-ceamento de carga para dois servios escolhidos, SMTP(Simple Mail Tranfer Protocol - envio dee-mails) e HTTP. Para SMTP, a configurao focada no princpio de redirect, presente no relayd.Para o HTTP, relay.

O funcionamento do redirect bem simples, fazendo uso de uma regra de firewall(PF) rdr-to e redirecionando(com persistncia de estados) aos hosts ativos nas tabelas especficas. O fi-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, redirecioandoo servio pretendido ao host do cluster/farm que dever receber a conexo no momento. O hostprocessa a requisio e a retorna ao LB, que responder ao cliente que solicitou a requisio. Afigura 2 ilustra como ocorre a comunicao.

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) deIP_3.

2 - Ao chegar ao LB, este manipula os pacotes e altera o endereo de destino, de IP_3 paraIP_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 paraIP_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 umsocket que escutar e aceitar conexes entrantes, em um IP e portas definidos na configurao.Qualquer conexo realizada no IP/porta ser tratado como se o LB fosse o servidor, ele far o

10


11/26

proxy das conexes(ao mesmo tempo que realizar uma conexo com o host que dever receber arequisio) e ele passar a intermediar a relao cliente/servidor, operando em camada 7(tambmchamado de gateway de aplicao ou proxy de camada 7). O propsito da funo relay prover umbalanceamento de carga avanado, baseado em caractersticas especficas de protocolos, tais comocabealhos HTTP, acelerao SSL ou manipular outros protocolos em nvel de aplicao. A figura3 ilustra como ocorre a comunicao.

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) deIP_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 clientede IP_1.

2 - partir LB(que mantm a conexo do cliente e faz proxy da conexo), este realiza umaconexo de sada com o servidor que dever responder solicitao(IP_4 ou IP_5, de acordocom a poltica de balanceamento) e encaminha os dados do cliente remoto ao servidor, operandoem camada 7. Quando o servidor responder(responder ao IP_3) ao LB, este encaminhar osdados ao cliente remoto de IP_1.

Para configurar o relayd, deve ser criado/editado o arquivo /usr/local/etc/relayd.conf com asseguintes opes:

################################################################################### GLOBAL#################################################################################interval 5 #tempo entre checagem dos hosts, em segundos

timeout 1000 #tempo que aguarda a resposta da checagem, em milisegundosprefork 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 SMTP2WEB1= "198.51.100.20" #IP do servidor WEB1WEB2= "198.51.100.21" #IP do servidor WEB2

11


12/26

#################################################################################

################################################################################### 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 { $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 { $SMTP1, $SMTP1, $SMTP2 },o SMTP1#receberia em torno de 66% e o SMTP2, 34% das#conexes.

table { $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 port 25 mode roundrobin check tcp#onde forward to port 25 significa que as#conexes recebidas sero encaminhadas aos#participantes da tabela na porta 25,#mode roundrobin significa que as conexes#encaminhadas tabela 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


13/26

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" #define a funo relay, com label WWWforward{

listen on $web port 80 #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 relayforward to port 80 mode loadbalance timeout 600 check tcp

#onde forward to port 80 significa que#as conexes recebidas sero encaminhadas aos#participantes da tabela na porta 80,#mode loadbalance significa que as conexes

#encaminhadas tabela 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 configurao 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, deveser editado/criado o arquivo /etc/pf.conf com as seguintes entradas(a configurao a mesma paraos 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


14/26

scrub in all fragment reassemble no-dfscrub 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 em0lan= "em1" #macro que atribui LAN como em1syncpf= "em2" #macro que atribui PFSYNC/syncpf como em2

#################################################################################

## REDES#################################################################################table { 192.0.2.0/24 }

#tabela que define uma rede administrativatable { 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 firewalltable { 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.10smtp2="{ 198.51.100.11 }" #macro que atribui smtp2 como 198.51.100.11web1= "{ 198.51.100.20 }" #macro que atribui web1 como 198.51.100.20web2= "{ 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 smtp2web= "{ $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.3carp_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


15/26

################################################################################### 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 qlimit 300 priority 5 hfsc\( realtime 250Mb red upperlimit 500Mb red )

queue ssh bandwidth 100Mb qlimit 300 priority 7 hfsc\( realtime 100Mb red upperlimit 600Mb red )

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

#################################################################################

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

15


16/26

## Relaydrdr-anchor "relayd/*" #Ativa o redirecionamento, utilizado pelo relayd

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

#################################################################################### REGRAS#################################################################################

## ADMIN#################################################################################pass in quick on $wan inet proto 1 from 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 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 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 statepass quick on { $wan $lan carp0 carp1 carp2 } proto carp modulate state queue sshpass quick on { $wan $lan carp0 carp1 carp2 } proto IGMP modulate state queue sshpass 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


17/26

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 to any label "INVLIDOS"antispoof quick for lo0pass 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 webpass 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


18/26

6 Funcionamento

O funcionamento do sistema complexo, porm simples de ser gerido e mantido. Como men-sionado anteriormente, o FreeBSD apresenta farta documentao e de acesso facilitado atravs dosite: http://www.freebsd.org.

A operao bsica do sistema consiste em parar e iniciar servios e ajustes de configurao. Para

manipular os servios de rede no FreeBSD, deve ser considerados dois pontos distintos: programas eservios que so nativos do SO e programas e servios instalados de terceiros. Todos os servios quej vm com o FreeBSD podem ser controlados a partir de /etc/rc.d/Nome_Do_Servico start|stop. . . , para servios como o pf, pfsync, pflog, syslog, dentre outros. J os instalados(contrudos) porterceiros, estaro em outra localizao, em /usr/local/erc/rc.d/Nome_Do_Servico start|stop. . . ,para softwares como relayd, net-snmp, postfix, e outros.

De incio, os dois LB podem ser ligados em qualquer ordem, apenas respeitando a configuraodas interfaces de rede(a terceira interface/em2 ligada entre os dois LB via cabo crossover). Apsligados, os dois LB devero possuir a seguinte sada(se ligado em portas gigabit de switch) paraa execuo do comando ifconfig (exceto para as interfaces CARP, que em um dos LB ter statusMASTER e no outro BACKUP):

em0: flags=8943 metric 0 mtu 1500options=1dbether 00:04:23:b1:e7:5cinet 192.0.2.1 netmask 0xffffff00 media: Ethernet autoselect (1000baseTX )status: active

em1: flags=8943 metric 0 mtu 1500options=1dbether 00:04:23:b1:e7:5dinet 198.51.100.1 netmask 0xffffff00 media: Ethernet autoselect (1000baseTX )

status: activeem2: flags=8943 metric 0 mtu 1500

options=1dbether 00:11:43:d9:a4:a2inet 203.0.113.0.1 netmask 0xfffffffc media: Ethernet autoselect (1000baseTX )status: active

lo0: flags=8049 metric 0 mtu 16384inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4inet6 ::1 prefixlen 128inet 127.0.0.1 netmask 0xff000000

pfsync0: flags=41 metric 0 mtu 1460pfsync: syncdev: em2 syncpeer: 224.0.0.240 maxupd: 128

carp0: flags=49 metric 0 mtu 1500inet 192.0.2.3 netmask 0xffffff00carp: MASTER vhid 100 advbase 1 advskew 10



No FW2, a sada do comando(para as interfaces CARP) ser:

18


19/26

carp0: flags=49 metric 0 mtu 1500inet 192.0.2.3 netmask 0xffffff00carp: BACKUP vhid 100 advbase 1 advskew 100



Assim, o FW1 responde pelo acesso entre as redes WAN e LAN, se caso alguma interface fa-lhar(houver queda de link/camada 1 e 2), o FW2 assume em no mximo 2 segundos. Vale apenaressartar, que o processo de queda do FW1 e assumir do FW2 no interrompe/fecha conexes aber-tas, 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 statusStatus: Enabled for 269 days 09:23:31 Debug: Urgent

Interface Stats for bge0 IPv4 IPv6Bytes In 12565507959096 166063Bytes Out 25381148856613 0Packets In

Passed 23262007918 413Blocked 390198167 1624

Packets OutPassed 75395100311 0Blocked 176675512 0

State Table Total Ratecurrent entries 5634searches 238741295155 10257.2/sinserts 4352087757 187.0/sremovals 4352098551 187.0/s

Counters match 4357434853 187.2/sbad-offset 0 0.0/sfragment 373 0.0/sshort 6 0.0/snormalize 11427 0.0/s

memory 0 0.0/sbad-timestamp 0 0.0/scongestion 0 0.0/sip-option 1558 0.0/sproto-cksum 126979 0.0/sstate-mismatch 3725936 0.2/sstate-insert 0 0.0/sstate-limit 0 0.0/ssrc-limit 0 0.0/ssynproxy 534631541 23.0/s

Caso seja necessria a inverso entre master e backup(realizar alguma manuteno ou por outromotivo qualquer), basta alterar a prioridade advskew do LB, atravs do comando ifconfig, de acordocom as seguintes etapas:

19


20/26

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:




e para o LB2:




2. alterar o advskew de modo que o valor para o LB2 seja menor que o LB1(alterando somenteem LB1)

root# ifconfig carp0 advskew 200 && ifconfig carp1 advskew 200 &&\ifconfig carp2 advskew 200

3. conferir os resultados:

em LB1:

carp0: flags=49 metric 0 mtu 1500inet 192.0.2.3 netmask 0xffffff00

carp: BACKUP vhid 100 advbase 1 advskew 200carp1: flags=49 metric 0 mtu 1500

inet 198.51.100.3 netmask 0xffffff00carp: BACKUP vhid 101 advbase 1 advskew 200


e para o LB2:


20


21/26



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 falhade um deles, no gere indisponibilidade completa do sistema, alis, ele manter o servidor queapresentou 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# relayctl show summaryId Type Name Avlblty Status0 redirect SMTPSERVER active10 table SMTP:25 active (2 hosts up)20 host 198.51.100.10 100.00% up21 host 198.51.100.11 100.00% up0 relay WWWforward active11 table WEB:80 active (2 hosts up)22 host 198.51.100.20 100.00% up23 host 198.51.100.21 100.00% up

A funo de habilitar/desabilitar algum host que faa parte de um cluster, por exemplo, removero 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# relayctl show summaryId Type Name Avlblty Status0 redirect SMTPSERVER active10 table SMTP:25 active (2 hosts up)20 host 198.51.100.10 disabled21 host 198.51.100.11 100.00% up0 relay WWWforward active11 table WEB:80 active (2 hosts up)22 host 198.51.100.20 100.00% up23 host 198.51.100.21 100.00% up

Assim, o host 198.51.100.10 no recebe mais requisies, e todas as conexes sero tratadasapenas pelo 198.51.100.11(Com a realizao do procedimento, o servio no ficou indisponvel e esteartifcio pode ser utilizado para realizar manutenes nos servidores.

Para retornar o servidor ao cluster:

root# relayctl host enable 20

Para ver o resultado:

21


22/26

root# relayctl show summaryId Type Name Avlblty Status0 redirect SMTPSERVER active10 table SMTP:25 active (2 hosts up)20 host 198.51.100.10 100.00% up21 host 198.51.100.11 100.00% up

0 relay WWWforward active11 table WEB:80 active (2 hosts up)22 host 198.51.100.20 100.00% up23 host 198.51.100.21 100.00% up

6.1 Verificao do Funcionamento

A verificao do sistema funcionando pode ser verificada a partir da execuo do comandotcpdump, que exibir o trfego passante entre as interfaces de rede.

Para o funcionamento do PFSYNC, no fw1, monitorando a interface que o pfsync mapeia, aem2:

root# tcpdump -n -e -i em2 -c 5tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on em2, link-type EN10MB (Ethernet), capture size 96 bytes23: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 54823:34:58.806227 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 28423: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 captured247 packets received by filter0 packets dropped by kernel

No fw2:

root1# tcpdump -n -e -i em2 -c 5tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening 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





5 packets captured

382 packets received by filter0 packets dropped by kernel

22


23/26

Para apresentar o funcionamento do sistema que atende o smtp, o trabalho maior, pois hnecessidade 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.100tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on em0, link-type EN10MB (Ethernet), capture size 96 bytes00: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: S2226251592:2226251592(0) win 8192

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 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 1768000: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


tcpdump na interface LAN do LB, para averiguar qual servidor smtp est recebendo o tr-fego(SMTP1):

root# tcpdump -n -e -i em1 port 25 and host 192.0.2.100tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on em1, link-type EN10MB (Ethernet), capture size 96 bytes00: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: S3960872231:3960872231(0) win 0

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 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 1768000: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 6553500: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 176425 packets captured152990 packets received by filter0 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.100tcpdump: verbose output suppressed, use -v or -vv for full protocol decodelistening on xl0, link-type EN10MB (Ethernet), capture size 96 bytes00: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


24/26

3960872231:3960872231(0) win 0 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: S3748023373:3748023373(0) ack 3960872232 win 65535

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


Resultados semelhantes podemos obter para o servidor SMTP2, pois como o trfego balan-ceado, 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 necessrioo monitoramento das interfaces, uma vez que a conexo realizada do cliente ao LB e do LB aoservidor. Sendo assim, o teste pode ser feito criando um arquivo de ndice em cada servidor web eacessado pelo cliente remoto atravs do comando telnet, da seguinte maneira:

cliente# telnet 198.51.100.4 80Trying 198.51.100.4...Connected to 198.51.100.4.Escape character is ^].GET / HTTP1.1

HTTP/1.1 200 OKDate: Wed, 20 Mar 2010 15:49:19 GMTServer: Apache/2.0.63 (FreeBSD)Last-Modified: Wed, 20 Mar 2010 14:30:49 GMTETag: "1e3403-31-484296ae8a640"Accept-Ranges: bytesContent-Length: 49Connection: closeContent-Type: text/plain

OI, SOU O SERVIDOR WEB1. Meu IP 198.51.100.20

Connection closed by foreign host.

Pode ser verificado que o servidor que atendeu requisio foi o WEB1. Repetindo o proce-dimento, a conexo ser respondida pelo WEB2(o IP do cliente remoto deve ser alterado, pois napoltica de balanceamento o IP de origem faz parte do processo. Se no for alterado, a o servidor queatendeu a primeira requisio que ir continuar a responder. O IP foi mudado para 192.0.2.101)

cliente# telnet 198.51.100.4 80Trying 198.51.100.4...Connected to 198.51.100.4.

Escape character is ^].GET / HTTP1.1

24


25/26

HTTP/1.1 200 OKDate: Wed, 20 Mar 2010 15:51:19 GMTServer: Apache/2.0.63 (FreeBSD)Last-Modified: Wed, 20 Mar 2010 14:35:49 GMTETag: "1e3403-31-4842979830d80"

Accept-Ranges: bytesContent-Length: 49Connection: closeContent-Type: text/plain

OI, SOU O SERVIDOR WEB2. Meu IP 198.51.100.21Connection closed by foreign host.

Com isso, os testes realizados comprovam o funcionamento proposto para o sistema.

7 Prs e ContrasO 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 mercadoe softwares open-source)

Sem limitaes de tratamento de dados, que restrita capacidade do hardware(no hnecessidade de licenciamento de acordo com a demanda de processamento/utilizao)

Pode ser customizado de acordo com as necessidades(pois o cdigo-fonte aberto), alm depermitir a agregao de novos servios(que podem ser instalados nos equipamentos) e a inte-

grao com outras ferramentas e sistemasComo 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

8 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 implementadoscom certa facilidade, atingindo os objetivos mensionados na seo 1

Uma procura crescente por solues como esta est se tornando mais comum no mercado, pois ocrescimento de sites de e-commerce, de relacionamento, da quantidade de domiclios e pessoas queacessam servios na Internet, dentre outros, exige que os sistemas que promovam a conectividadeno pare, no fique indisponvel e no apresente perda de desempenho.

Esta soluo(ou boa parte dela) est em uso pelo Provedor Onda, fornecendo redundncia/altadisponibilidade para sistemas de e-mail, de portais de e-commerce, sistemas ERP e bancos de dadosque trabalham em regime de misso-crtica.

Como continuidade da atividade desenvolvida, pode-se melhorar a contruo do sistemas, utili-zando, alm de firewall/balanceador de carga, links redundantes independentes, switches redundan-

tes e outras alternativas/equipamentos que permitam tornar a soluo ainda mais robusta.

25


26/26

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, Julho2009.

[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 theFreeBSD Operating System. Addison-Wesley Professional, Agosto 2004.

[5] Jari Arkko; Michelle Cotton e Leo Vegoda. Rfc5737 - ipv4 address blocks reserved for docu-mentation, 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. The freebsd project, acessado em 20 de Maro de 2010.http://www.freebsd.org.

[8] Peter N.M. Hansteen. The Book of PF: A No-Nonsense Guide to the OpenBSD Firewall. NoStarch 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. Sun BluePrints, 2000.http://www.sun.com/blueprints/1100/HAFund.pdf.

[13] Wikipedia. Load balancing, acessado em 20 de Maro de 2010.http://en.wikipedia.org/wiki/Load_balancing_(computing).

[14] Wikipedia. The wikipedia, acessado em 20 de Maro de 2010.http://pt.wikipedia.org/wiki/Firewall.

carp pfsync

Documents