Teste de largura de banda e QOS: Jperf (Iperf)

   O Jperf é um front-end gráfico em Java para o iperf. É uma ferramenta livre para testar a largura de banda em rede TCP/IP, sua funcionalidade principal, mas também é possível realizar outros tipos de testes como Jitter, perda de pacotes e configurações de QOS. O Jperf (e o Iperf) tem versões para windows e linux e pode ser obtido aqui : http://code.google.com/p/xjperf/ . Ele não é "instalável", só é necessário que a máquina tenha o JRE.
   A saída do teste é textual (pela aba output) e gráfica, a duração e amostragem são configuráveis.

 
   Ela funciona no esquema  "cliente/servidor": Abre-se uma instância do Jperf em uma ponta do link alvo do teste, configura-se a porta e é iniciado como servidor. Do outro lado do link, fica no modo cliente em que o IP do servidor e a porta (existe uma série de outras opções opcionais para customização do teste) devem ser passados como parâmetros. É possível realizar o teste tanto com TCP como UDP (O cliente e o servidor devem estar configurados para utilizar o mesmo protocolo).

   Considerações importantes:

• O sentido do tráfego é do cliente para o servidor, é como se o lado servidor fosse realizar um download do cliente (o cliente que "empurra" os bits, o servidor só recebe e manda os acks). 
• Infelizmente não é possível configurar a porta origem no cliente o que não torna a ferramenta "perfeita" para um teste de QOS, mas ainda assim "dá pro gasto". Existe uma outra ferramenta mais robusta (mais complicada e mais feia) que consegue realizar isto, é o MGEN,  desenvolvido pela Marinda dos E.U.A  http://cs.itd.nrl.navy.mil/work/mgen/
• É possível abrir várias instâncias do Jperf para testes com vários fluxos em diferentes portas, tome cuidado com as portas para não bater com algum serviço que já esteja escutando na máquina.

   Um teste de QOS pode ser implementado da seguinte maneira:

1. Na ponta que será "servidora" é aberto 3 instâncias do Jperf, cada uma utilizando uma porta distinta que estejam configuradas com prioridades diferentes nos roteadores.
2. Na ponta cliente faça testes variados: ora utilize somente uma porta, depois ative outro fluxo da outra porta ou ainda mais de um fluxo na mesma porta (com a opção parallel streams). Será possível verificar se as políticas de QOS estão funcionando (lembre-se do sentido do tráfego).

   Segue um teste que realizei numa rede wireless N. Os nós (lado cliente e servidor) estavam "linkados" em 65Mbps, na prática não chega a 10Mbps (fica ocilando nos 9Mbps). O lado cliente estava configurado com dois fluxos (parallel strems), durante 600 segundos (Transmit) e a cada 5 segundos era exibida a throughput de cada fluxo e a soma (Report Interval)

      Para mais dicas sobre testes utilizando Jperf (e Iperf), visitem http://openmaniak.com/iperf.php

Alta Disponibilidade(HA): Mcafee Firewall Enterprise 8.2

   Esta postagem demonstra a instalação, utilizando máquinas virtuais, e configurações básicas de um cluster de alta disponibilidade utilizando o Mcafee Firewall Enterprise versão 8.2.

   O MFE tem como base o mesmo sistema operacional do PFsense (FreeBSD) com customizações que leva o nome de SecureOS.

   Este Firewall conta com todas as capacidades de um FreeBSD adicionando algumas funcionalidades interessantes como GTI , GeoIP, Smart Filter, conceito de zonas, interface gráfica e muito, muito mais (como fala a gravação do suporte Platinum da Mcafee kkk). Para quem estiver procurando um firewall, vale a pena conhecê-lo.

   A maior parte da administração rotineira é feita via Interface Gráfica (o software cliente admin console, for windows), embora também esteja disponível acesso SSH (com comandos dos "BSD likes" mais comandos específicos do SecureOS, existe um manual que discorre sobre eles).

   Tendo em mãos a ISO do firewall, pacote de instalação do Admin Console, Vmware Workstation e uma máquina que suporte a execução destes componentes, podemos começar a instalação.

