luizluca

OpenWRT: turbine seu roteador! Instalando em um computador ou VM

2012-02-05T21:26:00.001-02:00

Mais um artigo da série sobre o OpenWRT.

Apesar de recomendar o uso do OpenWRT para os "computeiros" em geral, trocar o firmware do seu roteador "para ver como é" o OpenWRT não é uma boa prática. Se este é o seu caso, este artigo foi feito para você.

O OpenWRT, devido a sua gama de roteadores suportados, tem a portabilidade como um fator fundamental de sucesso. Ele precisa operar tanto em dispositivos com ARM, Mips e outros processadores um tanto quanto exóticos para quem somente trabalha com a arquitetura Intel clássica. Se ele funciona para tantas arquiteturas diversas, por que então não funcionaria com um computador i586? Bem, ele funciona.

No mesmo local onde é encontrado os firmwares para os roteadores, existe um "alvo" específico para a arquitetura x86 (ix86, i586). É neste link aqui e é chamada de x86_generic. Assim como para qualquer outra arquitetura, existe também o ImageBuilder que já comentei anteriormente. Porém, o espaço em disco não é problema para um x86, onde o armazenamento gira em torno dos Gigabytes e não Megabytes. No link que passei, como sempre, existe vários arquivos. Dentre as opções de imagens, foi destacar algumas.

openwrt-x86-generic-combined-ext2.img.gz
openwrt-x86-generic-combined-ext2.vdi
openwrt-x86-generic-combined-ext2.vmdk

A versão "combined" não possui a partição /overlay. Ele funciona como a raiz de uma distribuição Linux clássica: alteração direta no disco. Se você apagar o que não deve, pode precisar começar do zero. Bem, isto não é tão crítico em um PC. Basta usar um LiveCD ou reinstalar o OpenWRT. Das três opções que eu listei são, em ordem: uma imagem (compactada com gzip) para ser copiada no disco (usando dd, por exemplo), um disco para VirtualBox e um disco para Vmware. Para experimentar, as duas últimas são as mais indicadas. Existe também a versão rootfs-squashfs, similar ao utilizado em um roteador embarcado, mas ainda não experimentei.

A arquitetura x86_generic também pode ser utilizada não como um "experimento" mas sim como um roteador em produção. Já precisei mais de uma vez montar um roteador com Linux utilizando um PC. No meu caso, até hoje, só utilizei distribuições clássicas, e isso dá um pouco de trabalho. Porém, hoje em dia, diante das facilidades de configuração do OpenWRT, eu optaria por utilizá-lo como "distribuição" dos meus roteadores.

Se for utilizar as versões virtuais (vdi, vmdk) em produção, vale a pena dar uma olhada se os drivers de rede estão "acelerados". Não sei se os drivers paravirtualizados (vmware-tools, vboxadditions) estão integrados na imagem. Mesmo sem eles, acho que o desempenho de um roteador com um processador Core 2 Duo moderno deve ser mais performático do que um processador de 400 Mhz dos roteadores "residenciais" ou SOHO. Com recurso de VLAN, pode-se montar um ambiente bem interessante.

Até a próxima.

OpenWRT: turbine seu roteador! Multiplique suas redes: MultiLAN com VLAN

2012-02-01T18:18:00.000-02:00

Mais um artigo da série sobre o OpenWRT.

No artigo anterior, comentei sobre o uso de múltiplas redes wireless. Hoje, vou falar sobre múltiplas redes LAN.

Em geral, os roteadores possuem duas interface de rede cabeadas: LAN e WAN. A primeira representa as portas da rede local, normalmente umas 4 ou 5 delas. A segunda é utilizada para a conexão ao enlace superior, o que normalmente é a sua conexão com a Internet. Na figura abaixo, a porta azul é a WAN, enquanto as amarelas são para a conexão LAN.

Neste roteador com OpenWRT, a eth0 "representa" o acesso as várias portas da rede local (as amarelas). Fazendo uma analogia com um computador, o que existe "dentro da caixa" é um switch de 4 portas externas e uma interna (chamada CPU), sendo esta interna conectada à interface eth0. A eth0, por padrão, é agregada com a interface wireless, wlan0, para que as duas redes troquem pacotes. Tudo isto já comentei anteriormente. A figura seguinte ilustra aproximadamente esta "rede interna".

Este arranjo também muda de equipamento para equipamento. Tem casos onde a porta WAN está neste switch e eth1 não existe, outros a wireless é eth1 e assim por diante.

Como qualquer interface de rede no OpenWRT, a sua finalidade pode ser reajustada de acordo com a necessidade do administrador. Caso não fosse necessário a conexão com a Internet, como no caso de um access-point, a interface eth1 poderia ser anexada junto na interface LAN, operando como uma quinta porta local. Porém, o mais interessante não é juntar as interfaces mas sim, dividi-las.

Se seu roteador suportar o recurso de VLAN (olhe a coluna VLAN no site do OpenWRT), você poderá dividir estas portas em redes isoladas. VLAN é uma tecnologia de Virtualização de Redes Locais. Ela foi criada para que o isolamento entre duas redes pudesse ocorrer dentro de um switch e não exigir toda uma estrutura em paralelo. Assim, parte das portas de um switch podem pertencem a uma rede enquanto outras pertencem a uma segunda rede, sem comunicação entre elas. A troca de pacotes entre as redes é intermediada por um roteador, que pode controlar quem troca que pacotes com quem.

Dica: recomendo que as configurações do switch interno sejam feitas pela rede wireless, uma vez que esta não participa do switch. Assim, será mais difícil que uma mudança de configuração resulte em falta de conectividade.

Para configurar, vá para a configuração de rede, switch. Se não estiver habilitado, habilite o recurso de vlan. Você notará que já existe uma vlan 1 com todas as portas marcados como "não etiquetadas/not tagged". O que é esta etiqueta? Vou tentar explicar em poucas linhas.

VLAN são identificadas por um número único na rede local, chamado de VLAN ID. A VLAN padrão nos diversos equipamentos de rede no mercado é a de número 1. As outras, 2, 3, etc, são criadas de acordo com a necessidade do administrador.

As portas do switch podem estar em 2 estados básicos: pertencer a uma VLAN (estado "não etiquetado") ou não pertencer a uma VLAN (estado "desligado"). O primeiro, "não etiquetado", faz com que a porta envie e receba pacotes da VLAN correspondente. Cada porta pode estar presente em apenas uma VLAN para não misturar os tráfegos. Se selecionar para uma mesma porta duas VLANs como "não etiquetadas", a configuração não irá salvar e você receberá uma bela mensagem de erro. O outro estado, como o nome sugere, informa que esta porta está "desligada" da VLAN.

E quanto a esta "etiqueta"? A limitação de uma VLAN por porta não resolve todos os problemas. Porém, as VLANs não podem se "misturar" em uma mesma porta. Para resolver este problema, foi criada as etiquetas (tags) do protocolo 802.1Q. As etiquetas, nada mais são que um envelope envolvendo o pacote IP e informando de qual VLAN aquele pacote pertence. Assim, os pacotes da VLAN marcada como "etiquetado" recebem uma camada extra com o ID da VLAN de destino enquanto os "não etiquetado", onde a VLAN é chamada de VLAN nativa, são enviados normalmente pela rede.

Temos então 3 opções:

"desligado" significa porta não está naquela VLAN;
"não etiquetado" significa porta está naquela VLAN e somente nesta;
"etiquetado" significa porta está naquela VLAN mas todos os pacotes vindo desta ou destinados para ela serão envolvidos em um envelope.

Este "envelope" faz com que os sistemas operacionais e demais equipamentos de rede não reconheçam-no como um pacote IP normal. Contudo, tantos os switches e roteadores como os sistemas operacionais tem suporte, quando configurado, para interpretar estas etiquetas.

Vamos então a um exemplo simples onde 2 das quatro portas serão configuradas para uma outra rede. Ainda em rede, switch, crie uma nova VLAN. O número não importa muito, desde que seja único na rede. Nesta nova VLAN, marque a porta CPU como "etiquetado/tagged", e as portas 3 e 4 como "não etiquetado/not tagged". Como somente uma VLAN pode ter a porta como "não etiquetado", configure as portas 3 e 4 na VLAN 1 como "desligado". Aplique as configurações. Isto irá criar uma nova interface, eth0.2, onde 2 é o ID da VLAN. Ela pode ainda estar abaixada mas já vamos resolver isto. E a porta 5? Todas as configurações que eu fiz nela foram inócuas. Pela pesquisa que eu fiz, é uma porta de gerenciamento.

Agora precisamos criar uma nova interface para esta rede. Vá para "Rede" e "Interfaces" e adicione uma nova interface. Você irá notar que existe uma nova interface chamada de "Interface VLAN: "eth0.2"". Selecione ela e configure a sua nova interface como desejar. Só não esqueça de utilizar uma faixa de endereços independente das demais interfaces. Ajuste o firewall "a gosto".

Agora que já passamos pelo MultiWLAN e MultiLAN, no próximo artigo vou comentar como criar uma MultiWAN, com balancemento de carga e redundância entre diversas conexões com a Internet.

Até mais.

OpenWRT: turbine seu roteador! Multiplique suas redes: MultiWLAN

2012-01-27T23:38:00.001-02:00

Mais um artigo da série sobre o OpenWRT.

Um dos recursos mais úteis para ambientes corporativos é a possibilidade de multiplicar seu roteador com OpenWRT. A pedidos, neste artigo vou tratar o uso de múltiplas redes sem fio (MultiWLAN). Acho que vocês irão achar interessante. Em outros artigos na sequência, tratarei dos demais casos de "multiplicação de redes" como de múltiplas conexões com a Internet (MultiWAN) e múltiplas redes locais (MultiLAN).

Se seu roteador suportar (e a maioria suporta), você poderá criar diversas redes Wireless compartilhando o mesmo rádio. E para que serve isto? Bem, tive um problema recente na minha casa onde um computador visitante, com M$ Vista, não autenticava na minha rede WPA2/AES. Ele ganhava IP, enviava pacotes mas não os recebia. A solução mais "elegante" foi criar uma segunda rede Wireless com uma configuração de segurança diferenciada e um SSID próprio. E sim, WPA2/AES funcionou sem problemas quando usei um Linux LiveCD.

Outro caso que pode ser interessante é a utilização da rede Wireless para a conexão WAN. Não tem a rede aberta do vizinho que não pega muito bem? Pode usar um roteador Wireless para conectar como cliente da rede alheia ao mesmo tempo que você conecta normalmente na sua rede wireless local (mas não façam isto sem autorização, OK?). Para os casos mais avançados, poderia criar uma rede em malha, interligando diversos roteadores espalhados, como no caso de um condomínio, e difundir a Internet de um ponto central para todos os condôminos. Isto, ao mesmo tempo que os laptops continuam a conectar nos roteadores como se estes fossem roteadores "normais", conectados por cabo na Internet. Ainda não consegui reunir uma quantidade de roteadores significativa para realizar o teste da rede em malha (mesh), mas um dia chego lá.

