OpenWRT: Atualizando para versão 15.05

Mais um artigo da série sobre o OpenWRT.

Já temos a Caos Calmer (CC) 15.05. Agora vamos atualizar nossos sistemas!

Sim, este artigo repete diversos pontos do artigo de atualização anterior.

96,72% dos problemas com instalação/atualização com OpenWRT que ajudo é em relação a escolha incorreta da imagem da firmware. Como sempre, recomendo a versão squashfs, que possui modo de recuperação. Pegue o arquivo no download da Caos Calmer e nunca em um endereço qualquer, mesmo que seja na wiki do OpenWRT. Normalmente a wiki referencia a versão em desenvolvimento, que não é a que você quer. No diretório de download, navegue seguindo o caminho da "arquitetura alvo" em uso no seu roteador. Se você já é um usuário do OpenWRT, você pode vê-la olhando o arquivo /etc/openwrt_release:

root@router:~~# cat /etc/openwrt_release
DISTRIB_ID='OpenWrt'
DISTRIB_RELEASE='15.05'
DISTRIB_REVISION='r46767'
DISTRIB_CODENAME='chaos_calmer'
DISTRIB_TARGET='ar71xx/generic'
DISTRIB_DESCRIPTION='OpenWrt Chaos Calmer 15.05'
DISTRIB_TAINTS=''

A diferença entre a primeira instalação e a atualização é que não será usada a imagem "factory" e sim a "sysupgrade". Escolha o arquivo correspondente ao seu roteador (inclusive versão de hardware!). E muito importante, leia a wiki do seu roteador independente se ele já funcionava na versão anterior! São poucos minutos de leitura que podem salvar horas de trabalho ou mesmo seu roteador.

Bem, se eu simplesmente ir na interface, fornecer a nova imagem, ele vai funcionar? Provavelmente, mas talvez não é a maneira que dê menos trabalho. A atualização pode preservar as configurações mas não os programas instalados. Se você tem raiz expandida em unidade externa, a encrenca é ainda maior.

Mas eu nunca instalei um programa! OK, use a interface web e provavelmente todas as configurações serão migradas sem problemas. Já testei isto em mais de um roteador e funcionou sem problemas. Mas faça o backup antes! Caso tenha instalado algum pacote, continue lendo.

Em primeiro lugar, precisamos do plano de retorno caso a nova versão não se comporte como o esperado. Faça sempre um backup geral do seu sistema. No processo de upgrade, eu sugiro que sejam feitas as três formas diferentes de backup que eu comento no artigo sobre o tema: backup gerado pelo openwrt, lista de pacotes instalados e todos os arquivos do overlay. Este último serve apenas para o plano de retorno caso algo importante não funcione para você na nova versão.

Agora, finalmente, você está pronto para enviar a nova firmware. Se você usa um armazenamento externo para expandir a raiz, leia até o final deste post antes de iniciar o processo! Faça o upgrade pela interface web ou pelo terminal. Inclusive, você pode baixar o arquivo diretamente no roteador. Ex:

# cd /tmp

# wget http://downloads.openwrt.org/chaos_calmer/15.05/.../openwrt-15.05-...-squashfs-sysupgrade.bin

# sysupgrade openwrt...xxx....img 

Só cuidado ao colar a URL. O downloads.openwrt.org usa https por padrão mas o wget do OpenWRT não tem suporte para https (por padrão). Contudo, o downloads.openwrt.org aceita http sem problemas, só tirar o "s".

E pode fazer pela Wifi? Os fabricantes não recomendam usar sempre um computador "conectado por cabo"? Sim, e já tive problemas com atualização por não escutar isto. Mas não com OpenWRT. Se estiver atualizando (e não instalando a primeira vez!), pode fazer pela Wifi sem problemas. Quando a gravação for iniciada, todo o processo já está independente do computador cliente.

E depois do "Enter"/"Gravar", é a hora que você reza. Sempre dá um frio na barriga.

Se optar por preservar as configurações, tudo que seria guardado em um backup do sistema (listado pelo "sysupgrade -l") será restaurado. Se você instalou algum pacote e guardou a lista do que foi instalado, esta é a hora que você reinstala os pacotes desejados. Se for instalar manualmente, procure instalar os pacotes de mais alto nível (ex: "luci-app-minidlna" antes de "minidlna"), pois eles irão, por dependência, baixar os pacotes requeridos. No final do processo, é bom refazer a listagem do que está instalado e comparar com o que você tinha na versão anterior.