• obs¹: O MFE requer uma licença, caso não seja inserida uma licença válida ele funciona por 30 dias, o que para fins de POC ou LAB é suficiente.
• obs²: Eu tenho acesso a estes softwares por trabalhar em um local que tem licenças MFE e acesso para download no site da Mcafee, caso não seja seu caso, entre em contato com um revendedor/parceiro Mcafee.
• obs³: O MFE tem um manual bem abrangente e a Mcafee tem uma base de conhecimento bacana. 

A estrutura que será configurada:

Topologia e endereçamento dos membros e do cluster

   As configurações de hardware mínimas das VMs para esta configuração de cluster. Lembrando que são necessárias duas máquinas:

   

Realize o boot com a .iso , caso seja uma máquina "limpa" ele realiza um "auto-instalador" e reinicia a máquina. O processo de instalação básica deve ser realizado nas duas máquinas.

Início

Auto Install

Instalação

Término da auto-instalação

 Após esta instalação preliminar ele reiniciará a máquina e pedirá as configurações. Existe uma forma de fornecer as configurações e licenças por meio de um pendrive, utilizando o software "quick start" que é instalado junto com o "admin console". Aqui será configurado manualmente:

Tela após a instalação preliminar

EULA

Aceitando EULA

Identificação para o licenciamento

   Após estas etapas, começa a configuração. Não iremos configurar o firewall para ser gerenciado por um Control Center (Outro produto para centralizar a gerência de um parque de MFEs), não iremos utilizar o modo bridge e, inicialmente, só terá regras que permitem a administração do firewall. Na configuração é requisitado o endereçamento da interface interna e externa, usuário, senha, dns, default gateway e servidor de e-mail. A última pergunta é sobre se a administração será realizada somente pela zona Interna.

   O conceito de Zonas é interessante: várias interfaces de rede podem participar de uma mesma zona e regras podem ser atribuídas por zonas. É um artifício para regras (ou ACLs) ou configurações que podem ser aplicadas para várias redes, evitando redundância.

Configurações

Configurações

Configurações

Revisão das configurações

Software instalado

   Com o software instalado, toda a configuração pode ser realizada via Admin Console. O procedimento é muito simples, basta adicionar um firewall (sua máquina deve estar na mesma rede da interface interna) e o IP. Será pedido o usuário e senha:

Primeiro acesso via Admin Console

Acesso via Admin Console

Janela da aceitação do certificado.

Acesso via Admin Console

Acesso via Admin Console

Dashboard

Configurações das interfaces de rede

IMPORTANTE - Liberando o ICMP echo na zona, se desejado

Configuração de interface de rede

Interfaces de rede

   A configuração das interfaces de rede é muito simples. É importante manter a consistência nos nomes das zonas, das interfaces de rede e do endereçamento nos firewalls que farão parte do cluster. Reserve uma interface de rede, zona e endereçamento para o heartbeat. Uma vez tudo pronto, é hora de partir para o wizard do cluster em uma das máquinas:

Configuração de cluster

Criação do Cluster

Tipos de cluster

   Os modos de funcionamento do cluster no MFE são divididos em duas famílias : Load-Sharing HA (que é a opção homônima) e Failover HA (Peer-to-peer HA ou Primary/Standby HA). O modo Load-Sharing distribue a carga entre os membros, logo os dois membros estarão trabalhando em conjunto, no modo Failover um trabalha e o outro fica em standby. A diferença do Peer-To-Peer para o Primary/Standby é que no segundo você define quem será o principal e ele sempre assumirá a carga caso esteja funcional, no primeiro irá depender do tempo de takeover para saber quem será o principal em um momento de falha. Será utilizada o modo Failover HA - Primary/Standby HA.

   Uma observação importantíssima: O modo Load-Sharing HA é extremamente dependente da solução de camada dois de rede (switching) e exige um cuidado e trabalho bem maior na implantação, por experiência própria tenha cuidado (seja com este produto ou com qualquer outro) quando a solução promover este tipo de funcionalidade (Não é todo switch que possibilita a configuração de Unicast-mirrored ou MAC Multicast e eu acho "feia e ignorante" a solução de Unicast-flooded).

   Após selecionado o modo do Cluster, aparecerá a tela de configuração dos IPs do Cluster, bem como a necessidade de ser configurada a zona de heartbeat (onde é realizado os testes de disponibilidade entre os membros):

