Sistema de Firewalls em Alta Disponibilidade e Balanceamento de Carga
Éder de Mattos Curso de Redes e Segurança em Sistemas Pontifícia Universidade Católica do Paraná Curitiba, março de 2010
Resumo
A disponibilidade é um atributo para todos os serviços, especialmente os que são providos através da internet/redes privadas e que significa que está disponível para acesso. Alta disponibilidade está relacionada a provimento de serviços que não podem parar, que devem estar sempre disponíveis, mesmo com falhas de equipamentos, energia, conectividade ou qualquer outro tipo de adversidade. São tolerantes à falhas. Se um sistema parar, poderá ocasionar em prejuízo, principalmente em se tratando de operadores de Internet/conectividade, instituições financeiras, sistemas de comércio eletronico, dentre outros.
1 Introdução
O objetivo deste trabalho é apresentar um sistema de firewalls operando em redundância/alta disponibilidada e apto a realizar balanceamento de carga para aplicações clientes. Apresenta-se dividido em 8 seções, na primeira(esta), a introdução. Na seção 2, uma apresen- tação sobre disponibilidade e seus fundamentos. Na seção 3, aspectos sobre firewalls. Na sessão 4, sobre balanceamento de carga. Na seção 5, a estrutura de base para o trabalho, o FreeBSD e o desenvolvimento/configuração do projeto. Na seção 6, aspectos relacionados ao funcionamento do sistema e administração básica dos softwares. Finalmente na seção 7, os prós e contras da estrutura apresentada e por fim, a conclusão, na seção 8. Quando uma pessoa acessa algum site ou serviço na rede/Internet, ela quer uma resposta rápida, alta qualidade e acima de tudo, que esteja disponível. A disponibilidade é almejada tanto pela pessoa que possui um pequeno site e quer que ele seja visto, quanto uma grande corporação, que possui inúmeros serviços e precisa que estejam disponíveis. A falta da disponibilidade pode gerar inúmeros transtornos, sendo os maiores deles, depreciação da imagem e prejuízo financeiro. Neste contexto, os sistemas computacionais podem ser agrupados em quatro categorias[12], de acordo com a aplicação pretendida: • Computação de Propósito Geral, formado pela maior parte dos sistemas, que inclui aplicativos de usuário/profissional, são 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 serviços que podem ser aces- sados à qualquer momento, e disponibilidade é a métrica para tais sistemas, atribuindo um nível de tolerância para indisponibilidades. Estão inclusos neste ítem: sistemas bancários e de telecomunicações.
1 • Sistemas de Missão Crítica, formado pelos sistemas que possuem completa tolerância à falhas e não podem parar em hipótese alguma, como sistemas de tempo-real, sistemas de controle de tráfego aéreo, militares e de usinas nucleares • Sistema de Longa Vida, formado por sistemas com alta confiabilidade e que, normalmente, são de manutenção extremamente cara e complexa, como sistemas de satélite e naves espaciais. Para não estar suscetível a problemas de disponibilidade, empresas criam projetos, realizam treinamentos e, acima de tudo, realizam investimentos para chegar ao objetivo, estar acessível e funcional. Ítens como este e outros serão abordados neste trabalho, que expõe um modelo de sistema de firewalls, atuando de forma redundante(Sistema de Alta Disponibilidade), servindo de base para uma estrutura de provimento de serviços redundantes e tolerante à falhas.
2 Disponibilidade, Confiabilidade e MTBF
A definição de confiabilidade[12] é a probabilidade de operação de um sistema, em um determi- nado período, sem apresentar falhas. É apenas um dos muitos fatores que influenciam a disponibi- lidade e mede a capacidade de um sistema funcionar sem interrupções durante o fornecimento de um serviço/aplicação. O MTBF (mean time between failures) é uma métrica relacionada à confiabilidade, que mede qual o intervalo de tempo médio entre duas falhas consecutivas(normalmente medido em horas). Alguns tipos de MTBF são: MTBF de hardware(tempo médio entre falhas de hardware), MTBF de sistema(tempo médio entre falhas de sistema, que podem ser minimizadas com a utilização de hardware redundante), e MTBI(mean time between interruptions, que são falhas temporárias de sistema sem a realização de reparos). O MTBF não indica exatamente quando a falha irá ocorrer(pois é um valor baseado em análise estatística), porém 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 serviços quanto para clientes. A empresa que provê qualquer tipo de serviço precisa oferecer métricas e referências a respeito do que ela faz para manter o serviço disponível. As métricas são cálculos que levam em conta um grande número de variáveis, mas que ao fim, resulta em um número em formato %(percentual). Este número explicita o quanto aquele serviço esteve estável no último período de aferição. Uma prática comum é utilizar ferramentas/metodologias de gerenciamento para monitorar tais indicadores, levando à uma desiganação muito utilizada, apresentada em contratos de fornecimento de serviços, que é o SLA(Service Level Agreement ou Nível de Acordo de Serviço). O SLA abrange, além de disponibilidade, tolerância à falhas, performance, prioridade e incidência de erros, e apresenta o % de disponibilidade do sistema. No controle de tudo está o gerenciamento de serviços, que envolve inúmeros aspectos, desde equipamentos até a satisfação do cliente.
2.2 Fundamentos de Disponibilidade Disponibilidade geralmente é medida pela taxa de tempo disponível, que corresponde ao tempo aproximado de disponibilidade e representa a porcentagem de tempo que um sistema computacional está disponível durante a vida útil. Por outro lado, para obter o tempo de indisponibilidade(anual), a métrica downtime pode ser calculada, de acordo com a seguinte fórmula:
Downtime(em minutos) = (1 − T empoDisponivel) ∗ 365 ∗ 24 ∗ 60 (1)
2 O % de disponibilidade é calculado da seguinte maneira:
MTBF Disponibilidade = (2) MTBF + MTTR Onde MTBF é Mean Time Between Failures e MTTR é Mean Time to Repair
A tabela 1 apresenta os valores de disponibilidade em relação ao período de downtime:
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 Confiabilidade e Disponibilidade Existe diferenças entre confiabilidade e disponibilidade. Dependendo da situação, maiores bene- fícios podem ser obtidos com confiabilidade ao invés da disponibilidade e vice-versa. Casos em que confiabilidade é mais importante ocorre quando os sistemas estão localizados em áreas remotas e com manutenção cara. Embora disponibilidade seja função da confiabilidade e manutenabilidade, é possivel sistemas de baixa confiabilidade trabalhar em alta disponibilidade, fazendo uso de artifícios como redundância de equipamentos(quantidade de equipamentos)(N + 1, N + 2, N + N) e redun- dância de hardware dentro do equipamento(HD’s em raid, fonte redundante, multiplas interfaces de rede, etc). A confiabilidade mede a habilidade de um sistema operar continuamente sem interrup- ções. Um sistema computacional com alto MTBF indica que, em média, o sistema opera por longos períodos sem nenhuma interrução por falha de equipamento. Por outro lado, a disponibilidade mede a habilidade de um sistema suportar um determinado nível de serviço. Uma maneira aproximada(90 % de precisão) de conversão de confiabilidade para disponibilidade[12] é a seguinte:
t − (1 − R(t))dt Disponibilidade = (3) t onde: R(t) é a confiabilidade de um sistema no período de tempo t, e dt é o tempo de indisponibilidade(em horas).
A confiabilidade, R(t), de um sistema representa a probabilidade de um sistema não apresentar falhas em um período de tempo t. O valor de 1 - R(t) representa a probabilidade de um sistema apresentar falhas em um período de tempo t. Multiplicando 1 - R(t) por dt , aproxima-se o total de tempo indisponível no mesmo período. O valor de t - ( 1 - R(t))dt apresenta o tempo total que um sistema está operando, durante o período de tempo t (uptime). Dividindo t - ( 1 - R(t)) dt pelo período de tempo total t, obtemos a disponibilidade total.
2.4 Manutenabilidade Manutenabilidade,M(t), é a probabilidade de um serviço(manutenção) ser completado durante um período t. Se a manutenabilidade for de 0,95 para três horas, significa que a probabilidade de o serviço ser concluído em 3 horas é de 95%. Uma alta confiabilidade reduz a frequência de falhas
3 de sistema e uma alta manutenabilidade reduz a duração de cada incidente de reparo, aumentando a taxa de disponibilidade. Comumente utilizada como métrica de manutenabilidade, o MTTR é o tempo médio necessário para o reparo completo(sem incluir o tempo de logística, somente o tempo de substituição e ação técnica).
3 Firewall
Firewall[14], nascido na década de 1980, é um dispositivo participante de uma rede de compu- tadores com objetivo de seletivamente, permitir ou negar a passagem de dados através dele, de um ponto à outro da rede, de acordo com políticas/padrões adotados. Abrange os equipamentos de filtros de pacotes e de proxy de aplicações, associados a redes TCP/IP. Pode ser encontrado na forma de software e hardware, ou na combinação de ambos (neste caso, normalmente é chamado de appliance). A complexidade de instalação depende do tamanho da rede, da política de segurança, da quantidade de regras que autorizam o fluxo de entrada e saída de informações e do grau de segurança desejado. Nos primórdios, 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 criação de listas de acesso e não checava o estado de conexões TCP, apenas poderiam ser criadas regras do tipo: • Restringir tráfego baseado no endereço IP de origem ou destino; • Restringir tráfego através da porta (TCP ou UDP) do serviço. Posteriormente, foi criado o firewall de estado, que armazena o estado das conexões e filtra com base nesse estado(estados: novas conexões, estabelecidas, relacionadas a outras existentes; Firewall Statefull), podendo ser criadas regras do tipo: • Restringir tráfego baseado no endereço IP de origem ou destino. • Restringir tráfego através da porta (TCP ou UDP) do serviço. • Restringir o tráfego para início de conexões. • Restringir o tráfego de pacotes que não tenham sido iniciados a partir da rede protegida. • Restringir o tráfego de pacotes que não tenham número de sequência corretos. Uma nova propoposta, mais recente que o firewall de estados é gateway de aplicação/balanceador de carga, também conhecido como firewall de aplicação ou firewall proxy, que compreende um sistema capaz de receber uma conexão, decodificar protocolos na camada de aplicação e interceptar a comunicação entre cliente/servidor para aplicar regras de acesso e posterior permissão/seleção do servidor de destino. Entre as funcionabilidades, inclui: • Todas as regras do firewall de estados • Restringir acesso FTP a usuários anônimos • Restringir acesso HTTP para portais de entretenimento • Restringir acesso a protocolos desconhecidos na porta 443(HTTPS). Já os firewalls de última geração provê solução comercial para redes de comunicação TCP/IP. Realiza SPI(Stateful Packet Inspection), inspecionando pacotes e tráfego de dados baseado nas características de cada aplicação, nas informações associadas a todas as camadas do modelo OSI (e não apenas na camada de rede ou de aplicação) e no estado das conexões e sessões ativas, realiza prevenção de intrusão para fins de identificar o abuso do protocolo TCP/IP mesmo em conexões aparentemente legítimas, e DPI (Deep Packet Inspection), associando as funcionalidades do SPI com as técnicas dos dispositivos IPS(Intrusion Prevention System).
4 4 Balanceamento de Carga
O balanceamento de carga(LB)[13] promove a distribuição de fluxo de acesso para dois ou mais servidores, links, processadores, ou outros tipos de recursos. A utilização do sistema de LB melhora a confiabilidade e redundância, já que uma de suas principais funções é compor clusters/farms de servidores(além de promover alta disponibilidade), permitindo uma divisão de carga entre os participantes. O sistema LB é muito utilizado para aplicações web(e-commerce principalmente), prover serviços de FTP, DNS, NTP, dentre outros. Dentre as principais caracetrísticas, encontram-se: • Garantir a persistência das sessões • Dividir a carga de maneira assimétrica • Aceleração SSL • Proteção de ataques de negação de serviço • Compressão, cache e segurança HTTP • Checagem do estado dos participantes de um clustet/farm(se um participante não estiver respondendo corretamente, é removido do pool) • Filtragem de conteúdos • 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 conexões que estão chegando em um host. Atua como balanceador de carga, gateway de aplicação ou proxy transparente. É capaz de monitorar a disponibilidade de um grupo de hosts e de serviços específicos 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 modalidade de relay, opera em camada 7, de maneira individual(não necessita do PF), permitindo a filtragem no nível de aplicação e de protocolos específicos.
5 Estrutura
Dentre os fatores importantes para a elaboração deste trabalho, alta disponibilidade, baixo in- vestimento e ROI(return on investimet) são os principais. Optou-se por uma estrutura de servidores de plataforma CISC(Complex Instruction Set Computer) AMD64/x86_64(estrutura de 64 bits pro- posta pela fabricante AMD, compatível com o conjunto de instruções mais antigo, denominado i386, proposto pela Intel na década de 1980). Como característica estrutural de equipamento, foi optado por servidores com disco e fonte re- dundante(que justamente são os componentes que mais apresentam falhas), com garantia de 36 meses e tempo de resolução(contrato firmado com o fornecedor, que estabelece um prazo para a resolução da falha de hardware) de 24 horas e configurado para operação em rack de 1U(1 unidade de rack). Características de processador, memória e capacidade de disco foram optados por, res- pectivamente, 1 processador de quatro núcleos e 2GHz, 2GB de memória RAM e disco SAS de 10K RPM e 73GB de espaço. 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 características de processamento que estas placas possuem(no FreeBSD estas placas são reconhecidas como em0, em1, em2..., devido ao nome do módulo do kernel, aliás, todas as placas de rede nos sistemas BSD adotam como identificação para elas, o nome do módulo de firewall que implementa a comunicação com o dispositivo de hardware).
5 5.1 FreeBSD Na sequência do trabalho, o sistema operacional escolhido para gerenciar toda a estrutura é o FreeBSD [7], que é um Sistema Operacional BSD UNIX avançado, com principal objetivo ser muito eficiente[4]. Com mais de trinta anos de contínuo desenvolvimento, melhorias e otimizações, provê um sistema de rede avançado, seguro e de alta performance, utilizado como base para inúmeros sitemas de acesso massivo. O FreeBSD é um sistema muito robusto, de farta documentação disponível, que possui um sis- tema muito eficiente de gerenciamento de processos, alocação de memória, utilização de cpu, uma das melhores pilhas TCP/IP[10], dentre outras inúmeras qualidades. Amplamente utilizado para prover serviços 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 por inúmeras empresas para publicação de conteúdo na web, como Yahoo!, Apache, Sony, Netcraft, Onda(Curitiba). Licenciado sob a licenca BSD[9], permite que seu código fonte seja alterado sem a necessidade de publicar as alterações realizadas, possibilitando às empresas, desenvolver produtos, comercializá-los, sem ter que divulgar o código fonte editado.
5.2 FreeBSD e Firewall Em se tratando de serviço de rede, o FreeBSD é muito competente[2]. Para atuar como firewall, a mesma coisa. É capaz de trabalhar com 3 softwares diferentes para desempenhar tal função[11], IPFILTER (também conhecido como IPF), IPFIREWALL (também conhecido como IPFW), e OpenBSD PacketFilter[3](também conhecido como PF). O FreeBSD também possui 2 sistemas de controle de tráfego, ALTQ(Alternate Queuing) e dummynet. Dummynet trabalha de maneira incorporada ao IPFW, assim como ALTQ com PF. Também é possível a utilização mesclada das estruturas de firewall e controle de tráfego[11], não abordada neste trabalho. A razão para o FreeBSD operar com múltiplos sistemas de firewall é permitir que cada pessoa trabalhe de acordo com a preferência e de acordo com as necessidades. Alguns preferem, por exemplo o IPFILTER para tratar regras de NAT e FTP, devido à facilidade de criação das regras. Para o trabalho em questão, o firewall adotado é o PF. O PF foi portado do OpenBSD para o FreeBSD em 2003 e em 2004, foi lançada a versão 5.3 do FreeBSD com PF já integrado ao sistema, utilizando ALTQ para prover QoS(qualidade de serviço). Junto com o PF, outros dois sistemas trabalham em conjunto: o PFLOG[1] e o PFSYNC[8]. O pflog é o responsável pelo tratamento/arquivamento dos logs gerados pelo PF. Já o pfsync faz um trabalho mais elaborado. Ele cria uma interface de rede pfsync, responsável por monitorar todas as alterações processadas na tabela de estados do PF(o tráfego de pfsync é encaminhado através da interface real ao qual ele está mapeado, enviando os dados ao endereço multicast 224.0.0.240. Como só existem dois firewall, o master envia ao backup. Se existissem mais que dois firewalls ligados com pfsync, todos os backups receberiam as tabelas de conexão do firewall via multicast). Desta maneira, todas as conexões ativas em um firewall podem ser sincronizadas com outro firewall e permitir que, se um firewall parar, outro pode assumir sem que qualquer conexão ativa seja perdida.
5.3 FreeBSD em Alta Disponibilidade O FreeBSD, é um sistema focado em desempenho e uma característica que implementa um sistema de alta disponibilidade incorporada por ele, a partir da versão 5.4, o CARP(Common Address Redundancy Protocol). O carp[3] é um protocolo multicast que permite múltiplos hosts compartilhar um ou mais endereços 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:
6 net.inet.carp.allow=1 net.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 geração de logs pelo carp Pode ser utilizado tanto para disponibilidade quanto para balanceamento de carga. Mas a utilização do carp por si só não faz o tabalho completo, pois a função dele é manter o IP ativo e disponível. E as conexões 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 elaboração do projeto, foram necessários 2 servidores(descritos anteriormente), instalados com o FreeBSD. Detalhes de como instalar, atualizar, recompilar o kernel, realizar otimizações e demais informações 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.
carp0
FW2 FW1 em0 em0 em2 em2
pfsync em1 em1
carp1 carp2
cluster/farm SMTP cluster/farm WEB
Figura 1: Estrutura em Alta Disponibilidade
7 Tomados os 2 servidores já instalados, com o ports[11] instalado e o sistema operacioanl atualiza- dos, para ativar as funcionalidades pretendidos é necessário recompilar o kernel(núcleo) do FreeBSD, com a inclusão dos seguintes módulos/opções:
device pf #(habilita o PF) device pflog #(habilita a geração de logs no PF) device pfsync #(habilita o sincronismo entre 2 sistemas PF) device vlan #(habilita o suporte à vlan, não 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 hierárquica 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 através de POLLING) options HZ=1000 #(define a granularidade do timer do sistema(em 1ms), #melhora o tratamento de taxa de tráfego alta)
Com o kernel pronto, parte-se para a instalação do software relayd. Para realizar a instalação, foi utilizado o ports, da seguinte maneira:
root# cd /usr/ports/net/relayd (entrar no diretório do software que se deseja instalar) root# make install clean (baixa o código fonte do software da internet, compila, instala e limpa o que restou do processo de compilação)
O passo seguinte é habilitar a inicialização/execução dos serviços. No arquivo /etc/rc.conf, deve ser adicionado:
pf_enable="YES" #(permite a execução do PF) pf_rules="/path/to/pf.conf" #(localização do arquivo que define regras) pf_program="/sbin/pfctl" #(local que está o pfctl - controla o PF) pfsync_enable="YES" #(permite a execução do PFSYNC) pfsync_syncdev="em2" #(interface de rede que o PFSYNC utilizará) pflog_enable="YES" #(para ativar a criação de logs no PF) pflog_logfile="/var/log/pflog" #(local onde o PF gravará os logs) pflog_program="/sbin/pflogd" #(local que está o binário pflog) gateway_enable="YES" #(habilita ação de gateway/router) relayd_enable="YES" #(habilita a execução do relayd)
A configuração de rede é outro ponto fundamental e que deve ser realizada com muita atenção. Como se trata de uma estrutura complexa, existe vários detalhes que precisam ser ajustados de modo a garantir o funcionamento do sistema. A estrutura de firewalls 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 IP’s[5] com interfaces utilizadas:
8 Tabela 2: Endereçamento de Rede
Endereçamento de Rede Equipamento Interface IP/Netmask Gateway default - 192.0.2.254/24 FW1 em0(WAN) 192.0.2.1/24 FW1 em1(LAN) 198.51.100.1/24 FW1 carp0 192.0.2.3/24 FW1 carp1 198.51.100.3/24 FW1 carp2 198.51.100.4/24 FW1 em3(pfsync) 203.0.113.1/30 FW2 em0(WAN) 192.0.2.2/24 FW2 em1(LAN) 198.51.100.2/24 FW2 carp0 192.0.2.3/24 FW2 carp1 198.51.100.3/24 FW2 carp2 198.51.100.4/24 FW2 em3(pfsync) 203.0.113.2/30 SMTP1 X 198.51.100.10/24 SMTP2 Y 198.51.100.11/24 WEB1 Z 198.51.100.20/24 WEB2 W 198.51.100.21/24 Cliente Remoto K 192.0.2.100/24 teste 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 seguinte conteúdo:
defaultrouter="192.0.2.254" #rota/gateway default hostname="fw1.teste.com.br" #hostname associado ao firewall/LB 1, no domínio 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 máscara 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 através 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 eleição #master/backup - quanto menor o valor, mais prioridade de virar master, #pass @abc} é a senha utilizada para permitir a autenticação #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 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"
Após configurada a rede, o próximo passo é configurar o relayd, a princípio para realizar balan- ceamento de carga para dois serviços escolhidos, SMTP(Simple Mail Tranfer Protocol - envio de e-mails) e HTTP. Para SMTP, a configuração focada no princípio 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 persistência de estados) aos hosts ativos nas tabelas específicas. O fi- rewall/LB(daqui pra frente chamado de LB) passa a mapear um IP e porta pertencente à ele. Qualquer conexão entrante que chega ao LB direcionada ao IP/porta é interceptada, redirecioando o serviço pretendido ao host do cluster/farm que deverá receber a conexão no momento. O host processa a requisição e a retorna ao LB, que responderá ao cliente que solicitou a requisição. A figura 2 ilustra como ocorre a comunicação.
Cluster/farm 2 IP_2 IP_3 IP_1 1 IP_4
IP_5 4 LB 3
Figura 2: Modelo de redirect
As estapas 1, 2, 3 e 4 correspondem à: • 1 - A requisição sai do cliente com IP_1 e destino ao serviço(IP virtual presente no LB) de IP_3. • 2 - Ao chegar ao LB, este manipula os pacotes e altera o endereço de destino, de IP_3 para IP_4 ou IP_5. • 3 - O servidor(agora origem) que recebeu a requisição responde ao solicitante(destino), IP_1, envaminhando os dados ao LB. • 4 - Ao chegar no LB, este manipula os pacotes novamente e altera o endereço 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 tráfego entre cliente e servidor, em contraste ao redirecinamento, ele irá criar um socket que escutará e aceitará conexões entrantes, em um IP e portas definidos na configuração. Qualquer conexão realizada no IP/porta será tratado como se o LB fosse o servidor, ele fará o
10 proxy das conexões(ao mesmo tempo que realizará uma conexão com o host que deverá receber a requisição) e ele passará a intermediar a relação cliente/servidor, operando em camada 7(também chamado de gateway de aplicação ou proxy de camada 7). O propósito da função relay é prover um balanceamento de carga avançado, baseado em características específicas de protocolos, tais como cabeçalhos HTTP, aceleração SSL ou manipular outros protocolos em nível de aplicação. A figura 3 ilustra como ocorre a comunicação.
Cluster/farm
LB IP_4 IP_1 IP_2 IP_3
1 2 IP_5
Figura 3: Modelo de relay
As estapas 1 e 2 correspondem à: • 1 - A requisição 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 conexão 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 mantém a conexão do cliente e faz proxy da conexão), este realiza uma conexão de saída com o servidor que deverá responder à solicitação(IP_4 ou IP_5, de acordo com a política 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 configurar o relayd, deve ser criado/editado o arquivo /usr/local/etc/relayd.conf com as seguintes opções:
################################################################################# ## GLOBAL ################################################################################# interval 5 #tempo entre checagem dos hosts, em segundos timeout 1000 #tempo que aguarda a resposta da checagem, em milisegundos prefork 8 #número de processos(quando opera em relay) que trata o relay de #conexões log updates #grava em log apenas as atualizações. Por padrão 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 SERVIÇO ################################################################################# smtp="198.51.100.3" #IP virtual alocado no LB, que receberá as requições #destinadas ao serviço de SMTP. web= "198.51.100.4" #IP virtual alocado no LB, que fará proxy das requisições #destinadas ao serviço HTTP. #################################################################################
################################################################################# ## TABELAS ################################################################################# table
################################################################################# ## AÇÕES ################################################################################# redirect SMTP #função 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 conexões por ele #atendidas, para ser tratadas pelo firewall PF
forward to
} protocol "WWW" #Define um protocolo utilizado como template #para ações e configurações para o relay {
12 tcp { nodelay, socket buffer 65536 } #Define como protocolo o TCP e utiliza as opções: nodelay(recomendada #para prevenir delay/atraso em conexões 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 função 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 utilização do protocolo WWW no relay forward to
Na sequência, é necessária a configuração do PF[8][1], para permitir a correta interação com o relayd e a passagem dos dados destinados aos servidores e demais tráfegos liberados. Para isso, deve ser editado/criado o arquivo /etc/pf.conf com as seguintes entradas(a configuração é a mesma para os 2 LB):
################################################################################# ## GLOBAL ################################################################################# set limit { states 200000, frags 100000, src-nodes 130000 } #configura limites máximos aceitáveis para a tabela de estados do #do firewall: 200000 de estados, 100000 de fragmentos, e 130000 origens #diferentes de conexão
set block-policy return #configura a política padrão de bloqueio set loginterface em0 #configura como interface que monitora a geração de logs a WAN(em0) set debug urgent #ativa a opção 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 } #configuração para tratamento de timeouts para TCP, UDP, ICMP e outros
13 scrub in all fragment reassemble no-df scrub out all random-id #ativa normalização de pacotes fragmentados tando para entrada quanto #para saída 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
## 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 #################################################################################
## CARP’S ################################################################################# 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 tráfego bloqueado
14 ################################################################################# ## TABELAS #################################################################################
################################################################################# ## QoS/FILAS #################################################################################
##QoS padrao para UPLOAD. não será necessário o controle de download ################################################################################# altq on { em0 } hfsc bandwidth 1Gb qlimit 500 queue { default, serviço } #ativa confrolador de banda altq, na interface em0, com política de controle #de fila hierárquica HFSC, largura de banda de 1Gbps, qlimit(número de #pacotes mantidos em fila) de 500, e 2 filas definidas, default e serviço 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 política de #controle de fila hierárquica HFSC, fila default, com garantia de 10Mbps e #limite de 10Mbps com política de descarte RED queue servico bandwidth 600Mb qlimit 300 priority 7 hfsc\ ( linkshare 600Mb upperlimit 600Mb red ) { smtp, web, ssh } #fila serviço, com 600Mbps, 300 pacotes de tamanho de fila, prioridade 7, #controle de fila hierárquica, permite compartilhar entre suas duas subfilas #600Mbps e limite de 600Mbps, compolítica de descarte RED e define três #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 hierárquica, com garantia de 250Mbps, política de descarte #RED, limite de utilização compartilhada de até 500Mbps e política 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 ## Relayd rdr-anchor "relayd/*" #Ativa o redirecionamento, é utilizado pelo relayd
################################################################################# ## DIRECIONAMENTOS #################################################################################
################################################################################# ### REGRAS #################################################################################
## ADMIN ################################################################################# pass in quick on $wan inet proto 1 from
## 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
## 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 conexões marcadas com a TAG # RELAYD_SMTP. A diretiva synproxy state força a realização do handshake # completo e cria um tratamento da conexão 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 6 Funcionamento
O funcionamento do sistema é complexo, porém simples de ser gerido e mantido. Como men- sionado anteriormente, o FreeBSD apresenta farta documentação e de acesso facilitado através do site: http://www.freebsd.org. A operação básica do sistema consiste em parar e iniciar serviços e ajustes de configuração. Para manipular os serviços de rede no FreeBSD, deve ser considerados dois pontos distintos: programas e serviços que são nativos do SO e programas e serviços instalados de terceiros. Todos os serviços que já vém com o FreeBSD podem ser controlados a partir de /etc/rc.d/Nome_Do_Servico start|stop ... , para serviços como o pf, pfsync, pflog, syslog, dentre outros. Já os instalados(contruídos) por terceiros, estarão em outra localização, em /usr/local/erc/rc.d/Nome_Do_Servico start|stop. . . , para softwares como relayd, net-snmp, postfix, e outros. De início, os dois LB podem ser ligados em qualquer ordem, apenas respeitando a configuração das interfaces de rede(a terceira interface/em2 é ligada entre os dois LB via cabo crossover). Após ligados, os dois LB deverão possuir a seguinte saída(se ligado em portas gigabit de switch) para a execução do comando ifconfig (exceto para as interfaces CARP, que em um dos LB terá status MASTER e no outro BACKUP): em0: flags=8943
No FW2, a saída do comando(para as interfaces CARP) será:
18 carp0: flags=49
Interface Stats for bge0 IPv4 IPv6 Bytes In 12565507959096 166063 Bytes Out 25381148856613 0 Packets In Passed 23262007918 413 Blocked 390198167 1624 Packets Out Passed 75395100311 0 Blocked 176675512 0
State Table Total Rate current entries 5634 searches 238741295155 10257.2/s inserts 4352087757 187.0/s removals 4352098551 187.0/s Counters match 4357434853 187.2/s bad-offset 0 0.0/s fragment 373 0.0/s short 6 0.0/s normalize 11427 0.0/s memory 0 0.0/s bad-timestamp 0 0.0/s congestion 0 0.0/s ip-option 1558 0.0/s proto-cksum 126979 0.0/s state-mismatch 3725936 0.2/s state-insert 0 0.0/s state-limit 0 0.0/s src-limit 0 0.0/s synproxy 534631541 23.0/s Caso seja necessária a inversão entre master e backup(realizar alguma manutenção ou por outro motivo qualquer), basta alterar a prioridade advskew do LB, através do comando ifconfig, de acordo com as seguintes etapas:
19 1. descobrir qual o advskew de cada carp do LB através do comando: root# ifconfig
que exibirá a seguinte saída das interfaces carp para o LB1: carp0: flags=49
e para o LB2: carp0: flags=49
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
e para o LB2: carp0: flags=49
20 carp1: flags=49
Com a realização deste processo, ocorreu a troca entre master e backup, sem perdas de conexões, nem momentos de indisponibilidade do sistema. Em relação ao relayd, este garante que a conectividade/acesso aos servidores, em caso de falha de um deles, não gere indisponibilidade completa do sistema, aliás, ele manterá o servidor que apresentou problema indisponível, mandando todas as requisições 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 summary Id Type Name Avlblty Status 0 redirect SMTPSERVER active 10 table SMTP:25 active (2 hosts up) 20 host 198.51.100.10 100.00% up 21 host 198.51.100.11 100.00% up 0 relay WWWforward active 11 table WEB:80 active (2 hosts up) 22 host 198.51.100.20 100.00% up 23 host 198.51.100.21 100.00% up
A função de habilitar/desabilitar algum host que faça parte de um cluster, por exemplo, remover o host 198.51.100.10(Id 20 do sumário) do serviço SMTP, pode ser feita da seguinte maneira:
root# relayctl host disable 20
Para ver o resultado:
root# relayctl show summary Id Type Name Avlblty Status 0 redirect SMTPSERVER active 10 table SMTP:25 active (2 hosts up) 20 host 198.51.100.10 disabled 21 host 198.51.100.11 100.00% up 0 relay WWWforward active 11 table WEB:80 active (2 hosts up) 22 host 198.51.100.20 100.00% up 23 host 198.51.100.21 100.00% up
Assim, o host 198.51.100.10 não recebe mais requisições, e todas as conexões serão tratadas apenas pelo 198.51.100.11(Com a realização do procedimento, o serviço não ficou indisponível e este artifício pode ser utilizado para realizar manutenções nos servidores. Para retornar o servidor ao cluster:
root# relayctl host enable 20
Para ver o resultado:
21 root# relayctl show summary Id Type Name Avlblty Status 0 redirect SMTPSERVER active 10 table SMTP:25 active (2 hosts up) 20 host 198.51.100.10 100.00% up 21 host 198.51.100.11 100.00% up 0 relay WWWforward active 11 table WEB:80 active (2 hosts up) 22 host 198.51.100.20 100.00% up 23 host 198.51.100.21 100.00% up
6.1 Verificação do Funcionamento A verificação do sistema funcionando pode ser verificada a partir da execução do comando tcpdump, que exibirá o tráfego 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 múltiplos pontos de análise de tráfego: • tcpdump na interface WAN do LB, para averiguar a requisição 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
23 3960872231:3960872231(0) win 0
• Resultados semelhantes podemos obter para o servidor SMTP2, pois como o tráfego é balan- ceado, basta repetir o procedimento que quem irá responder às requisições será o SMTP2. Para apresentação do funcionamento do sistema em relação ao relay(proxy), não se faz necessário o monitoramento das interfaces, uma vez que a conexão é 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 através 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 verificado que o servidor que atendeu à requisição foi o WEB1. Repetindo o proce- dimento, a conexão será respondida pelo WEB2(o IP do cliente remoto deve ser alterado, pois na política de balanceamento o IP de origem faz parte do processo. Se não for alterado, a o servidor que atendeu a primeira requisição é 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.
7 Prós e Contras
O modelo de sistema apresentado neste trabalho possui como pontos fortes: • A robustez(proporcionada pelo FreeBSD) • Baixo custo de implantação(utiliza hardware que pode ser adquirido com facilidade no mercado e softwares open-source) • Sem limitações de tratamento de dados, que é restrita à capacidade do hardware(não há necessidade de licenciamento de acordo com a demanda de processamento/utilização) • Pode ser customizado de acordo com as necessidades(pois o código-fonte é aberto), além de permitir a agregação de novos serviços(que podem ser instalados nos equipamentos) e a inte- gração com outras ferramentas e sistemas Como pontos fracos: • A necessidade de conhecimento avançado em sistemas UNIX(FreeBSD) • Tempo de implementação maior do que se adquirido um sistema pronto(appliances e softwares) • Inexistência de um "fornecedor/fabricante"que realize suporte e atendimento
8 Conclusão
O presente trabalho reuniu um conjunto de ferramentas e as integrou com suscesso em uma solução, que permite criar e manter sistemas em alta disponibilidade e que possam ser implementados com certa facilidade, atingindo os objetivos mensionados na seção 1 Uma procura crescente por soluções como esta está se tornando mais comum no mercado, pois o crescimento de sites de e-commerce, de relacionamento, da quantidade de domicílios e pessoas que acessam serviços na Internet, dentre outros, exige que os sistemas que promovam a conectividade não pare, não fique indisponível e não apresente perda de desempenho. Esta solução(ou boa parte dela) está em uso pelo Provedor Onda, fornecendo redundância/alta disponibilidade para sistemas de e-mail, de portais de e-commerce, sistemas ERP e bancos de dados que trabalham em regime de missão-crítica. Como continuidade da atividade desenvolvida, pode-se melhorar a contrução do sistemas, utili- zando, além de firewall/balanceador de carga, links redundantes independentes, switches redundan- tes e outras alternativas/equipamentos que permitam tornar a solução ainda mais robusta.
25 Referências
[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 Mãos. Novatec, Julho 2009. [3] Theo Deraadt. Openbsd website, acessado em 20 de Março 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 docu- mentation, acessado em 20 de Março de 2010. http://tools.ietf.org/html/rfc5737. [6] Reyk Floeter. Relayd, acessado em 20 de Março de 2010. http://spootnik.org/relayd/. [7] The FreeBSD Foundation. The freebsd project, acessado em 20 de Março de 2010. http://www.freebsd.org. [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 Março 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 Março 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 Março de 2010. http://en.wikipedia.org/wiki/Load_balancing_(computing). [14] Wikipedia. The wikipedia, acessado em 20 de Março de 2010. http://pt.wikipedia.org/wiki/Firewall.
26