www.kadu.langoni.net

É isso aí, hora de mudanças!

Dessa vez estou voltando pra São José dos Campos, terminando um longo ciclo de 5 anos morando em apartamentos para finalmente voltar a morar em uma casa :)

Vai ser bom por dois motivos, principalmente, primeiro que a Aptitude, minha cachorrinha, vai ter mais espaço; segundo por que pela primeira vez vou morar em um espaço compartilhado, morando com outros dois amigos.

Vai ser uma nova oportunidade, de aprendizado, de crescimento e, por que não, de aproveitamento :)

Depois que eu estiver totalmente instalado tentarei postar com mais frequência sobre esta nova fase e nova rotina.

Abraços a todos!

Gravações feitas essa semana, saindo do forno!!!!

As duas foram escritas em Marataízes/ES em homenagem a minha musa e namorada, Marcelinha =)

Eu sei que sumi, eu sei que abandonei o espaço aqui, mas as vezes é assim!

Tenho trabalhado bastante e vivido bastante tbm, só não tenho tido muito tempo pra postar nada por aqui =)

Tem tempo que estou querendo postar, mas está faltando ainda fechar alguns textos, e escrever outros que estão na cabeça, quem sabe em breve :)

Abraços a todos!

{Nota do Autor} Este é o primeiro de uma série de artigos que irá apresentar um cenário de rede montado em cima de pilha dupla (IPv4 e IPv6) e IPv6 apenas. Irei retratar aqui experiências reais com este protocolo e mostrar como configurar a rede e os principais serviços. Não espere encontrar um guia teórico sobre o IPv6, ou qualquer um dos serviços configurados, pois parto do princípio que quem estiver acompanhando estes artigos já possui conhecimento básico sobre network e serviços de rede, como http, dns, email e etc. {/Nota do Autor}

Tudo começou com um curso de IPv6 na NIC.br que eu estava adiando há mais de ano. Até que parei de enrolar e fui fazer o curso em outubro. Não é que pra minha surpresa eu gostei muito mais do que parecia.

Mas como todos sabem quando eu gosto de uma coisa ou acho que seja realmente válido eu sou xiita mesmo, evangelizo com vontade e defendo até o fim. Pois é, com o IPv6 vai ser assim também.

Vamos lá, neste primeiro artigo vou falar de "tunnel broker", do cenário que estou utilizado e como você pode fazer algo semelhante

Convenções/Glossário

(v4): Refere-se a versão 4 do protocolo IP, utilizando tanto para serviços que rodam sob quanto para o protocolo em si
(v6): Idem ao anterior, mas para versão 6 do protocolo IP

ATA: Adaptador de Telefone Analógico para SIP
POP: Do inglês Ponto de Presença
 

O cenário Geral

Aqui em casa tenho uma estrutura de rede peculiar, o core dela é composto por:

• 1 "switch" encore de 8 portas
• 1 ATA 1FXS 1FXO
• 1 ATA 2FXS
• 1 Netbook ASUS eeePC 701 4G + 1 adaptador usb2ethernet
• 1 Notebook Centrino 2G de RAM
• 1 Notebook Dual Core 2G de RAM
• 1 Roteador Wi-fi em Bridge

Os ATAs são para laboratórios de telefonia (nada haver com este artigo)

Com o netbook eu faço a borda da rede, ele recebe a conexão da NET e fecha o tunel IPv6 com a Sixxs[1] (já falo nisso), carrega um firewall, DHCP(v4), DNS(v4) e apenas para LAN, e mais alguns outros recursos.

Os dois notebooks possuem ubuntu desktop e virtualbox rodando. Para efeito dos artigos não importa em qual notebook está sendo executada cada máquina virtual, e TODOS os servidores são Debian Squeeze.

Por que ubuntu com virtualbox? Muito simples, porque eu ainda posso usa-los como estação de trabalho, pra alguém que venha me visitar e queira acessar a internet, ou até mesmo para em casos de pane no meu notebook de uso diário, se eu tiver uma boa rotina de backup (eu já tive, preciso reestabelecer).

Cenário para IPv6

O netbook fecha um tunel com a SIXXS através da CTBC em um POP localizado em Uberlândia, este tunel possui um IPv6 que me permite acesso a internet. Uma segunda interface de rede possui meu IPv4 privado e alguns IPv6 públicos de uma subnet /48 gentilmente cedida pela SIXXS/CTBC.

Existem:
um Quagga(versão 0.99.17) configurado com duas interfaces de rede roteando algumas subnets /64 do meu bloco para os meus servidores internet
{nota} Por que quagga? Por que num futuro próximo quero estudar OSPF e BGP, então por que não começar a montar a infra já pensando nisso? {/nota};

um servidor DNS com bind9 autoritativo sobre ipv6.langoni.net e futuramente sobre o reverso da minha subnet;