Endereços compartilhados do cluster

Zona para o heartbeat

Revisão da configuração do cluster

   Depois da criação do cluster no primeiro membro, é preparada a configuração dos membros adicionais na seção "Pair Members". É indicado o nome, endereço, o tempo de takeover e uma chave de registro. Após isto, é necessário iniciar o wizard do cluster no segundo membro e escolher a opção "join existing cluster" e utilizar as informações previamente configuradas no primeiro membro :

Tela da configuração do cluster

Adicionando um membro do cluster

Término da preparação para o segundo membro

Adicionando um membro no cluster

Parâmetros previamente configurados no primeiro membro do cluster

    Depois destas etapas é só conectar no endereço internal do cluster para a administração. Eis um  cluster de Mcafee Enterprise Firewall com dois membros no modo failover HA Primary/Standby pronto pra guerra. 

Conectando no cluster

Dashboard do cluster

Desvio de tráfego layer-2 (MAC) com bridge transparente - Linux e Ebtables

    Quando numa migração onde não se pode (ou não se quer) realizar uma troca "agressiva" de um dispositivo de rede por um outro (troca de firewall/roteador/gateway) e ainda deseja-se manter o roteamento IP da rede intacto, uma bridge transparente é uma ótima ferramenta para se desviar o tráfego no nível ethernet da comutação de quadros. A bridge é configurada em um Linux , com duas interfaces de rede e que tenha instalado o ebtables. No Ubuntu 10.04 LTS é instalado pelo pacote "bridge-utils".

    Exemplificando melhor a utilização: Imagine um teste de um novo roteador, onde deseja-se que somente o host2 utilize-o, mas sem realizar alterações de roteamento e endereçamento.

Rede exemplo

    Neste caso a bridge é posicionada na entrada LAN dos roteadores, como segue:

    Quando o host2 envia pacotes para redes que ele não está diretamente conectado, neste caso redes diferentes de 10.1.1.0/24, ele envia os pacotes para o gateway. Um pacote endereçado ao gateway do host2, por exemplo um PING para o DNS do google (8.8.8.8), teria estas informações:

MAC destino: AA:BB:CC:DD:EE:FF

MAC origem: MAC_DO_HOST2

IP destino: 8.8.8.8

IP origem: 10.1.1.2

    A configuração completa da bridge para alterar-se o tráfego para o Gateway2 seria a seguinte:

#ativação das interfaces sem IP

ifconfig eth0 0.0.0.0 up 

ifconfig eth1 0.0.0.0 up

#configuração da bridge

brctl addbr br0 

brctl addif br0 eth0

brctl addif br0 eth1

#atribuição de IP para a bridge (para administração)

ifconfig br0 10.1.1.50 netmask 255.255.255.0 up 

# "bypass" se o pacote for com destino a rede interna

ebtables -t nat -A PREROUTING -i eth0 -p ipv4 --ip-src 10.1.1.2 --ip-dst 10.1.1.0/24 -j ACCEPT

#muda o MAC Destino para o Gateway2 para o restante dos pacotes

ebtables -t nat -A PREROUTING -i eth0 -p ipv4 --ip-src 10.1.1.2 -j dnat --to-dst "11:22:33:44:55:66"

    Com esta configuração, a bridge os pacotes que vierem do host2 com destino externo terão seus MAC Destino modificados e sendo encaminhados para o Gateway2 que realizará o roteamento.

    Já utilizei com sucesso esta manipulação na migração de um firewall onde, em um primeiro momento, redirecionamos todo o tráfego dos Proxies de navegação interna. É possível realizar uma migração com as estruturas em paralelo funcionando, serviço por serviço, somente mantendo cuidado e avaliando previamente os possíveis caminhos de roteamento e comutação de quadros que podem ser realizados e então configurando na bridge. 

    Agradeço ao grande mestre Ricardo Barbosa  que ajudou-me na configuração e entendimento dessa funcionalidade. :)