Bem, tudo isto possui, eu diria, um "limitador". Todas as redes Wireless do seu roteador irão compartilhar as configurações de hardware como o canal e a potência. Afinal, mesmo com três antenas, você tem somente uma placa wireless. Contudo, acredito que não será um grande problema.

Agora a configuração: este é bem simples de ser feito. Pela interface Web, na configuração de rede, Wifi, clique em "Adicionar". A parte superior é a configuração do dispositivo, comum a todas as redes. A de baixo é a da sua rede, onde você pode escolher o modo, segurança, nome da rede Wireless, essas coisas. Uma configuração importante é a qual "interface" ela pertencerá. Não é a interface "Linux" tradicional mas as interfaces do OpenWRT, como já descrevi anteriormente (para os mais curiosos, a primeira interface wireless aparece como "wlan0" enquanto as demais ganham sufixos como "wlan0-1"). Você pode colocar esta rede como uma conexão LAN (ficando lado a lado com a rede local, assim como a rede wireless original) ou como uma conexão WAN (em conjunto com a interface já existente). Porém, o mais interessante são as configurações onde uma nova interface é criada.

O que eu vou colocar aqui é genérico e vale também para qualquer caso onde seja criado outras interfaces, como veremos em outro artigo sobre MultiLAN. Com a configuração de uma nova interface independente, você terá uma nova rede, com uma nova faixa de endereços IP, regras de firewall e tudo mais. Pode criar, por exemplo, um ambiente DMZ (zona desmilitarizada), com máquinas prestando serviços. Não confundir com o recurso DMZ dos roteadores wireless que apenas encaminham todas as requisições externas para um endereço IP interno que, para mim, não tem nada do conceito de "zona desmilitarizada". Está mais para "terra de ninguém".

Outra coisa interessante seria criar duas redes wireless. Uma rede segura, com somente máquinas "confiáveis", e com regras mais permissivas, e uma outra "de baixo escalão", para visitas indesejadas e máquinas Windows suspeitas. Pode também exercitar sua caridade "para com os outros" e criar uma rede "aberta", isolada das demais e fornecer acesso gratuito a quem conseguir alcançar seu roteador.

As redes são independentes e a comunicação entre elas é definida pelas regras do Firewall. Bem, mas isto é assunto longo e para outro artigo. Ainda preciso escrever este artigo sobre regras do Firewall...

Boa noite e bom hacking!

OpenWRT: turbine seu roteador! Customizando sua firmware

2012-01-25T23:30:00.000-02:00

Mais um artigo da série sobre o OpenWRT.

Em geral, a palavra "firmware" assusta as pessoas. Dá a impressão de algo imutável e complexo. Uma "firmware" ou "imagem", no caso do OpenWRT, nada mais é que uma imagem de um sistema operacional para dispositivos embarcados, similar às imagens feitas por um Ghost ou mesmo um dd. Claro, tudo isto dentro do formato esperado de cada dispositivo.

Mas por que alterar a "firmware" do OpenWRT? Um dos maiores problemas dos dispositivos embarcados é o limitado espaço em disco. 4MB é bem pouco para os mais sonhadores. Preciosos kbyte podem ser recuperados se você montar uma imagem que não contém algum pacote desnecessário. Se você é um feliz proprietário de um dispositivo com 8MB ou mais, parabéns, provavelmente este artigo não será útil para você. Instale a imagem padrão e posteriormente os demais pacotes desejados.

Então, tenho pouco espaço em disco. A estratégia é retirar tudo que eu conseguir, criando um a imagem enxuta, e instalar individualmente os pacotes após a gravação? Não, os arquivos presentes na ROM são mais econômicos do que os mesmos arquivos salvos na partição de alteração (overlay). O mais econômico é que, após selecionar os pacotes desejados, seja criada uma imagem com tudo pré-instalado, sempre deixando o espaço vazio para as configurações e para instalações não planejadas que, idealmente, serão embutidas em uma nova firmware para posterior gravação.

Outro bom motivo é a mais fácil reinstalação de um dispositivo ou a sua instalação em lote. Ao instalar o OpenWRT com a "firmware" padrão, os programas instalados anteriormente serão removidos. Colocando-os diretamente na "firmware", eles já estarão prontos logo após a nova instalação. Para o caso da instalação em lote, o mesmo vale para configurações padrão, que podem ser embutidas na firmware. Muito cuidado neste ponto pois o modo de emergência não irá ser útil caso a falha de configuração já estiver na firmware!

Pela característica de um projeto de Software Livre, tudo no OpenWRT é customizável. Basta baixar, alterar e recompilar. Porém, isto dá um pouco de trabalho. Para a customização dos pacotes instalados e de arquivos diversos, o OpenWRT desenvolveu o construtor de "firmwares" chamado ImageBuilder. Ele fica localizado no mesmo nível das "firmwares" no download do OpenWRT. No caso da arquitetura que tenho usado (ar71xx), seria este arquivo. É um arquivo tar.bz2 grande, aproximadamente 420MB contendo todos os pacotes do OpenWRT compilados para esta arquitetura e os scripts de construção de novas "firmwares".

Depois de descompactá-lo, entre no diretório criado e use o comando "make". "make help" irá dar algumas instruções de como usá-lo. Ah, o pacote de tradução do Português do Brasil pode ser colocado no subdiretório packages e os scripts irão achá-lo.

No meu ambiente, estou usando o seguinte comando:

make image PROFILE=TLWR740NV1 PACKAGES="luci-i18n-portuguese_brazilian ip6tables libiwinfo wpad-mini luci-app-wol luci-theme-openwrt uhttpd wol netstat-nat ifstat luci-theme-base luci-app-qos luci-app-upnp luci-app-firewall luci-app-ddns kmod-input-polldev -ppp -ppp-mod-pppoe aiccu radvd ddns-scripts libiptc resolveip luci-mod-admin-full libiwinfo-lua"

Ele gerará a imagem para o dispositivo "TLWR740NV1" e selecionará os pacotes necessário para o suporte IPv6, que comentei anteriormente, o programa netstat-nat, para mostrar as conexões do NAT, programas para o Wake-on-LAN (WOL), UPnP, scripts para serviços de DynDNS. O que eu retirei? Suporte a PPP. Para o meu caso onde o modem fornece o endereço IP por DHCP, ele é desnecessário (e bem grande). Com isto, você ainda terá 320 KBytes livres para configurações e outros pacotes. Para listas todos os PROFILES possíveis use:

make info

O PROFILE padrão é a geração de imagens para todos os "firmware", o que leva algum tempo. Porém, notei um problema com o construtor do OpenWRT: ele não respeita o parâmetro PROFILE. O patch do bugreport resolve o problema. Outra alternativa é esperar ele gerar as imagens até que a desejada esteja pronta e, então, o processo pode ser abortado (ctrl+c é suficiente). As imagens são geradas no subdiretório bin/<alvo>, e seguem o mesmo nome encontrado no download do site.

Depois de uma certa experiência, o administrador pode, inclusive, optar por não instalar a interface Web. Com isto, será preservado um bom espaço em disco, permitindo a instalação de muito mais programas, mesmo em um disco limitado. Que tal um servidor VPN? Um cliente VPN? Um relay TOR? Suporte a uma rede em malha (mesh)?

Boa sorte, pessoal!

OpenWRT: turbine seu roteador! Tradução para Português do Brasil

2012-01-22T17:57:00.000-02:00

Mais um artigo da série sobre o OpenWRT.

Nem sempre a língua Ianque é fluente para todos os administradores. As vezes, a tradução das mensagem ajuda, e muito! Outro caso onde a tradução pode ser fundamental é em um suporte remoto, quando um usuário leigo tem que ler o que ele está vendo. É bem complicado saber o que está acontecendo quando um usuário fala que apareceu a mensagem "uzer unconau". Seria mais fácil um "usuário desconhecido", não é?

Depois de instalar o OpenWRT, filtrando os pacotes por luci-i18n, você vai notar que existe traduções da interface WEB para diversas línguas, menos a nossa língua nativa: Português do Brasil ou pt_BR. Por quê? Bem, existe sim a tradução só que o sistema de construção dos pacote não o gerou.

De qualquer forma, pelo menos para o alvo ar71xx, eu compilei o pacote. Só baixar e instalar usando o comando opkg.

ssh root@router

cd /tmp

wget http://dl.dropbox.com/u/1286502/luci-i18n-portuguese_brazilian_0.10.0-1_ar71xx.ipk

opkg install luci-i18n-portuguese_brazilian_0.10.0-1_ar71xx.ipk

Depois, por padrão, se seu navegador optar preferencialmente por pt_br, uma atualização simples da página irá mostrar tudo em português.

Quem achar algo errado ou não traduzido, pode ficar a vontade para ajudar traduzindo a interface Web na página do projeto Luci. Preferencialmente, crie uma conta. Se precisar de alguma ajuda, também posso auxiliar neste ponto.

OpenWRT: turbine seu roteador! Configurando IPv6

2012-01-21T00:22:00.001-02:00

Mais um artigo da série sobre o OpenWRT.

Por muito tempo, eu usei um Asus EEE 4G, aquele de tela de 7', como meu roteador wireless. Isto concomitante com o uso como um computador pessoal. Era um roteador muito eficiente: suporte a IPv6 por túnel, firewall extremamente configurável, WPA2 e tudo que um Linux desktop oferecia. Foi suficiente para minhas necessidades até o dia que, indo para o novo apartamento, o modem e este computador não mais poderiam ficar juntos. Comprei um TP-WR740N.

Logo após a instalação do roteador TP-Link, comecei a recriar a infraestrutura que eu possuia quando o roteador era um dos laptops da casa: regras de firewall, dyndns.... Porém esbarrei em um ponto: IPv6. Como um estudioso do tema e entusiasta da tecnologia, gostaria de reestabelecer a conectividade IPv6 da minha rede local. Como tal recurso não estava presente no meu TP-Link, enviei uma mensagem para o suporte técnico. A resposta não foi nem um pouco animadora:

Dear sir\madam,

Thank you very much for your email requesting information about our product.

The TL-WR740N can not support IPv6 till now and we don’t have such a plan in the near future.

Sorry for any inconvenience.

Foi a senha para a instalação do OpenWRT.

Se quiser aprender sobre IPv6, recomendo o curso online gratuito em ipv6.br. Aprendi grande parte do que eu sei sobre IPv6 neste curso. Não é o meu objetivo ensinar IPv6 neste artigo.

Por questão de espaço em disco, o OpenWRT não vem com os pacotes para o suporte ao IPv6 por padrão. Porém, tendo espaço em disco livre, nada impede de instalá-lo. Os pacotes são kmod-ip6tables, ip6tables e kmod-ipv6. Você pode instalar pela interface Web ou pela linha de comando:

opkg update

opkg install kmod-ip6tables ip6tables kmod-ipv6

Isto instala apenas o suporte para o roteador atuar como cliente IPv6 e adiciona o suporte IPv6 ao firewall. A interface Web já tem suporte nativo para o IPv6.

