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