Não é comum no OpenWRT mas pode existir alguma atualização de segurança importante, como ocorreu com o Heartbleed. De qualquer forma, é bom listar os pacotes atualizáveis:

# opkg update
# opkg list-upgradable

O maior problema é que estas atualizações de segurança também ocupararão espaço a mais do seu roteador (overlay) pois apagar ou substituir arquivos existentes na firmware inicial não recupera o espaço usado no sistema de arquivos.

Por fim, faça um novo backup geral. É sempre bom preservar o seu trabalho.

Se precisar retornar a versão anterior do OpenWRT, realize a gravação da firmware antiga, entre no modo de recuperação e restaure a overlay.

Se você não usa uma unidade externa para expandir o espaço interno, seu trabalho acabou. Para os demais, o processo é um pouco mais complicado... Ao atualizar o sistema, você terá um kernel novo que é incompatível com os módulos de kernel existentes na unidade externa ou mesmo com as bibliotecas pertencentes à versão anterior. Você precisaria reinstalá-los. Esta é a sugestão de como proceder:

Em primeiro lugar, gere todos os backups sugeridos anteriormente. É importante preservar seu trabalho anterior. Ainda sem instalar a nova firmware, reinicie o sistema sem a unidade externa. Se você seguiu minha sugestão de manter uma configuração básica na flash interna, você ainda terá um ambiente funcional. Com isto, ele vai usar somente a flash interna (com a configuração que você tinha antes de usar a unidade externa).

Ainda com a unidade externa desconectada, faça o procedimento de atualização descrito neste artigo para quem não usa raiz expandida, inclusive com a etapa de backups. Você terá que preservar os dois conjuntos de backups: com e sem a unidade externa em uso. Ao final do processo, você deverá ter a sua configuração básica restabelecida. Caso tenha optado por não preservar as configurações na gravação, você pode aproveitar o backup gerado quando a unidade externa estava desconectada (o segundo) para restaurar as configurações.

Neste momento, a unidade externa ainda está com os programas da versão anterior, que são geralmente incompatíveis com a nova versão (os módulos de kernel sempre o são). Por isto, precisamos nos livrar de todos os arquivos da versão anterior do OpenWRT presentes na unidade externa. Na unidade externa, na partição usada como overlay, remova todo o conteúdo ou mova tudo para um subdiretório (ou para outra unidade se não estiver com espaço livre) afim de que este não seja usado. Como sugestão, crie um "openwrt-versao-xxx" e mova tudo para lá. Refaça a configuração de uso de uma unidade externa (que no mínimo será reinstalar os pacotes necessários). Reinicie o sistema. Você deve estar agora com mais espaço na raiz.

Neste ponto, você ainda terá as mesmas configurações que tinha quando usou o sistema sem a unidade externa. Envie o primeiro backup da versão anterior feito com a unidade externa conectada (primeiro backup). Na sequência, reinstale os pacotes extras, assim como é feito para ambientes sem a raiz expandida. Complete o trabalho com aquele backup final.

Espero que apreciem a nova versão. De agora em diante, vou apenas focar em configurações específicas do 15.05, que ainda podem funcionar nas versões 14.07, 12.09 e 10.03.1.

Se pintar um problema, tem sempre o fórum deste blog. Até a próxima.

OpenWRT: Fazendo Backups

Mais um artigo da série sobre o OpenWRT.

Antes de comentar como atualizar para a próxima versão do OpenWRT, achei interessante comentar sobre um assunto relacionado, mas tão importante que merece um artigo próprio: backups.

Tem gente que ainda confia em tecnologia. Brinco dizendo que não adianta rezar, só backup salva. Depois de fotos, vídeos, documentos, os roteadores são a última coisa que as pessoas se preocupam em fazer backup. Afinal de contas, para os mais simples, ele só contém o nome da rede e a senha. Porém, com o OpenWRT, seu roteador pode ser muito mais do que isto. O meu, em especial, é a central de comunicação, entreterimento e armazenamento da casa. Na prática, um servidor na rede com múltiplas funções. Como configurá-lo exige uma significativa quantidade de trabalho, sempre é bom evitar que você tenha que refazê-lo caso algo aconteça com ele.