OK, roteador com suporte a IPv6. O que eu preciso para ter acesso à Internet por IPv6? Infelizmente, são raríssimos os provedores de Internet brasileiros que fornecem conectividade por IPv6. Se for o seu caso, sinta-se feliz. Um dia eu espero que meu provedor (NET) forneça o roteamento IPv6. Enquanto isto não é verdade, vamos as alternativas.

A primeira é o 6to4. Neste estratégia, o seu endereço IPv4 é utilizado para compor uma rede IPv6 única. Os pacotes IPv6 que deixam seu roteador são envelopados em um pacote IPv4 e este é enviado a um endereço anycast. Com esperança, em algum ponto da rede, algum roteador terá a rota para um roteador com conectividade IPv6 que responda por este endereço. Este roteador é chamado de relay e, voluntariamente, se oferece como um tradutor dos dois mundos. Recebendo seu pacote, ele o extrai do IPv4 e o envia através da rede IPv6. A volta faz o trabalho inverso: o pacote IPv6 acha um roteador relay que empacota a resposta dentro de um pacote IPv4 e o envia para seu roteador. Esta foi a estratégia que eu utilizei por muito tempo. Porém, nem sempre seu pacote acha um roteador relay. Outro problema é que o caminho de ida e de volta, em geral, são completamente diferentes. Tive diversos problemas com esta forma de conectividade, inclusive com provedores explicitamente bloqueando estes pacotes. Não recomendo esta estratégia.

Por recomendação do Antônio M. Moreiras, em uma das minhas visitas ao FISL, adotei o uso de um túnel através da SixXS. SixXS é um projeto para prover conectivade IPv6 a quem quiser, através de pontos de presença voluntários. Felizmente, temos um destes PoP no Brasil! Obrigado CTBC! É a nossa única opção da América Latina. Os outros grandes provedores também poderiam oferecer um PoP com um baixíssimo custo... O SixXS também funciona diretamente no seu sistema operacional mas o foco aqui é no OpenWRT.

O cadastro no SixXs é gratuito. Você requisita uma conta e ganha alguns "créditos". Com eles, você pode solicitar um túnel. Para os felizardos que possuem um IPv4 fixo, pode ser solicitado um túnel para IPv4 fixo. Não é o meu caso. Minha conexão, como a da maioria das pessoas, é com um IPv4 real mas dinâmico. Por isto, criei um túnel do tipo "Dynamic IPv4 Endpoint using Heartbeat protocol". Neste caso, o programa aiccu estabelece uma conexão com o PoP e a mantém viva enviando periodicamente um sinal de vida. Para utilizá-la, instale o pacote aiccu:

opkg update

opkg install aiccu

Depois basta configurá-lo em /etc/config/aiccu. Nada muito complicado. O único grande requisito é que o relógio do roteador esteja atualizado. Bem, isto, por padrão, já é feito por NTP na imagem do OpenWRT. Dispare e ative o serviço (que pode também ser feito pela interface WEB).

/etc/init.d/aiccu enable

/etc/init.d/aiccu start

O resultado pode ser observado pelos logs (logread). Se tudo der certo, aparecerá uma nova interface no roteador como esta:

sixxs Link encap:IPv6-in-IPv4

inet6 addr: 2001:xxx:xxx:xxx::2/64 Scope:Global

inet6 addr: fe80::bd04:xxx/64 Scope:Link

inet6 addr: fe80::c0a8:xxx/64 Scope:Link

UP POINTOPOINT RUNNING NOARP MTU:1280 Metric:1

RX packets:2 errors:0 dropped:0 overruns:0 frame:0

TX packets:2 errors:0 dropped:0 overruns:0 carrier:0

collisions:0 txqueuelen:0

RX bytes:208 (208.0 B) TX bytes:208 (208.0 B)

Parabéns! Seu roteador já possui IPv6. Tente alcançar o ipv6.br:

root@router:~# ping6 ipv6.br

PING ipv6.br (2001:12ff:0:4::22): 56 data bytes

64 bytes from 2001:12ff:0:4::22: seq=0 ttl=56 time=73.889 ms

64 bytes from 2001:12ff:0:4::22: seq=1 ttl=56 time=71.613 ms

64 bytes from 2001:12ff:0:4::22: seq=2 ttl=56 time=71.309 ms

Se tudo correr bem, grande parte do trabalho estará feito. Contudo, o roteador ainda será apenas um cliente IPv6 (endpoint) e não um roteador IPv6 para o resto da rede. Pelo mecanismo de créditos do SixXS, ainda não é possível requisitar uma subrede.

A cada 2 semanas de conexão ativa, o SiXXs creditará 5 créditos. Então, por duas semanas, somente acompanhe para verificar que sua conexão está ativada. A transação típica de um novo usuário do SixXs é a seguinte:

Action	Cost	Description
Signup	25
Tunnel Request	-10
Tunnel Approve	-5
	10	Can't request a subnet, due to lower bound
Week uptime	5
	15	Can request a subnet
Subnet Request	-10
Subnet Approve	-4
Configure 1 NS	-1
	0	Out of credits, save some more in the coming weeks

Duas semanas mais tarde, e com 15 créditos, será o suficiente para requisitar a subrede. Requisite-a e a associe ao seu túnel existente. Na sua interface local do roteador (lan), adicione um IPv6 dentro da rede que o SixXS forneceu. Qualquer um. A parte legal do IPv6 é que, ao usar notação hexadecimal, você pode criar endereços fonéticos com partes como cafe, b0de, b0b0, fofa, ou até musicais: aeae:eeee:0000.

Agora, vamos precisar configurar e instalar mais algumas coisas no roteador.

Para ambientes pequenos, como o residencial, o mais indicado é o uso da configuração stateless do IPv6. Ela é automática, basta o roteador se anunciar na rede. O programa que realiza esta divulgação é o radvd. Instale-o.

opkg install radvd

Configure o radvd em /etc/config/radvd, ative e dispare o serviço, assim como foi feito para o aiccu. Uma das coisas interessantes do radvd é que ele também divulga a informação DNS pelo rdnss. Em geral é bom ativá-lo. O problema é que ele não funciona para sistemas M$. Para o Windows, adicione na rede lan do roteador um IPv6 extra: fec0:0:0:ffff::1/64. Não, o XP não irá funcionar pois o seu resolvedor DNS não suporta IPv6.

Ao ativar o radvd, é bom acompanhar pelo wireshark se aparece alguns pacotes do anúncio do roteador pela rede. Se seu sistema operacional for recente, é provável que ele ganhe um IPv6 instantaneamente e automaticamente. Se tudo correr bem, você terá conectividade com o ipv6.br.

$ ping6 ipv6.br
PING ipv6.br(ipv6.br) 56 data bytes
64 bytes from ipv6.br: icmp_seq=1 ttl=55 time=110 ms
64 bytes from ipv6.br: icmp_seq=2 ttl=55 time=107 ms
64 bytes from ipv6.br: icmp_seq=3 ttl=55 time=90.2 ms
64 bytes from ipv6.br: icmp_seq=4 ttl=55 time=72.0 ms

Acessar com um navegador o ipv6.br e ver o globo girando (e seu IPv6 no topo). Ou realizar o teste de conectivade IPv6. Eu consegui nota 10 no teste.

O firewall do OpenWRT precisa ser configurado assim como para o IPv4. A configuração padrão dará uma segurança similar ao IPv4 com NAT. Em geral, é desejável abrir os serviços que seus computadores externos irão receber conexões, como o torrent. Mais adiante eu faço um artigo sobre o firewall.

A partir deste ponto, tudo é opcional.

Todos os servidores DNS que estão configurados no roteador devem ser IPv4. Ex:

# cat /tmp/resolv.conf.auto
nameserver 189.4.64.87
nameserver 189.4.64.82

Enquanto existir IPv4, isto não é problema algum (e vai existir por muito, muito tempo). Porém, para ganhar o décimo ponto no teste IPv6, você precisa ter um servidor DNS IPv6. O SixXS fornece alguns servidores DNS IPv6 como este: 2001:4de0:1000:a3::2. Adicione-o na interface sixxs (pode ser pela interface WEB) e crie este script:

/etc/hotplug.d/iface/60-aiccu-dns.sh

#!/bin/sh

# Add dns configured in aiccu interface

source /etc/functions.sh

config_load aiccu

for cfgs_section in $CONFIG_SECTIONS; do

config_get aiccu_iface $cfgs_section interface

if [ "$INTERFACE" == "$aiccu_iface" ]; then

source /lib/network/config.sh

config_load "network"

config_get "dns" "$INTERFACE" "dns"

if [ "$dns" ]; then

case "$ACTION" in

ifup)

# Add DNS from aiccu interface

add_dns "$INTERFACE" "$dns"

;;

ifdown)

# Remove DNS from aiccu interface

remove_dns "$INTERFACE" "$dns"

;;

esac

done

Isto adicionará o dns da interface sixxs aos servidores dns disponíveis quando a interface for levantada. Ele irá aparecer no arquivo /tmp/resolv.conf.auto. Por padrão, o dnsmasq consulta a cada requisição todos os servidores dns configurados.

Só um aviso: este roteador retorna IPv6 para alguns sites como o google.com. Então, na rara situação onde a resposta do servidor DNS IPv6 chegar antes dos demais, você irá acessar o GMail por IPv6. Será um pouco mais lento pela latência do túnel mas é extremamente raro de acontecer.

OpenWRT: turbine seu roteador! Administrando o OpenWRT

2012-01-14T00:54:00.001-02:00

Mais um artigo da série sobre o OpenWRT.

Quando instalado, o OpenWRT vem com uma configuração bem simples:

A rede sem fio está desligada. Use, por enquanto, o cabo de rede;
O usuário administrador "root" não possui senha. Deve ser a primeira coisa a ser resolvida;
O acesso por telnet está liberado. Mais adiante, este acesso não é mais necessário (por ser inseguro) e é substituído pelo SSH;
A interface LAN (as portas e a sem fio) estarão juntas (bridge) e esta estará configurada com o endereço 192.168.1.1/24;
Um servidor DHCP irá fornecer endereços para a rede LAN;
O equipamento estará configurado para utilizar servidores NTP do projeto para ajustar a hora;
As regras do firewall irão bloquear tudo que não seja ICMP vindo de fora. Os acessos de dentro da rede para fora não sofrem influência.

A primeira coisa a ser feita é a configuração de uma senha. Use uma boa senha. Pelo que observo nos logs do meu firewall, é comum ataques em massa vindos da Internet. Não precisa ser nada de 15 caracteres, letras maiúsculas e minúsculas, números e símbolos. Porém, nada de admin ou 12345678. O próximo passo é o ajuste das configurações de rede.

Durante a configuração do OpenWRT, não vemos as usuais interfaces do Linux (eth1, wlan0,...). O que encontramos são interfaces de "mais alto nível" como LAN e WAN. Estas interfaces podem ser mapeadas diretamente para uma única interface do roteador (agora sim eth0, etc) ou agrupá-las em uma bridge. Por padrão, existem duas interfaces: WAN (Wide area network) e a LAN (Local area network). A WAN normalmente é composta apenas de uma interface (eth1), normalmente destacada das demais portas, utilizada para a conexão com a Internet. A LAN é uma bridge que junta a eth0 (portas da rede local) e a interface wireless (wlan0). Em geral, não é alterada a rede LAN e a WAN opera configurada por DHCP, PPPoE, dependendo do seu provedor.