Configuração automática de Proxy WEB: WPAD via DNS

    Defrontei-me com uma necessidade para um segmento de rede wireless para visitantes no órgão onde trabalho. Liberar alguns sites Jurídicos e governamentais para navegação. A idéia proposta era direcionar este fluxo para o nosso filtro de contéudo restringindo o segmento a este tipo de navegação, mas a idéia de instruir pessoas a configurar o proxy nos navegadores não me parecia muito arrojada. A saída foi utilizar a tecnologia WPAD para configuração automática de proxy.
    A forma de funcionamento do Wpad é simples. A estação faz uma pesquisa de DNS por "wpad.dominio" (a informação do domínio já foi recebida por DHCP), caso a pesquisa retorne positiva, ele busca o arquivo wpad.dat via HTTP junto ao host (http://wpad.dominio/wpad.dat). O arquivo wpad.dat contêm a informação de configuração do proxy para o browser que é então utilizada.

Funcionamento do WPAD via DNS

    Configurei um registro A no DNS interno como "wpad", apontando para o host que iria servir o wpad.dat.    
    Caso seja utilizado um Windows Server como DNS interno é necessário um passo adicional retirando o wpad como registro reservado (http://technet.microsoft.com/en-us/library/cc995158.aspx).
    Para servir o arquivo wpad.dat utilizei o mesmo servidor do filtro de conteúdo, no caso Mcafee Web Gateway, que tem a opção de habilitar um webserver para este tipo de situação (É só seguir as instruções do product guide https://kc.mcafee.com/resources/sites/MCAFEE/content/live/PRODUCT_DOCUMENTATION/22000/PD22889/en_US/mwg_702_pg_product_7002778A00_en-us.pdf ).
    O arquivo wpad.dat é um javascript que pode ser customizado de acordo com o ambiente. É possível configurar exceções como, por exemplo, para acessar recursos locais (redes locais) não utilizar o Proxy (Direct).

Conteúdo do arquivo wpad.dat:

function FindProxyForURL(url, host) {
    if (shExpMatch( host, "192.168.0.*" )
    ||  shExpMatch( host, "127.*" )
    ||  shExpMatch( host, "localhost" )
    ||  isPlainHostName( host )
    ||  dnsDomainIs( host, ".tjms.jus.br" )
    ||  dnsDomainIs( host, ".tjms.gov.br" )
    ||  dnsDomainIs( host, ".intranet" )) {
        return "DIRECT"; 
    }
    else
        return "PROXY 172.16.1.2:8080";
}

   Uma vez realizada a configuração o funcionamento é imediato. Realizei testes com Internet Explorer, Firefox e Chrome, a operação é perfeita. :) O WPAD é uma medida simples que pode ser utilizado quando não existe a possibilidade de rodar scripts (Logon Script ou GPO) nos clientes, já que os browsers vem por padrão a opção "detectar automaticamente as configurações" que busca o recurso do WPAD.

Solução de Contorno : Linux (iptables, dnsmasq) + 3G HTC Magic

    Neste final de semana meu ISP de banda larga (NET) está com problemas quanto a conexões com serviços da Microsoft e Google. Meu Gmail estava ruim, o Live Messenger caindo toda hora, Youtube impossível e pesquisa do Google demorando.

     Inicialmente pensei existir algo errado com meu roteador wireless, pois é um D-link antigo, bem, só por ser D-link eu já estava desconfiado (kkk):  rebootei, verifiquei os leases do DHCP, mudei o canal do wireless e nada de resolver.... Parti pra ignorância, abri o wireshark e comecei a analisar o tráfego; verifiquei retransmissão de TCP para os serviços que estavam estranhos. Busquei a intermitência por meio de ping e traceroute, inciando pelo router wireless, passando pelo cable modem, endereços da NET, Embratel e por fim os serviços que eu estava sentindo problemas, resultado: A intermitência só aparecia nos serviços externos. Liguei para a NET e fui informado que realmente existia um problema e que a previsão para a resolução era na madrugada de segunda-feira.

    Desejando acessar os serviços na noite de domingo, pensei em uma solução "geek" para essa indisponibilidade, utilizar o serviço de dados da TIM do celular como gateway da minha rede Wireless de casa. 

    Passo-á-passo:

1. Desabilitei o DHCP do meu D-link;
2. Pluguei o celular no netbook, como é um "android phone" é  Plug-and-Play, já aparece no Linux um interface USB0 com conectividade à internet;
3. Com um cabo crossover, liguei a eth0 do netbook no roteador D-link;
4. Subi um endereço na eth0:
   # ifconfig eth0 10.1.1.20 netmask 255.0.0.0
5. Habilitei o roteamento no parâmetro do kernel e o NAT na usb0 via iptables:
   
   # echo "1" > /proc/sys/net/ipv4/ip_forward
   # iptables -t nat -A POSTROUTING -o usb0 -j MASQUERADE
6. Configurei o range do DHCP com o dnsmasq e ativei-o:
   
   # touch /etc/dnsmasq.conf
   # echo "dhcp-range=10.1.1.30,10.1.1.50,2h" >> /etc/dnsmasq.conf
   # echo "dhcp-option=3,10.1.1.20" >> /etc/dnsmasq.conf
   # dnsmasq
7. Renovei os IPs nas estações e Pronto! :)

Em cima da TV pois é onde pega melhor o sinal do celular :P

    Quando a NET voltar a normalidade é só desligar tudo, habilitar o DHCP do D-link novamente e renovar os IPs das estações. 

OBS: Antes que me perguntem: Sim, eu poderia utilizar o celular direto no PC para navegar mas existem dois problemas: 

1. O sinal da TIM aqui na minha região é fraco, só pegando "legal" na sala, que é onde fica meu "facilities entrance" :);
2. Eu só resolveria a conectividade de uma estação, ficando as outras sem Orkut, Live messenger e Google (para muitos isso significa a falta completa de Internet, kkkk)
   
   