um servidor http com apache2, php5 e mysql responsável pela hospedagem de www.kadu.ipv6.langoni.net

um sistema cliente que será utilizado para testes internos e externos, falarei dele mais adiante.

Futuramente ainda será adicionado um serviço de ftp e um looking glass ao servidor http, um serviço de email (ainda não escolhi qual), a centralização da autenticação com LDAP, um servidor de  monitoramento para esta infra.

Fora os itens indicados com futuramente o restante já está todo em funcionamento.

Tunnel Broker

Segundo a wikipedia um tunnel broker, no contexto de computação, é um serviço que provê um tunel de rede. Estes tuneis podem prover conectividade encapsulada de uma infraestrutura existente para uma nova.[1]

No meu caso estou usando a SIXXS como provedor do tunnel por conta da parceria com a CTBC e um pop no Brasil. Lembre-se que você está encapsulando v6 sob v4, através de um túnel e tudo isso impacta na performance. Não venha dizer, minha conexão v6 está lenta, isso é esperado. O objetivo aqui é fazer testes de implementações, colocar redes locais em pilha dupla e ver o comportamento e por aí vai.

Vou falar mais um pouco sobre a SIXXS. Eles fornecem gratuitamente o acesso ao tunel e a todos os recursos necessários para se implementar pilha dupla pra quem não possui conectividade v6 nativa. Mas não é entrar e se cadastrar e pronto, e isso foi o que eu achei mais interessante.

Primeiro você cria uma entidade (ou usa uma já existente), se você fizer um whois CEL3-SIXXS encontrará informações sobre a minha entidade.

Segundo você tem que justificar o porque devem deixar você usar o túnel deles, e todas as solicitações futuras (subnet, dns e etc) devem ser justificadas também.

Além disso existe uma moeda local chamada ISK, sim tudo tem custo na SIXXS, solicitar um tunel, solicitar subnet e etc. Você ganha novos ISKs por conseguir provar que consegue manter o tunel online 24x7 ou o mais próximo disso, a cada semana você é remunerado com alguns ISKs por manter seu tunel funcionando. Pra vocês terem uma ideia somente depois de uma semana de funcionamento do tunel solicitado é que você terá ISKs para solicitar uma subnet. Não precisa haver tráfego no tunel, ele tem apenas que estar online. E o tunel pode ser feito em praticamente qualquer conexão de internet. Recomendo que todos leiam o FAQ no site deles antes de inciar a aventura.

Existem outros por aih, como o da he.net, este possui até uma certificação em IPv6 gratuita pra gente fazer depois que o lab estiver pronto. Maiores informações em [3]

E como eu, neste caso você, posso brincar também?

Vamos lá, primeiro passo, leia sobre o IPv6 (se ainda não o fez) e entenda como funciona a nova numeração IP. Mas tenha em mente o seguinte, analisando grossamente o IPv6 não houveram grandes mudanças, então tudo o que você pensa em v4 só precisa adicionar mais 96 bits e tá pronto! :p Ou seja o conceito todo do endereçamento de rede não mudou, só que o endereço deixou de ter 32 bits, passando para 128 e algumas coisas passaram a ser mais importantes dos que no v4, como o protocolo icmp.

Segundo passo, imagine sua infra, quantos servidores você quer subir e por que, qual hardware você vai ter disponível pra brincar, e pense em como você montaria em v4.

Terceiro passo, monte tudo em v4 e acrescente o v6, depois remova o v4 e veja como tudo funciona, ou não!

Sendo mais didático :)

Você precisa basicamente do seguinte, um computador (se for usar o tunel da sixxs ele tem que ficar ligado 24x7), um sistema de máquinas virtuais (eu gosto muito do virtualbox) e muita disposição. Lembre-se das palavras de Albert Einstein “Sucesso e genialidade, são 10 por cento de inspiração e 90 por cento de transpiração”.

Para ajudar um pouco mais vou citar como exemplo meu amigo e incentivador Thiago Oliveira. Ele topou a brincadeira e na estrutura da empresa onde ele trabalha está criando uma(s) máquina virtual para criarmos uma estrutura v6.
 

O maior problema são os testes, pra onde vou testar, como posso mandar um email, acessar uma página ou ainda, como posso saber se o que eu configurei aqui na minha rede está funcionando para o mundo?

Para isso ofereço um apoio e sugiro que outros procurem criar o mesmo. O cliente que identifiquei acima será uma máquina de acesso comportilhado em ambiente chroot. E eu ofereço o acesso a ela para quem quiser, basta entrar em contato comigo para acertar os detalhes. Lembrando que ela só oferece acesso IPv6 e que será monitorada o tempo todo se quiser brincar é pra brincar direito :D