OK, até agora como qualquer roteador. Porém, agora entra a flexibilidade do OpenWRT. As funções das interfaces podem ser alteradas, alternadas, agregadas ou divididas como o administrador desejar. A interface wlan0 pode se juntar com a WAN, as portas da LAN serem usadas para conexões diversas com a Internet ou juntar tudo e tornar o roteador um simples ponto de acesso (access-point) sem qualquer roteamento. Alguém pode perguntar: "mas as portas da rede local, aquelas 4, são mapeadas para uma única interface, a eth0?". Sim, são. Mas isto não é um limitador. Apesar de, por padrão, estarem juntas, as portas, se o HW permitir, podem ser isoladas em diversas redes, enviar pacotes com tags de VLANs e assim por diante. Porém, isto é um tema para um artigo isolado.

Para os roteadores wireless, é provavel que o desejo seja ativar o rádio. Isto é feito na configuração Wifi. SSID, criptografia (WPA ou WPA2, por favor. Esqueça que WEP existe), uma senha razoável, potência, canal, tudo isto que já encontramos em todos os firmwares. Vou focar nas diferenças: modo de operação. Existe uma boa gama de opções do modo de operação desde o clássico "AP", passando pelo simplório Ad-hoc e por coisas mais interessantes como redes Mesh (802.11s), WDS cliente ou servidor, ou até mesmo se comportando como um cliente wireless comum, conectando-se a outro roteador Wireless. Há também o modo "monitor", para realizar captura de pacotes wireless. Passando rapidamente, outra coisa interessante pode não ser notada. Na configuração do Wifi, existe um botão para "Adicionar". Adicionar o quê? Outra configuração wireless. Se o HW permitir, e normalmente permite, você pode ter múltiplas configurações de rede sem fio, operando em modos diferentes, com senhas diferentes, com SSID diferentes, cada uma representando uma interface. Vou tentar fazer um artigo somente sobre casos interessantes de uso da rede sem fio múltipla.

O acompanhamento do desempenho do roteador é muito próximo ao encontrado em um computador com Linux. Pode-se usar o top, ifconfig, free, df, etc. A interface provê todas estas informações de uma forma amigável, com gráficos em tempo real e alguma gerência como matar um processo. Vale a pena olhar. Ainda pela WEB, é possível configurar tarefas agendadas na cron, ativar/desativar e iniciar/parar serviços. Tudo simples e fácil.

Para ver se o roteador está "aguentando" a carga, observe valor da carga média (loadavg). São 3 valores com a média (respectivamente, média de 1, 5, 15 minutos) do tamanho da fila de processos querendo usar a CPU. Como regra geral, quando este valor estiver abaixo de 1, tudo certo. Quer dizer que ninguém ficou "esperando na fila". Se subir, pode ser muita carga ou problemas de HW. É bom avisar que, enquanto está sendo operada, a interface WEB usa bastante CPU. Memória normalmente sobra. Se ela faltar, coisas estranhas e aleatórias irão acontecer. O gráfico da rede também é muito legal, observando em tempo real se o seu provedor está entregando o que realmente foi contratado. Por fim, o disco só irá ser importante para a instalação de pacotes. Não é esperado que seja necessário reiniciar o roteador, por qualquer motivo que seja. No meu caso, ele fica ligado por meses sem qualquer degradação do desempenho. Só é desligado/reiniciado em caso de falta de energia, viagem ou atualização de firmware.

A lista de pacotes é bem vasta. Os novatos podem facilmente se perderem nas milhares de alternativas. A lista inclui desde pacotes clássicos, como nmap, socat, iftop, módulos de kernel ou programas específicos para roteadores. A limitação, como já comentei anteriormente, será seu espaço em disco. No meu caso, gastei quase todo o meu espaço livre para configurar IPv6, com SW do túnel, divulgação de roteador e demais detalhes. Para os iniciantes, observe os pacotes luci. Eles adicionam recursos à interface e, por dependência, instalam os programas necessários. Algum mais usados são luci-app-multiwan, para balancear entre múltiplas conexões com a Internet, luci-app-openvpn para configurar uma VPN, luci-app-upnp para criar encaminhamento de portas automaticamente (útil para Skype, Torrent e outros), luci-app-qos, para regras de qualidade de serviço.