Saindo do ambiente residencial, o tempo de restauração normalmente é crítico para ambientes empresariais. Neste caso, um backup "na mão" facilita em muito restaurar rapidamente um equipamento com defeito. Fora isto, backup podem ser utilizados para replicação "em massa", evitando o retrabalho de configurar o roteador "do zero" (para este fim, tem que recriar a entrada da ULA do IPv6).

Neste artigo, vou considerar que você conhece um básico do OpenWRT, como a estrutura que usa o squashfs com a overlay.

O OpenWRT tem backup? Sim, mas não de tudo. O backup do OpenWRT guarda somente configurações e dados selecionados do /etc. A lista do que ele copia pode ser vista com o comando "sysupgrade -l":

root@router:~~# sysupgrade -l

/etc/config/dhcp

...

/etc/sysctl.conf

/etc/sysupgrade.conf

São alguns arquivos pré-definidos, listados em /lib/upgrade/keep.d/ (pelos pacotes) ou em /etc/sysupgrade.conf, pelo usuário. Programas instalados não serão salvos, mas somente suas configurações (se estiverem em /etc/config ou forem explicitadas pelo mantenedor do pacote). É isto que é preservado quando você faz uma atualização do OpenWRT e pede para salvar as configurações. Compare isto com o conteúdo da overlay. Tudo que estiver lá foi modificado no seu sistema desde a instalação. O que estiver lá e não na listagem do sysupgrade, será perdido utilizando esta forma de backup. 

E quanto aos programas? Se você usa a firmware no formato squashfs, existem duas opções. A primeira é guardar a lista dos pacotes instalados e reinstalá-los. Para facilitar, você pode ver na /overlay:

root@router:~# ls /overlay/usr/lib/opkg/info/*control | sed -e 's%.*/%%;s/\.control//' | xargs

aiccu bind-dig bind-host bind-libs binutils block-mount coreutils-du coreutils ddns-scripts diffutils e2fsprogs...

Com a lista de pacotes salva, basta instalá-los após a restauração da configuração.

A segunda opção é guardar toda a overlay. Para salvar tudo mesmo que você fez desde a instalação do OpenWRT, é bom copiar a partição overlay. Um tar simples pode fazer o serviço. De um computador com Linux, execute:

$ ssh root@router tar -czv /overlay | dd of=backup-roteador.20150925.tgz

Isto compacta a /overlay em um tar e envia para o arquivo local backup-roteador.20150925.tgz sem criar o arquivo no roteador, que nem sempre tem espaço para isto. O WinSCP poderia copiar a overlay mas provavelmente você teria problemas com a permissão (perdida) dos arquivos. Se a overlay for pequena, você pode fazer o tar no /tmp (memória RAM) e copiar com o WinSCP:

root@router:~# tar -czvf /tmp/backup-roteador.20150925.tgz /overlay

Caso use Linux, fiz um pequeno script que faz a cópia do backup do OpenWRT, da lista de pacotes e da overlay em um único passo. Se seu roteador está em 192.168.1.1, só chamar:

$ ./fullbackup 192.168.1.1

E se eu não uso a firmware em squashfs? Primeiro você é corajoso pois se fizer algo de errado, não terá como usar a recuperação do OpenWRT. Contudo, isto não é um problema se o OpenWRT foi instalado em um PC ou VM. Para estes casos, faça o tar de todo o conteúdo. Só precisa tomar o cuidado de excluir os diretórios de dados voláteis (/proc, /sys, /tmp, /var/tmp, ...) ou simplesmente use a opção "--one-file-system" do tar para não sair da partição raíz.

E para restaurar tudo isto? Se for o backup do OpenWRT, pode ser feito pela interface web ou pelo comando sysupgrade. Se for pela overlay, recomendo entrar no modo de recuperação, zerar o roteador, montar a overlay e descompactar o conteúdo diretamente sobre a partição. Escrever na overlay enquanto ela estiver usada resulta em comportamentos incertos.

E, reforçando, não adianta rezar: só backup salva!

Se pintar um problema, tem sempre o fórum deste blog. Até a próxima.

OpenWRT: Recuperação de desastre em vídeo

Este é mais um artigovídeo da série sobre o OpenWRT. 

Depois de diversas dúvidas na postagem sobre recuperação do OpenWRT, resolvi mostrar os procedimentos em vídeo. Assim ficam menos dúvidas de como apertar o botão, quando, e o que é esperado.

Até a próxima! E feliz 2014!

OpenWRT: Multiplique suas redes: MultiLAN com VLAN

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.

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.