Alta Disponibilidade (HA) : Pfsense (CARP + PFsync)

    Quem vive a realidade de manter um Infraestrutura de TI com serviços importantes  que devem (ou pelo menos deveriam) estar sempre acessíveis,  Alta Disponibilidade em sistemas é primordial.
    Esta postagem tem o objetivo de demonstrar o recurso de Alta Disponibilidade presente no firewall Open Source Pfsense, que utiliza os recursos CARP e PFsync, funcionalidade do FreeBSD que é a base deste firewall. O modo de funcionamento deste HA cluster é Failover (Ativo-passivo), na indisponibilidade do nó "mestre" o nó "escravo" assume os IPs do Cluster e mantém as conexões ativas. A versão utilizada é a 1.2.3-Release, que é a versão estável neste momento.

Topologia utilizada

  
    Foi realizada uma instalação padrão do PFsense. As máquinas, por recomendação da funcionalidade,  necessitam de uma interface separada para a sincronização da tabela de estados. Assim, ficaram com três interfaces: Lan, Wan e Sync.
   A configuração da alta disponibilidade começa no menu "Firewall", na opção "Virtual IPs". Dentro da Aba "CARP Settings"  é configurado as opções do PFsync e a sincronização de configurações entre os Firewalls.

Configuração do master

      Prosseguindo a configuração do nó escravo.

CARP settings nó escravo

    Após este passo, toda a configuração é realizada no nó mestre (regras, nat, ips virtuais e etc) e automaticamente sincronizada com o nó escravo.
    Antes da criação dos IPs virtuais do Cluster, foi criada uma regra para a interface SYNC permitindo a livre comunicação (Firewall, Rules, aba SYNC).

   Prosseguindo com a criação dos Ips Virtuais para o Cluster (Firewall, Virtual Ips). O VHID deve ser único para cada grupo IPs Virtuais.

Configuração Ip Cluster LAN

Ips Virtuais do Cluster configurados.

    Realizado estes ajustes, foi modificado o modo de funcionamento do NAT para Manual Outbound NAT rule generation (Firewall, NAT, Outbound), e no campo translation colocado o IP virtual da WAN (10.1.1.15).

    Findo isto, o Cluter de Alta Disponibilidade já está funcionando. É possivel visualizar os estados de funcionamento das Interfaces Virtuais pelo Menu "Status", na opção "CARP (failover)".

CARP status mestre

CARP status escravo

    Finalizando, gravei um video demonstrando a funcionalidade em tempo real. É possivel perceber o momento da "virada" onde o nó escravo assume o IP virtual, bem como a continuidade do download sendo realizado e os gráficos do tráfego entre as máquinas.

Vídeo demonstrativo