O OpenWRT possui mecanismo para salvar as configurações em um arquivo de backup. Contudo, ele não é suficiente para todos os casos. Em primeiro lugar, na eventual instalação de um novo firmware, todos os programas instalados após a gravação da firmware anterior sumirão. Será necessário reinstalá-los. Em relação as configurações, existe uma lista de arquivos a serem preservados. Alguns como /etc/pass ou /etc/config/* são automaticamente mantidos. Outros, principalmente de pacotes sem interface WEB, precisam que seus arquivos de configurações sejam relacionados em /etc/sysupgrade.conf, ou pela interface WEB. Recomendo que todo o conteúdo de /overlay seja também mantido enquanto ainda existir dúvidas se todos os arquivos estão listados para o backup.

A atualização da versão do OpenWRT é simples. Baixe a versão da firmware sysupgrade desejada e solicite a gravação. É possível solicitar a manutenção das configurações. Porém, isto é similar a gerar um backup e restaurá-lo. É importante lembrar que, como comentado no parágrafo anterior, nem tudo será mantido.

O diagnóstico de problemas é feito em grande parte olhando os logs. Existe o log do kernel (dmesg), o log do sistema (logread), que contém o do kernel e, possívelmente, logs de programas em /var/log/. A grande maioria dos programas usa somente o log do sistema e a criação de logs próprios é rara. Como o conteúdo do dmesg está contido no syslog, normalmente somente o logread é necessário. O logread é a ferramenta para ler o conteúdo do log do sistema. Este conteúdo pode ser acessado pela interface WEB ou por uma console. A opção "-f" faz com que o log seja "seguido", mostrando o conteúdo a medida que ele é gerado.

Bem, fiz algum configuração e agora não consigo acessar meu roteador. O que eu faço? Aperta o reset? Não vai funcionar. Jogo ele fora? Ainda não. Se o problema for apenas configuração ou alguma alteração de disco após a instalação do firmware, a recuperação é tranquila. O botão de reset do roteador é apenas um botão, que pode ser aproveitado para diversas finalidades, assim como, no meu caso, o QSS. Porém, durante o boot, ele tem uma função especial. Durante o processo de boot, o roteador envia um pacote UDP pela rede cabeada da LAN com um aviso parecido como, "Se quiser entrar no modo de emergência, aperte o reset agora!". Rapidamente aperte o botão reset. Com isto, todas as alterações feitas no disco, sendo elas instalação de pacotes, remoção de arquivos ou configurações serão ignoradas. Elas não serão removidas, apenas ignoradas. Realize os ajustes necessários e reinicie o equipamento. Mas como eu vou ver este pacote? Para os mais interessados, use um sniffer de rede (wireshark). Os mais preguiçosos, que é uma qualidade na computação, podem esperar o primeiro pacote recebido pela rede vindo do roteador. O aviso será o primeiro pacote.

Para os corajosos, boa sorte! Se precisarem de alguma ajuda, vou tentar fazer o possível. Devo falar sobre a criação de uma firmware customizada no próximo artigo.

OpenWRT: turbine seu roteador! Instalando o OpenWRT

2012-01-13T22:42:00.001-02:00

Antes de mais nada, façam a instalação por sua conta e risco! Eu utilizo o OpenWRT faz algum tempo, já tive problemas de configuração, já corrompi a flash (com firmware experimental). Posso tentar ajudar em alguma coisa mas não tenho como dar garantias.

A instalação do OpenWRT é ligeiramente tranquila. Primeiramente, descubra se o seu roteador possui suporte e a partir de qual versão (coluna "status"). Considerando que ele tem suporte, observe a plataforma alvo (coluna "target"). Os Tp-Link com suporte são todos para o alvo ar71xx. A última versão lançada no final de dezembro de 2011 é a backfire 10.03.1 (Nota: O nome da distribuição vem de drinks e sua receita é mostrada quando o usuário loga na console). Não recomendo experimentar com firmwares não finais. Os RC são relativamente seguros mas sempre podem apresentar algum problema. Usar a versão em desenvolvimento (trunk) é ainda mais arriscado. Vai do perfil de cada um. Com tudo isto em mãos, vá para a parte de download.

Busque o modelo do seu roteador. No meu caso, é o TL-WR740N. Existem dois arquivos para este modelo:

http://downloads.openwrt.org/backfire/10.03.1/ar71xx/openwrt-ar71xx-tl-wr740n-v1-squashfs-factory.bin
http://downloads.openwrt.org/backfire/10.03.1/ar71xx/openwrt-ar71xx-tl-wr740n-v1-squashfs-sysupgrade.bin

Destaquei algumas coisas no caminho do arquivo. "backfire" é o nome dado ao OpenWRT versão 10. "10.03.1" é a última versão estável lançada (também existem versões anteriores e RC mais antigos). "ar71xx" é a arquitetura alvo, também presente no nome do arquivo. "tl-wr740n" é o modelo do roteador wireless. "v1" é a versão do hardware e pode ser fundamental. Em seguida aparece "squashfs" que representa o formato do disco. Por fim, o que difere os dois arquivos, é a descrição "factory" e "sysupgrade". O "factory" é utilizado somente para a primeira instalação, onde o firmware do fabricante está rodando e o administrador deseja instalar o OpenWRT. Depois da primeira instalação, somente o "sysupgrade" será utilizado.

Para o modelo de exemplo, não existe alternativa do formato do disco. Contudo, para outros, pode existir a alternativa entre o "squashfs" e o "jffs2". O OpenWRT geralmente é utilizado com os arquivos na flash formatados como squashfs (somente leitura) + área de alterações. Quando um arquivo original do firmware é removido no squashfs, ele não libera espaço. Pelo contrário, ao removê-lo, é criado um arquivo de controle extra no espaço de alteração para marcar o arquivo removido e ocultá-lo da raiz, mas ele jamais deixa de existir na ROM e não libera espaço. Já na estrutura "jffs2", não existe área ROM e todos os arquivos são "apagáveis". Porém, isto "permite" que o administrador remova algo importante e faça com que o roteador não ligue mais que, no jargão da área, é chamado de bricked. Com o formato "jffs2", não existe modo de emergência ou recuperação. A recuperação somente é possível interagindo com o gerenciador de boot (serial ou tftp, quando possível) ou dessoldando a flash da placa e gravando externamente. Recomendo fortemente que seja usado exclusivamente o "squashfs". Pode também existir variações do tamanho da flash para um mesmo modelo. Porém isto é um caso raro ou fruto de algum hack de hardware.

Atenção: Antes de qualquer coisa, leia toda a documentação do modelo do roteador na Wiki do OpenWRT. As vezes alguma informação ou instrução peculiar pode ser necessária antes da instalação.

Dica: Se o roteador for a sua única forma de acesso à Internet, baixe toda a documentação necessária. Preferencialmente, não dependa do roteador para acesso à Internet durante o procedimento de instalação. Tenha uma alternativa nem que seja acesso discado.

Com o arquivo baixado da versão "factory", proceda a instalação do firmware como se este fosse um firmware fornecido pelo fabricando do equipamento. Após a gravação, o OpenWRT estará rodando!

Por padrão, ele estará rodando como 192.168.1.1, máscara 255.255.255.0. Conecte por um cabo de rede ou pela rede sem fio, abra um navegador para http://192.168.1.1 e configure o novo sistema.

OpenWRT: turbine seu roteador! Sobre o OpenWRT

2012-01-08T20:14:00.001-02:00

Mais um artigo da série sobre o OpenWRT.

O OpenWRT é uma distribuição Linux para dispositivos embarcados, como roteadores, funcionado como substituto aos firmwares originais do fabricante. É fruto do código-fonte do firmware da Linksys, baseado em Linux, e publicado sobre a licença GPL.

Com o controle sobre o firmware, o administrador pode explorar todos os recursos do hardware. Pode aproveitar uma porta USB para criar um servidor de impressão. Pode utilizar a wireless como cliente, como uma rede mesh, como ad-hoc ou um access-point (ou tudo isto ao mesmo tempo se o hardware suportar). Queria aproveitar o botão de QSS, que não serve para muita coisa, para algo diferente como desligar a wireless, mudar a potência do sinal? Enfim, se o hardware permite, o software deixa de ser o limitador. Ainda mais se quiser meter a mão em um pouco de shell script ou lua.

Diferentemente da imobilidade dos firwmare originais, o OpenWRT é extremamente expansível. Assim como as distribuições Linux, ele trabalha com pacotes. Os programas, serviços podem ser baixados e instalados, ajustando os recursos disponíveis a necessidade do usuário. A lista de pacotes prontos é extensa. O firmware padrão traz acesso ao roteador por Telnet, por SSH e por uma interface WEB avançada. A interface WEB é suficiente para atender as necessidades da grande maioria dos usuários, mesmo muitos usuários avançados. Para os casos omissos, as configurações podem ser feitas pela console (Telnet, SSH ou mesmo a serial). A documentação na Wiki contempla muitos cenários desde a instalação, recuperação, configurações e hacks. O fórum também é um lugar interessante para pesquisar informações. Os softwares empacotados no OpenWRT são, em geral, os mesmos encontrados nas distribuições Linux, mas com alguns ajustes e compilados para o dispositivo. Então, se precisar de ajuda, a própria documentação padrão do software, quando rodando em um PC, deve se aplicar. E, se tudo mais falhar, ainda pode dar uma olhada no código-fonte. Afinal, tudo no OpenWRT possui código-fonte aberto.

A estrutura do disco difere do que encontramos nas formatações dos discos de um computador. Não existe uma tabela de partição, MBR. Porém, algumas coisas têm sua posição definida. Além disto, podem existir variações em função do fabricante. Existe uma vasta lista de dispositivos descritos na Wiki do OpenWRT que explicam melhor como está organizado o disco de cada equipamento. Vou descrever um exemplo geral:

O início do disco contém o gerenciador de boot. Este pode ser o U-boot, Redboot ou outro qualquer (em geral, os mesmos encontrados em celulares). Na sequência vem o firmware com o kernel, programas e dados e, por fim, em geral uma partição proprietária para configuração ou dados de hardware. A tabela abaixo mostra o layout da flash para o modelo TP-Link WR1043ND encontrado na wiki do openwrt.

TP-Link WR1043ND Flash Layout
Layer0	m25p80 spi0.0: m25p64 8192KiB
Layer1	mtd0 *u-boot* 128KiB	mtd5 *firmware* 8000KiB			mtd4 *art* 64KiB
Layer2		mtd1 *kernel* 1280KiB	mtd2 *rootfs* 6720KiB
mountpoint			`/`
filesystem			mini_fo
Layer3				mtd3 *rootfs_data* 5184KiB
Size in KiB	128KiB	1280KiB	1536KiB	5184KiB	64KiB
Name	*u-boot*	*kernel*		*rootfs_data*	*art*
mountpoint	none	none	`/rom`	`/overlay`	none
filesystem	none	none	SquashFS	JFFS2	none

O gerenciador de boot é capaz de carregar o firmware de diversas fontes como um servidor TFTP, através da serial ou, como é o usual, da própria memória flash. A interação com o gerenciador de boot normalmente só é possível através da serial ou reconfigurando alguma de suas variáveis ambientes. A operação padrão do gerenciador de boot é carregar o firmware da memória flash e executá-lo.

O firmware é dividido em partes. A primeira parte é composta do kernel Linux do sistema, que possui tamanho variável em função da arquitetura e módulos embutidos. Só para destacar, não existe um arquivo em um sistema de arquivos contendo o kernel, como em um computador. Ele apenas está na posição imediatamente após o gerenciador de boot. Após a sua carga, o kernel busca a raiz do sistema na posição seguinte ao local onde o kernel está armazenado.

A raiz do sistema usa o squashfs, também utilizado em alguns LiveCDs e terminais leves. É uma imagem ROM (somente leitura) e compactada, para economizar o escasso recurso de disco. No caso de um LiveCD, qualquer alteração ao disco é armazenada na memória e perdida ao desligar o computador. No caso do OpenWRT, estas alterações ficam no espaço livre restante após a ROM do squashfs e antes da partição proprietária. Isto é transparente do ponto de vista do administrador. Qualquer parte do disco pode ser alterada. Porém, somente os arquivos alterados serão armazenados na região rootfs_data. Com isto, diferentemente do LiveCD, as alterações serão preservadas.

A estrutura do sistema de arquivos é muito próxima ao encontrado em qualquer unix:

drwxr-xr-x 2 1024 Dec 21 11:10 bin
drwxr-xr-x 5 2060 Jan 8 18:15 dev
drwxr-xr-x 12 1024 Jan 8 18:15 etc
drwxr-xr-x 12 1024 Nov 18 16:23 lib
drwx------ 2 2515968 Dec 21 11:13 lost+found
drwxr-xr-x 2 1024 Dec 21 10:30 mnt
drwxr-xr-x 2 1024 Dec 21 10:30 overlay
dr-xr-xr-x 45 0 Jan 8 18:15 proc
drwxr-xr-x 2 1024 Dec 21 11:09 rom
drwxr-xr-x 2 1024 Dec 21 10:30 root
drwxr-xr-x 2 1024 Dec 21 11:10 sbin
drwxr-xr-x 12 0 Jan 8 18:15 sys
drwxrwxrwt 12 360 Jan 8 19:46 tmp
drwxr-xr-x 6 1024 Nov 18 16:23 usr
lrwxrwxrwx 1 4 Dec 21 11:09 var -> /tmp
drwxr-xr-x 4 1024 Dec 21 10:39 www

Alguns diretórios diferentes podem chamar a atenção. O "rom" aponta para a imagem squashfs original e somente leitura. Se precisar restaurar algum arquivo para o seu original, ele pode ser obtido neste diretório. O "overlay" aponta para a região da flash onde as diferenças estão armazenadas. Não tente alterar os arquivos diretamente neste local. O formato é simples mas específico. Porém, ele serve como um bom local para descobrir onde foi parar aquele espaço livre que você tinha e desapareceu. Também mostra o que foi alterado no disco.

Uma das vantagens desta escolha de estrutura com uma imagem fixa, rom, e as alteracões é que a restauração ao firmware é extremamente simplificada: basta não ler as alterações presentes na "overlay". Mais adiante eu comento como recuperar um roteador após uma mudança que o deixe inacessível.

O diretório "tmp" está montado em uma tmpfs, que é um disco em memória RAM. Em geral, até metade da memória pode ser utilizada para este fim. Neste local ficam os logs, arquivos temporários e demais informações voláteis que serão perdidas quando o sistema for reiniciado. O "var" é apenas um link simbólico para o "tmp".

O "etc" contém arquivos usuais de configuração de um Linux e um diretório "config" específico de configurações do OpenWRT. O "/etc/config" contém arquivos texto com configurações em um formato padrão do OpenWRT. Geralmente, a interface WEB altera apenas estes arquivos presentes no diretório "config". Este é um exemplo de um arquivo de configuração:

config system
option hostname OpenWrt
option timezone UTC
config timeserver ntp
list server 0.openwrt.pool.ntp.org
list server 1.openwrt.pool.ntp.org
list server 2.openwrt.pool.ntp.org
list server 3.openwrt.pool.ntp.org

É comum que os scripts de gerenciamento dos serviços leiam as definições nestes arquivos e, a partir destas, gerem em "/tmp" a configuração do programa a ser executado.

Grande parte dos programas não cria seus próprios arquivos de logs e utilizam o serviço de log do sistema. Os logs do OpenWRT podem ser acessados pelo comando logread.

Jan 8 19:24:24 OpenWrt user.notice ifup: Enabling Router Solicitations on loopback (lo)Jan 8 19:24:24 OpenWrt user.info kernel: eth0: link up, 100Mbps, full-duplex

O formato é o que já encontramos em outros Unix.

Bem, agora podemos partir para a instalação.

OpenWRT: turbine seu roteador! Escolhendo o Hardware

2012-01-08T18:45:00.001-02:00

Com o recente lançamento do OpenWRT 10.03.1 e como seu usuário, resolvi compartilhar algumas experiências por aqui. Este é um primeiro artigo de uma série de outros sobre o assunto.

Em geral, enquanto configurava alguns roteadores wireless residenciais, eu me sentia um pouco frustado. Os firmwares originais dos roteadores são limitados quanto as funcionalidades disponível. É fácil entender isto quando levamos em consideração que o fabricante precisa desenvolver, além do hardware, todo o sistema operacional que será executado, com pilha de rede, servidor http, ssh, telnet, syslog. Foi assim até o dia que eu precisei comprar um roteador wireless para uso pessoal.

Já conhecendo o que me esperava dos firmwares originais, procurei um modelo que fosse compatível alguma coisa alternativa baseada em Linux. Em geral, se funciona com um dos alternativos, será possível fazer funcionar com qualquer outro. Pelo custo/benefício, encontrei o modelo Tp-Link TL-WR740N. Era o mais barato que eu achei. Pesquisando um pouco, você vai descobrir os componentes de qualquer roteador wireless são de poucos fabricantes como Broadcom, Atheros, Ralink, Texas, Ubicom. As vezes, para um mesmo modelo, o fabricante troca o chipset em uma nova versão de hardware. Por isto, dois equipamentos de mesmo modelo/fabricante podem ter desempenho muito diferente. A D-Link, por exemplo, trocou o chipset de Atheros para Ralink em boa parte dos modelos DIR quando passou da revisão de hardware A para B.

Bem, no meu caso, o TL-WR740N possui configurações bem espartanas:

Processador Atheros 400Mhz
4 MB de disco
32 MB de RAM
Rede b/g/n
1 antena não removível
4+1 portas FastEthernet (100Mbit)

Para quem está acostumado com "gigas", a volta aos "megas" pode assustar um pouco mas, em geral, é suficiente para o trabalho. É possível realizar melhorias na especificação fazendo alguns "hardware hacks". Este modelo possui pinagem no chipset para uma porta USB 1.1. Também possui uma porta serial com circuitarem não concluída para a casos de emergência. Outros mais radicais chegam a trocar os chips de memória flash e RAM, soldados na placa. Sugiro não contar com estes recursos latentes e, se realmente desejar, compre um modelo que os forneça naturalmente. Durante os testes com firmwares experimentais, tive que soldar a serial e não foi uma atividade divertida.

Ao longo do uso do OpenWRT, notei que eu poderia aproveitá-lo melhor se tivesse algumas coisas a mais na especificação do equipamento. O primeiro ponto que eu melhoraria seria o espaço em disco. 4 MB faz você trabalhar no extremo do limite, literalmente contando os KBytes restantes. Sugiro algo como 8MB. Caso esteja disponível uma porta USB, um pendrive pode ser utilizado como disco mas isto vai tornar seu ambiente mais complexo. Falando nela, uma porta USB é uma grande coisa. Você pode utilizá-la para qualquer finalidade que use USB: modem 3g, pendrive, disco externo, impressora, webcam, placa de som, ventilador...(desde que não use muita corrente). A porta USB torna o roteador muito mais versátil. Os 32 MB de memória RAM é suficiente para os casos normais mas, se for utilizar muitos serviços extras, pode ser necessário mais memória ou utilizar um espaço para swap. No caso da swap, sugiro que seja utilizado um pendrive ou disco externo pela USB. E claro, como qualquer memória virtual, o sistema deve perder desempenho. Eu pessoalmente não utilizo as portas Ethernet da Lan. Se o roteador for utilizado para conectar mais de um computador por cabo, eu optaria por modelos GigaEthernet. Em relação as antenas, uma e fixa é suficiente para mim. Se precisar de uma antena maior, compre as destacáveis. Se precisar de maior alcance e mais banda, compre os modelos com múltiplas antenas.

Conhecendo a disponibilidade de equipamentos no nosso mercado nacional, minha sugestão de compra atual é o modelo Tp-Link TL-WR1043ND.

Processador Atheros 400Mhz
8 MB de disco
32 MB de RAM
Rede b/g/n
3 antena destacáveis
4+1 portas GigaEthernet (1000Mbit)
Porta USB 2.0
Porta serial facilmente soldável

Existe novos modelos da Tp-Link que ainda não chegaram no nosso mercado que parecem promissores. Fica a dica, para evitar problemas, observar a tabela de compatibilidade do OpenWRT e atentar para a versão do Hardware suportada e a versão mínima do OpenWRT suportada. Cuidado que na mesma página existem as listagem dos modelos compatíveis, dos possivelmente compatíveis e dos não compatíveis.

O próximo artigo será sobre a estrutura interna do OpenWRT.

Atendimento Eletrônico da Anatel com suporte para Firefox

2011-12-08T10:38:00.001-02:00

Quem tentou usar no passado o atendimento eletrônico da Anatel a partir do Linux provavelmente esbarrou na limitação da aplicação que somente funcionava em Internet Explorer. Para usuários M$ Windows, era somente o caso de trocar o navegador enquanto para os usuários Linux, a solução possível seria extremamente exótica (como rodar o IE no wine).

Bem, era extremamente frustrante que, após não resolver o problema com a Telecom (por sinal, no meu caso, era a Oi), você não consiga nem mesmo reclamar com a Anatel. Como eu estava realmente indignado, resolvi ir ao limite para tentar sanar o problema. Inicialmente, o primeiro passo seria entrar em contato com a Ouvidoria da Anatel e informar do problema. Para a minha surpresa, até mesmo a ouvidoria usava o mesmo sistema do atendimento eletrônico! E, para ajudar, não achei, na época, outra forma de contato que não seja o telefônico. Para utilizar o meio eletrônico, eu teria que "subir o nível".

Pensei no Ministério das Telecomunicações. Contudo, estudando um pouco, encontrei que a "...a agência tem independência administrativa e financeira e não está subordinada a nenhum órgão de governo". Investigando mais um pouco, cheguei em alguém que poderia me ajudar: Controladoria Geral da União (CGU).

Entrando na página da controladoria, consegui facilmente relatar o problema encontrado. Os argumentos foram simples. A exigência do uso do IE daria privilégios a uma empresa (Micro$oft) sem qualquer motivo ou concorrência pública. Para usar legalmente o sistema da Anatel, eu teria que comprar uma licença do produto, ou utilizar uma cópia ilegal, que seria "contra a lei". Isto estaria restringindo os direitos de cidadão dos não clientes da Microsoft. Além de tudo, a limitação não teria qualquer justificativa pois existem outros navegadores de alta qualidade no mercado (que inclusive são mais usados do que o IE), compatíveis com diversos sistemas operacionais, além da compatibilidade com a crescente onda dos dispositivos móveis. Por fim, ainda o uso de recursos limitadores fora dos padrões vai contra a orientação do Padrões de Interoperabilidade de Governo Eletrônico (E-ping). Para quem não conhece, o E-ping define diversas normativas de soluções de TI para o Governo como protocolos e formatos de documentos, inclusive adotando o ODT. É de caráter obrigatório para o Poder Executivo mas o Judiciário também aderiu voluntariamente.

Em pouco tempo, recebi por e-mail a resposta da CGU:

Prezado Senhor,

                        Acuso o recebimento da manifestação em referência, originada de correspondência eletrônica em que Vossa Senhoria reclama sobre a restrição de acesso ao atendimento eletrônico da Agência Nacional de Telecomunicações/ANATEL que exigiria do usuário a utilização de determinado navegador de internet para utilização dos seus serviços.

2.                     Considerando a natureza da matéria ali abordada, informo que sua manifestação foi enviada, nesta data, à ouvidoria daquela Agência para conhecimento, providências e oportuna comunicação com Vossa Senhoria, bem como à Secretaria-Executiva do Governo Eletrônico, a título de colaboração na implementação do programa.

                        Atenciosamente,

RICARDO GARCIA FRANÇA

Assessor do Ouvidor-Geral da União

Alguns meses se passaram e, algumas semanas atrás, testei novamente o sistema utilizando o navegador Google Chrome. Para minha surpresa, consegui avançar em muito em relação às limitações que eu enfrentei no passado. Porém, ainda assim não conclui um cadastro pois existe algum problema com a consulta do CEP. Poucos dias depois, recebo a tão aguardada resposta da Anatel:

Prezado Sr. Luiz Ângelo Daros de Luca,

1.          Em atenção ao Ofício nº 21531/2011/OGU/CGU-PR, encaminhado à Anatel e recebido no dia 05 de agosto de 2011, referente à sua reclamação de restrição de acesso ao sistema FOCUS, informamos que já se encontram em produção desde o dia 13 de outubro as alterações inerentes a cadastro de entidade externa com compatibilidade com os navegadores Mozilla Firefox e Microsoft Internet Explorer. Tais alterações visaram aprimorar os processos de atendimento eletrônico da ANATEL, e aproveitamos para agradecer o contato.

2.          Informamos ainda que estamos trabalhando em outras alterações visando compatibilizar o acesso ao atendimento com o navegador Google Chrome, com previsão de conclusão para o dia 9 de dezembro próximo.

3.          Informamos também que o tratamento relativo ao Sr. Evandro de Andrade Bastos, referente à mudança de plano e aparelho já foi encaminhada à área competente e terá o devido retorno.

4.          Pedimos desculpas pelo inconveniente causado e nos colocamos a disposição para quaisquer esclarecimentos.

Bingo! O problema foi solucionado! Testei o cadastro com o Mozilla Firefox e tudo funcionou sem qualquer problemas. O problema que eu enfrentei com o Google Chrome já é conhecido e, segundo a resposta, já estão trabalhando na solução. De qualquer maneira, dou-me por satisfeito com a opção do Firefox.

Fica a lição de que "reclamar resolve". Mas não com os seus colegas. Reclamem com os tomadores de decisão da instituição, que em geral não estão cientes do problema e, no caso das públicas, até mesmo da orientação do Governo Federal. Se o caso for com uma empresa privada, deixe claro que você tentou comprar/contratar o serviço e não conseguiu. Se isto chegar aos ouvidos dos interessados, eles irão escutar. A falta de compatibilidade é, em geral, descuido do desenvolvimento e vai fornecer aos tomadores de decisão os argumentos para discutirem com a equipe de TI.

Por fim, muito obrigado a CGU e a Anatel pela resposta ao problema. Apesar dos meses para a solução e do aviso de sua disponibilidade, sei que isto é, em parte, dos problemas do trâmite administrativo dentro de uma instituição pública. Porém, ainda assim, o prazo foi comparável ou até mais favorável do que o encontrado com diversos problemas de soluções de "referência" no mercado.

Twice NAT: Comunicando redes com o mesmo endereço utilizando Cisco ou Linux

2011-09-27T21:23:00.000-03:00

As boas práticas recomendam que as mudanças no ambiente de produção sejam planejadas, documentadas e testadas antes de serem implementadas. Estes testes, quando possível, são realizados em um ambiente de homologação, ou pré-produção, para evitar qualquer impacto na qualidade dos serviços disponibilizados. Uma das características importantes de um bom ambiente de homologação é a sua semelhança com a produção. Quanto maior esta semelhança, mais problemas poderão ser detectados antes de afetar os usuários.

Um dos pontos interessantes para ser replicado é a configuração de rede. Assim, uma máquina poderia migrar entre o ambiente de produção e homologação sem mudanças, nem mesmo na configuração da rede. Alguém pode perguntar: os endereços IP e, ainda mais, as redes não deveriam ser únicos dentro de uma mesma rede local? Sim, caso contrário, o roteador não saberia para qual das duas redes enviar os pacotes. Deixar as duas redes desconectadas uma da outra também não é uma boa solução. Não é muito prático enviar dados pelo protocolo PPCPPL (pendrive para cá, pendrive para lá). Vejamos o problema de duas redes com endereços conflitantes. O roteador, ao receber um pacote do computador 10.1.2.2 para 10.1.1.2, não teria como escolher entre as duas redes 10.1.1.0/24:

10.1.1.0/24 (homolog)
----------------------+-------------------------------
|
+----+----+ 10.1.2.0/24
|Roteador +--------------------------
+----+----+
|
----------------------+-------------------------------
10.1.1.0/24 (produção)

O primeiro passo da solução é isolar as duas conexões do mesmo roteador. Com o auxílio de um segundo roteador, a conexão fica desta forma:

10.1.1.0/24 (homolog)
----------------------+-------------------------------
|
|fa0/0
+----+----+
|Rot. Aux +
+----+----+
fa0/1|
|
|10.1.99.0/30
|

fa0/1|

+----+----+ 10.1.2.0/24

|Roteador +--------------------------

+----+----+

|fa0/0

----------------------+-------------------------------

10.1.1.0/24 (produção)

Entre os dois roteadores, foi configurada uma rede de dois endereços 10.1.99.0/30. Caso 10.1.2.2 envie um pacote para 10.1.1.2, o roteador não teria dúvidas em enviá-lo para a rede de produção. Agora, como 10.1.2.2 poderia falar com um outro computador com o mesmo endereço mas na rede de homologação? A solução é utilizar a tradução de endereços (NAT).

Em uma NAT, o endereço do pacote é mapeado para outro endereço alcançável pelo destinatário. Quanto ele deixa a rede abaixo da NAT, o IP de origem é mascarado pelo endereço do roteador. Na volta, o IP de destino é traduzido de volta para o endereço da Intranet.

200.123.123.44 (Internet)
----------------------+-------------------------------
|
+----+----+
|Roteador |
+----+----+
|
----------------------+-------------------------------
10.1.0.0/24 (intranet)

No caso do problema das duas redes internas conflitantes, esta tradução pode ser feita estaticamente, mapeando os endereços 1 para 1. Por exemplo: uma rede de mesmo tamanho da rede de homologação é reservada para ser o "alvo virtual" das redes conflitantes. Usaremos neste caso a rede 10.1.66.0/24. Quando 10.1.2.2 quer enviar um pacote para o computador 10.1.1.2 da rede de homologação, ele enviaria o pacote para o endereço correspondente da rede alvo. Se o mapeamento da rede alvo e da rede de homologação estiver na sequência, este seria 10.1.66.2. Exemplos:

10.1.66.1 para 10.1.1.1
10.1.66.2 para 10.1.1.2
10.1.66.20 para 10.1.1.20

Os pacotes seriam enviados ao roteador e, com o auxílio de uma configuração de rota, enviados ao roteador auxiliar. Este realizaria a tradução de endereços e a comunicação estaria estabelecida.

10.1.2.2 envia um pacote para 10.1.66.3 (rede alvo do envio)

10.1.2.2 -> 10.1.66.3

O roteador principal envia o pacote para o roteador auxiliar.

10.1.2.2 -> 10.1.66.3

No roteador auxiliar, ocorre a tradução de endereço de destino. Neste caso, o destino passa para 10.1.1.3:

10.1.2.2 -> 10.1.1.3

O roteador auxiliar envia o pacote pela rede de homologação.

10.1.2.2 -> 10.1.1.3

Agora, e se existir a necessidade de comunicação entre a rede de produção e de homologação? Se a máquina 10.1.1.2 da rede produção necessitasse enviar um pacote para a 10.1.1.3 da rede de homologação, ela poderia utilizar a mesma estratégia de enviar para a rede alvo. Contudo, a resposta nunca chegaria. Quando a máquina 10.1.1.3 da rede de homologação fosse responder o pacote, pelo endereço de origem, esta o enviaria para a máquina 10.1.1.2 de sua própria rede (homologação). A solução para este problema é a utilização do NAT duas vezes, em inglês "Twice NAT" ou NAT "Overlapping".

No "Twice NAT", ou "Nat duas vezes", em um envio do pacote, a tradução dos endereços deve ocorrer duas vezes: uma para o endereço de destino, como na NAT tradicional, e outra para o endereço de origem.

O fluxo do pacote do exemplo anterior, 10.1.1.2 da rede produção para a 10.1.1.3 da homologação seria algo como:

10.1.1.2 envia um pacote para 10.1.66.3 (rede alvo do envio)

10.1.1.2 -> 10.1.66.3

O roteador principal envia o pacote para o roteador auxiliar.

10.1.1.2 -> 10.1.66.3

No roteador auxiliar, ocorre a tradução de endereço, tanto do emissor como do receptor. Neste caso, o destino passa para 10.1.1.3:

10.1.55.2 -> 10.1.1.3

O roteador auxiliar envia o pacote pela rede de homologação.

10.1.55.2 -> 10.1.1.3

O retorno seria o mesmo processo mas em ordem inversa. Para a rede de homologação, a rede "alvo" da produção é a 10.1.55.0/24. Caso os roteadores sejam Cisco, a configuração do roteador auxiliar seria algo como:

interface FastEthernet0/0
 ip address '''10.1.1.1''' 255.255.255.0
 ip nat '''inside'''
!
interface FastEthernet0/1
 ip address '''10.1.99.1''' 255.255.255.252
 ip nat '''outside'''
! Os proximos, um para cada equipamento da rede!!!

! 10.9.1.1 
ip nat inside source static 10.1.1.1 10.1.55.1 
ip nat outside source static 10.1.1.1 10.1.66.1

! 10.9.1.2

ip nat inside source static 10.1.1.2 10.1.55.2 
ip nat outside source static 10.1.1.2 10.1.66.2

Um fato interessante é que as duas redes alvo poderiam compartilhar o endereço sem problemas. A rede alvo a partir da produção para a rede de homologação e a rede alvo a partir da homologação para a produção poderiam ser ambas 10.1.66.0/24. Não existe conflitos.

Como nem todos possuem a possibilidade de utilizar dois roteadores Cisco, vamos também trabalhar no mesmo problema com um servidor Linux.

10.1.1.0/24 (homolog)
----------------------+-------------------------------
|
|eth1
+----+----+
|Rot. Aux +
+----+----+
eth0|

|10.1.99.0/30

eth0|

+----+----+ 10.1.2.0/24

|Roteador +--------------------------

+----+----+

|eth1

----------------------+-------------------------------

10.1.1.0/24 (produção)

Diferente do Cisco, o Linux não consegue realizar a tradução dupla do endereço de origem e destino. No Linux, a tradução do NAT é feita pelas tabelas nat do iptables. Elas possuem 3 chains: PREROUTING, POSTROUTING e OUTPUT. OUTPUT é utilizado pelos pacotes originados dentro do próprio roteador e não é interessante para nosso caso. Quanto aos outros dois, o fluxo de encaminhamento do pacote é o seguinte:

O pacote é capturado pela placa de rede
Regras do PREROUTING
Roteamento
Regras do POSTROUTING
O pacote sai pela interface escolhida

Nesta sequência, existe algumas limitações. O Linux pode fazer o mascaramento tanto dos endereços de origem como de destino. Porém, cada um é feito exclusivamente em uma etapa. No PREROUTING, apenas o endereço de destino pode ser mascarado. No POSTROUTING, apenas o de origem. Isto gera um problema interessante para o roteamento. Vamos rever o exemplo da máquina 10.1.1.2 da rede produção enviando pacotes para a 10.1.1.3 da homologação, mas com roteador Linux:

10.1.1.2 envia um pacote para 10.1.66.3 (rede alvo do envio)

10.1.1.2 -> 10.1.66.3

O roteador principal envia o pacote para o roteador auxiliar.

10.1.1.2 -> 10.1.66.3

No roteador auxiliar:

O pacote é capturado pela placa de rede eth0.

10.1.1.2 -> 10.1.66.3

Regras do PREROUTING

10.1.1.2 -> 10.1.1.3

Roteamento

Neste ponto o Linux deve rotear o pacote de 10.1.1.2 para 10.1.1.3, originado da interface eth0. Porém, isto é uma anomalia. A rede 10.1.1.0/24 é da interface eth1 e pacotes originados desta rede não podem entrar pela eth0. Isto é o famoso caso dos "martian source", que povoam o dmesg e logs dos mais desavisados. O pacote é descartado e nada acontece.

A solução é mascarar o endereço de origem antes de chegar no roteador com a interface 10.1.1.1/24 de homologação. Isto pode ser feito ainda no roteador principal ou em um terceiro roteador intermediário entre os dois. Com isto, o fluxo seria:

10.1.1.2 envia um pacote para 10.1.66.3 (rede alvo do envio)

10.1.1.2 -> 10.1.66.3

Ainda no roteador principal ou no roteador intermediário, ocorre o mascaramento da origem.

O pacote é capturado pela placa de rede eth0.

10.1.1.2 -> 10.1.66.3

Regras do PREROUTING

nada acontece

Roteamento

É escolhida a rota para o roteador secundário

Regras do POSTROUTING

Endereço de origem é mascarado
10.1.55.2 -> 10.1.66.3

O pacote sai para o roteador Secundário

No roteador auxiliar, ocorre a tradução apenas do destinatário. Neste caso, o destino passa para 10.1.1.3:

O pacote é capturado pela placa de rede eth0.

10.1.55.2 -> 10.1.66.3

Regras do PREROUTING

O destino é mascarado
10.1.55.2 -> 10.1.1.3

Roteamento

É escolhida a rota para a rede diretamente conectada

Regras do POSTROUTING

Nada acontece

O pacote sai para o host 10.1.1.3 da rede de homologação

Se o objetivo é comunicação para ambos os sentidos, é necessário reproduzir as regras mas em ordem inversa. Uma vantagem para a configuração em Linux é que o mapeamento das redes alvo para a rede 10.1.1.0/24 pode ser feito por regra única e não uma por endereço de rede. Um dos destinos para o iptables é o NETMAP, que mascara um endereço de uma rede para outra.

Para o caso onde o roteador principal já realiza o mascaramento da origem, as configurações seriam:

Roteador principal:

iptables -t nat -A POSTROUTING -o eth0 -s 10.9.0.0/24 -j NETMAP --to 10.9.55.0/24
iptables -t nat -A PREROUTING -i eth0 -d 10.9.66.0/24 -j NETMAP --to 10.9.0.0/24

Roteador secundário:

iptables -t nat -A POSTROUTING -o eth0 -s 10.9.0.0/24 -j NETMAP --to 10.9.66.0/24
iptables -t nat -A PREROUTING -i eth0 -d 10.9.55.0/24 -j NETMAP --to 10.9.0.0/24

Claro, além disto, é necessário habilitar o ip_forward em ambos para eles atuarem como roteadores.

Assim como no caso do Cisco, as duas redes alvo poderiam ser a mesma. Se for o caso, e pela ordem das interfaces de rede, as configurações do mascaramento dos dois roteadores seriam idênticas.

Além deste exemplo para uso de ambiente de homologação e produção, esta mesma técnica pode ser aplicada em outros casos. Em algumas situações, duas intranets precisam ser interligadas (por exemplo, uma VPN) e, nos piores deles, ambas compartilham uma ou mais redes. Para evitar o custo da conversão dos endereços de toda uma rede, o "Twice NAT" permite a utilização de uma faixa de endereços falsos vaga para realizar o mapeamento.

Arranhando roteamento avançado em Linux

2011-07-29T11:50:00.000-03:00

Esse é para as pessoas que algum dia já conectaram duas placas de redes em um equipamento Linux e nada funcionou direito...

O Linux é um sistema operacional versátil. Opera desde celulares a grandes computadores. Dentro deste espectro, ele também é muito utilizado como o coração de uma gama enorme de roteadores. Um Linux não faz feio frente a um roteador Cisco, só talvez não com o mesmo desempenho. Enfim, com Linux, qualquer computador se torna um roteador avançado. Basta adicionar mais interfaces de rede.

Um dos problemas comuns de conectar 2 placas de rede a um computador é em relação ao roteador padrão. Sempre existe apenas um roteador padrão. Para uma única interface, o que em geral é encontrado em um computador convencional, temos as seguintes rotas:

# ip route

192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.11

127.0.0.0/8 dev lo  scope link

default via 192.168.1.1 dev eth0

A primeira é da rede diretamente conectada pela eth0, a segunda, o mesmo da primeira para a interface de loopback. E a última é a rota para as outras redes (o roteador padrão). Quando adicionamos uma segunda interface de rede, aparece mais uma rota diretamente conectada:

# ip route

192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.11

192.168.2.0/24 dev eth1  proto kernel  scope link  src 192.168.2.22

127.0.0.0/8 dev lo  scope link

default via 192.168.1.1 dev eth0

Em geral, a segunda interface de rede conecta uma rede isolada, acessível apenas através do próprio Linux (como roteador ou não).

Agora, quando a máquina que está conectada em duas redes não é a única forma de acessar a subrede, o que acontece? Imagine um cenário onde um Linux está conectado em duas redes. Simples não?

Rede A(192.168.1.0/24)              Rede B(192.168.2.0/24)  

       |............Roteador (R)...........|

   X...|                                   |....Y

       |........eth0 Linux (L) eth1........|                   

       |                                   |

Nem tanto. Se o equipamento X, conectado na rede A tenta falar com a eth0 do servidor Linux, ele responde sem problemas (pois está diretamente conectado). O mesmo ocorre quando o equipamento Y tenta falar com o servidor Linux pela interface eth1. Agora, se X precisa falar com o endereço da interface eth1? O que acontece?

X prepara um pacote para 192.168.2.22
X envia para o roteador pois o IP 192.168.2.22 não está nas suas redes locais
Roteador recebe o pacote da rede A e repassa para a rede B
O servidor Linux recebe o pacote pela interface eth1

O caminho de ida foi sem problemas. Agora a resposta:

O servidor Linux prepara resposta para X
X está em uma rede diretamente conectada (interface eth0). O pacote é enviado diretamente.

Olha que interessante! O pacote chegou pela interface eth1 mas saiu pela eth0 (e com o MAC dela). O roteador, se quisesse, não teria como restringir a resposta do servidor Linux.

Vamos a outro cenário. Uma máquina Z fora das duas redes, tenta falar com a a interface eth0.

Roteador recebe o pacote vindo de Z, pela rede C, e repassa para a rede A
O servidor Linux recebe o pacote pela interface eth0
O servidor Linux prepara a resposta de Z
Como Z não é uma interface diretamente conectada, ele envia ao roteador padrão (192.168.1.1).
O Roteador recebe o pacote vindo de (192.168.1.11) vindo da rede A e o repassa para Z

Sem problemas. Agora se Z estivesse falando com a eth1?

Roteador recebe o pacote vindo de Z, pela rede C, e repassa para a rede B
O servidor Linux recebe o pacote pela interface eth1
O servidor Linux prepara a resposta de Z
Como Z não é uma interface diretamente conectada, ele envia ao roteador padrão (192.168.1.1).
O Roteador recebe o pacote de (192.168.2.22) vindo da rede A e REJEITA!. Como o pacote da rede B pode surgir dentro da rede A?

O problema é que a tabela de roteamento não faz distinção quanto ao ip de origem (ou interface de origem). Ele apenas observa o destino. Como o destino é fora da rede local, ele envia pelo roteador padrão. Não existe 2 roteadores "padrão". Como resolver esta questão?

O Linux permite que seja criada mais de uma tabela de roteamento. Basta acrescentar a qual tabela estamos nos referenciando no comando "ip route". Exemplo:

# ip route show table main

192.168.1.0/24 dev eth0  proto kernel  scope link  src 192.168.1.11

192.168.2.0/24 dev eth1  proto kernel  scope link  src 192.168.2.22

127.0.0.0/8 dev lo  scope link

default via 192.168.1.1 dev eth0

As tabelas "local" e "0" também são bem interessantes para quem só usava até agora o comando "route".

O que precisamos fazer é criar uma nova tabela. Primeiro, cadastre um nome (para não usar números)

echo "1 redeB" >>/etc/iproute2/rt_tables

Isto permite que redeB seja usada nos comandos ao invés de apenas números.

Agora, a nova tabela de roteamento pode ser recriada.

ip route add 192.168.2.0/24 dev eth1 table redeB

ip route add default via 192.168.2.1 dev eth1 table redeB

Mas quando que esta tabela nova vai ser usada? Isto pode ser definido por regras. Esta regra faz com que todos os pacotes que chegam pela interface eth1 utilizem a tabela de rotas redeB ao invés das regras padrão.

ip rule add from 192.168.2.2/32 lookup redeB

E pode ser necessário (em geral é) limpar o cache de rotas:

ip route flush cache

Como sempre, toda esta configuração (exceto pelo cadastro do nome) é volátil e se perde ao derrubar a rede ou reiniciar o computador. Por isto, deve ser carregada em script junto ao processo de configuração da rede.

Um outro cenário onde a configuração de tabelas de roteamento distintas pode ser útil é o caso de uma VPN quando até o tráfego Internet da rede interna deve ser roteado para a VPN. O roteador VPN deve utilizar uma rota padrão que aponte para a Internet, para operar a VPN, mas os pacotes vindos da rede interna devem ser todos roteados pela VPN.

Outro caso seria em laptops com interface WLAN e LAN. Se as duas estiverem conectadas em segmentos distintos da rede local, para algumas máquinas uma das interfaces não será acessível.

Este é só um caso onde é necessário o roteamento avançado. Porém, roteamento avançado pode ser usado em uma infinidade de casos como múltiplas conexões para a Internet. Vale a pena buscar no Google...

Ah, se alguém sentiu falta dos comandos "ifconfig", "route", ta mais do que na hora de aprender o comando "ip". Ele é mais limpo, mais fácil e toda a saída pode ser usada como entrada, basta prefixar com "ip <modulo> add/del". Talvez eu escreva sobre isto no futuro...

A quem interessa o IPv6?

2011-04-29T00:52:00.000-03:00

Tava aqui filosofando com meus botões...

Os provedores de Internet receberam "de graça" um bem que são endereços IPv4. Era só justificar que levava e era assim no mundo inteiro. Enquanto tinha endereços "a vontade", tal bem não tinha preço. Segundo a lei da oferta e procura, se a oferta é ilimitada, o preço é zero. Bem, hoje, a oferta já não é mais ilimitada.

Os endereços IPv4 são necessários para acessar a Internet. Como o mundo não migrou para IPv6, ele ainda é fundamental. Bem, se a oferta reduz (ou melhor, a "produção parou") e a procura só aumenta, temos uma inflação no preço do endereço.

Agora voltamos ao provedor de Internet. Se vc tinha um bem que vale zero, ele não era tão importante assim. Bastava que ele suprisse suas necessidades de negócio e pronto. Agora, quando este bem, ou melhor, ativo, começa a valer alguns milhões, a história muda. O pior de tudo é que, até agora, ninguém disse que o ativo endereço IPv4 é ou não é negociável. Recebeu de graça e agora pode vender. Entendeu a jogada? Quase a galinha dos ovos de ouro. Só não é melhor porque a galinha só vai botar ovos até, no máximo, 2012.

A implementação de IPv6 envolve custos e não possui um retorno visível para o cliente, exceto pelos problemas no serviço durante a migração. Se um provedor implementa a sua rede IPv6, e todos o fizerem, a procura por endereços irá cair, e inclusive, a oferta pode aumentar com os endereços vagos. Com isto o preço do ativo que eles atualmente possuem irá cair abruptamente. Alguém que visa o lucro é louco de fazer isto?

Moral da história: os provedores comerciais não irão implementar IPv6 enquanto a curva de crescimento do valor do endereço ainda estiver subindo e começarão a fazer gambiarras nos seus serviços para poder vender para outros novos provedores o que puder de seus endereços enquanto o preço estive em alta.

Os provedores não irão implementar a rede IPv6 até que:

Os clientes exijam o serviço (IPv6 ou vou para outro que tenha), coisa que não vai acontecer se o cliente não souber do que se trata;
O governo force sua implementação por força de lei ou norma;
Ou, no caso de mau planejamento, eles tenham vendido mais endereços do que podiam e agora precisam comprar.

É, esperem uma inversão no serviço de Internet daqui a um, dois anos. Preços mais altos e qualidade pior devido as gambiarras para usar menos endereços.

Luiz 1 x 0 SW de gerenciamento de celular

2011-04-24T05:08:00.000-03:00

Como responsável da área da computação em casa, eu estava realizando a migração do celular da mulher. Bem, vamos dizer que é um celular exótico: gradiente fabricado pela francesa Sagem. Para a época, o celular era muito bom e ainda funciona bem. Agora voltando ao assunto...

A ferramenta de exportação foi terceirizada para uma empresa que, claro, não suporta mais este celular e nem vende o produto que o fazia. Com muita luta, achei uma versão demo que faz o que eu queria, exceto pelo fato de ser limitada a 6 contatos (o celular tem algumas centenas deles). Procura aqui, ali e nada de solução. Conclui que eu teria que fazer isto sozinho!

Tem um debugger para windows muito bom: w32dsm. Faz milagres. Pena que eu não tive assembly x86 na universidade. Com ele, busquei qualquer referencia a string "contacts" na memoria e coloquei um breakpoint depois de cada uma. Rodei o programa e foi contando o breakpoint que batia 6 vezes. E não é que eu achei?!

String Resource ID=17035: "Reading contacts: Mobile memory"

Desta forma, existe algum loop do tipo:

while ??? {

???

    chamada1()

???

}

chamada1 ( ) { chamada2 () }

(...)

chamadaX () { char[] str = "Reading contacts: Mobile memory" }

Com esta informação, fuirastreando (stepover) as chamadas "ret" do assembly que representam o retorno da chamada de função até o ponto onde o stepover bateu novamente no breakpoint da string. Isto me indicou que eu havia chegado no loop de leitura dos contatos. Voltei para as intruções do loop e analisei uma passada completa. O resultado não foi nada inovador. Algumas comparações no começo do loop, muita coisa no meio e um incremental no final: o bom e velho "for":

for (i-0;???;i++) {

???

    chamada1()

???

}
Bastou observar com cuidado para ver qual comparação gerava o jump para fora do loop. Na sexta iteração, achei uma comparação interessante entre o EAX (neste caso, i) e uma região da memória EBP+018. Mais sugestivo é que a comparação é >=. Quando ambos eram 6, o processo saia do loop. Olhando este EAX+018, ele possui o valor 6 desde o início do loop.

a=6; 

for (i-0;???;i++) {

    if (i >= a) break;

    chamada1()

???

}
Agora é a parte fácil :-) Durante um loop qualquer, ainda pelo debugger, troquei o valor da memória para algo como 0x1000, retirei o breakpoint e fui para o abraço. Se fosse fazer algo permanente, teria que trocar a intrução do jump para uma nop ou modificar a comparação para que esta sempre desse negativa.

Já tinha feito algo parecido no passado mas com if e não for. O loop é muito mais fácil de identificar.

O pior de tudo: vou ganhar só um "ah tah... obrigada" por todo este trabalho :-(

Blog? Vamos ver..

2011-04-03T09:32:00.000-03:00

Resolvi criar o blog. É mais fácil para publicar coisas por aqui...