OpenWRT: Sobre o OpenWRT

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

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

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

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.

1. 10.1.2.2 envia um pacote para 10.1.66.3 (rede alvo do envio)
1. 10.1.2.2 -> 10.1.66.3
2. O roteador principal envia o pacote para o roteador auxiliar.
1. 10.1.2.2 -> 10.1.66.3
3. No roteador auxiliar, ocorre a tradução de endereço de destino. Neste caso, o destino passa para 10.1.1.3:
1. 10.1.2.2 -> 10.1.1.3
4. O roteador auxiliar envia o pacote pela rede de homologação.
1. 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:

1. 10.1.1.2 envia um pacote para 10.1.66.3 (rede alvo do envio)
1. 10.1.1.2 -> 10.1.66.3
2. O roteador principal envia o pacote para o roteador auxiliar.
1. 10.1.1.2 -> 10.1.66.3
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:
1. 10.1.55.2 -> 10.1.1.3
4. O roteador auxiliar envia o pacote pela rede de homologação.
1. 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:

1. O pacote é capturado pela placa de rede
2. Regras do PREROUTING
3. Roteamento
4. Regras do POSTROUTING
5. 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:

1. 10.1.1.2 envia um pacote para 10.1.66.3 (rede alvo do envio)
1. 10.1.1.2 -> 10.1.66.3
2. O roteador principal envia o pacote para o roteador auxiliar.
1. 10.1.1.2 -> 10.1.66.3
   
3. No roteador auxiliar:
1. O pacote é capturado pela placa de rede eth0.
1. 10.1.1.2 -> 10.1.66.3 
2. Regras do PREROUTING
1. 10.1.1.2 -> 10.1.1.3 
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:

1. 10.1.1.2 envia um pacote para 10.1.66.3 (rede alvo do envio)
1. 10.1.1.2 -> 10.1.66.3
2. Ainda no roteador principal ou no roteador intermediário, ocorre o mascaramento da origem.
1. O pacote é capturado pela placa de rede eth0.
1. 10.1.1.2 -> 10.1.66.3 
2. Regras do PREROUTING
1. nada acontece
3. Roteamento
1. É escolhida a rota para o roteador secundário
4. Regras do POSTROUTING
1. Endereço de origem é mascarado
2. 10.1.55.2 -> 10.1.66.3
5. O pacote sai para o roteador Secundário
3. No roteador auxiliar, ocorre a tradução apenas do destinatário. Neste caso, o destino passa para 10.1.1.3:
1. O pacote é capturado pela placa de rede eth0.
1. 10.1.55.2 -> 10.1.66.3
2. Regras do PREROUTING
1. O destino é mascarado
2. 10.1.55.2 -> 10.1.1.3
3. Roteamento
1. É escolhida a rota para a rede diretamente conectada
4. Regras do POSTROUTING
1. Nada acontece
5. 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.