Todo acesso dela e pra ela será feito em cima de IPv6, por isso somente com a sua estrutura v6 pronta é que será possível o acesso a ela. Existiram ping6, traceroute6, w3m (navegador em console), tcpdump e estou procurando um cliente de email pra console que seja "simples" de usar, indicações são bem vindas (tem que suportar pop3, smtp e imap e IPv6 é claro). Através dela você poderá testar o acesso a sua rede, navegação em páginas no seu webserver etc, etc, etc. Facilitando bastante a brincadeira :P

No próximo artigo irei falar mais sobre a configuração do tunel, da subnet e do DNS :D

Abraços a todos!

[1] http://www.sixxs.net
[2] http://en.wikipedia.org/wiki/Tunnel_broker
[3] http://en.wikipedia.org/wiki/List_of_IPv6_tunnel_brokers

Olá para todos!

Vou explicar em detalhes, nas linhas abaixo, como  montar alguns gráficos de consumo de rede em tempo real. O principal objetivo é, como administrador de redes, ter uma visualização melhor do que acontece de tráfego, mas de forma simples, sem ter que acessar ao servidor e usar o iptraf ou sem ter que esperar o tempo médio de 5 muitos do cacti/MRTG. Sem mais demoras vamos lá!

Motivação

Há mais ou menos três anos atrás tive a oportunidade de trabalhar com equipamentos de rádio Nano Station da Ubitiqui e um detalhe sempre me chamou a atenção; o monitoramento de tráfego.
Ele traça um gráfico simples, com duas linhas, que apresentam o consumo de rede de cada interface.

Procurei no google, nestes últimos anos, uma forma semelhante de fazer, algum sistema pronto, e nada. Chegou o dia de colocar a mão na massa!

Primeiro eu tentei com RRD[1], o resultado ficou bom, mas bem aquem das minhas expectativas, eu queria fazer exatamente como no nano, o gráfico na tela, atualizando os pontos a cada X segundos, e não o reload de uma imagem a cada X segundos.

Resolvi então, através da engenharia reversa, criar um sistema semelhante.

Depois de alguns dias entendendo melhor javascript, jquery, flotr e outras coisinhas mais, consegui gerar um código funcional que permite fazer o gráfico de duas maneiras: usando o /proc/net/dev e usando regras do iptables.

Funcionamento

A ideia é bem simples, ler um contador e marcar pontos em um gráfico.

O download do código pode ser feito aqui.[2]

Você precisará de um servidor web com suporte a php.

O arquivo, após descompactado, irá criar o diretório monitor, que deve ser colocado onde possa ser acessado via navegador.

O sistema funciona com dois conjuntos de arquivos:
index.php e status.php - responsável por criar os gráficos da interface de rede
index2.php e status2.php - responsável por criar os gráficos baseado em regras do iptables.

index.php, no começo do arquivo tem a variável iface[]. Ajuste ela para a ou as interfaces que deseja monitorar. Está com eth1 e eth2 comentado (// no começo). Depois no arquivos status.php você ajusta a variável path com o caminho onde ele vai encontrar o script get_net_info.sh, que está na raiz do diretório monitor.

No index2.php você ajusta a variável $serie_nome de modo a informar
quantas são e quais são as origens de dados.
No status2.php você ajusta as variáveis de captura do iptables

no iptables crie duas chains personalizadas chamadas YLOG e YJUMP (o
nome é sugestivo, basta apenas modificar o status2.php de acordo com os
nomes que vc criar.
Eu fiz a seguinte adição de regras

$IPT -t filter -N YLOG
$IPT -t filter -N YJUMP
#WEB
iptables -t filter -A YLOG -m multiport -p tcp --sport 80,443 -j YJUMP
iptables -t filter -A YLOG -m multiport -p tcp --dport 80,443 -j YJUMP
#SMTP
iptables -t filter -A YLOG -m multiport -p tcp --sport 25,587 -j YJUMP
#POP/IMAP
iptables -t filter -A YLOG -m multiport -p tcp --sport 110,143,993,995 -j
YJUMP

iptables -t filter -I INPUT -j YLOG
iptables -t filter -I OUTPUT -j YLOG
iptables -t filter -I FORWARD -j YLOG

A segunda chain personalizada foi utilizada apenas para evitar o uso do
jump LOG, que encheu meu HD de um dia para o outro, desta modo a
contagem ainda funciona e não gera nenhuma interferência nas regras do
firewall.

É MANDATÓRIO que estas regras sejam as primeiras de cada uma das chains
da tabela filter.

Foi tudo preparado no fim de semana e pode conter bugs e código mal escrito. Quem quiser contribuir com modificações e sugestões deve se sentir a vontade!
Em [3] encontra-se a documentação da API que desenha os gráficos, você pode utilizá-la para personalizar a visualização dos gráficos.

Abraços a todos!

[1]http://oss.oetiker.ch/rrdtool/
[2]http://www.kadu.langoni.net/net_monitor-1.0.tgz
[3]http://flot.googlecode.com/svn/trunk/API.txt