OpenWRT: Barrier Breaker (14.07)

Salve pessoal! Mais um artigo da série do OpenWRT.

Quem está acompanhando as notícias do mundo de TI deve ter notado que foi lançada uma nova versão do OpenWRT, a Barrier Breaker (a.k.a BB, 14.07). Como fazem dois anos desde a última versão estável, é uma significativa mudança. Então quer dizer que eu vou atualizar e minha vida vai mudar?! Não é bem assim. Dependendo do caso, você nem vai notar. Afinal, o que a BB trouxe de novo? Vamos aos destaques:

• Kernel atualizado para 3.10

Isto traz diversas correções, atualizações de drivers e outras funcionalidades desde o kernel 3.3. Se você nunca precisou olhar qual a versão do kernel no seu OpenWRT, provavelmente não sentirá diferença. Existe diversas correções para problemas com placas atheros, mas parece que nem todos os problemas antigos foram sanados. Atualização: mas resolveu todos os que eu tinha ;-)

• Suporte nativo IPv6

Para sortudos que já tem acesso à redes IPv6 nativa, a nova versão do OpenWRT deve ser uma das mais adaptadas ao mundo de pilha dupla. Para os demais, continuamos a depender de gambi... estratégias de contorno técnicas como túneis, que já comentei anteriormente. Você vai observar também o surgimento de uma nova interface wan6, dedicada ao suporte IPv6. Ela muda a forma de configurar IPv6, a exemplo do uso de túneis. Devo atualizar o artigo de IPv6 em breve.

• Novo init: procd

O procd seria o equivalente ao systemd no OpenWRT. Com a alteração, os scripts de iniciação dos serviços precisam de ajustes. Caso tenha feito algum, deve ser necessário atualizá-lo. Como ele substituiu o hotplug2, pode ter algum efeito colateral nos scripts em /etc/hotplug.d/, como as funções acionadas por botão. Entretanto, parece que ao menos nesta versão, ele tem comportamento compatível com scripts antigos.

• Suporte a snapshot e rollback

Ainda não tive a oportunidade de mexer neste recurso mas ele permite que você crie fotos de seu ambiente (no caso, as mudanças da overlay) e permite que você retorne a um estado anterior em caso de falha. Contudo, isto mexe um pouco a forma de trabalho, exigindo que você explicitamente save o estado atual do disco antes de reiniciar o roteador. Vou deixar isto para um artigo futuro.

• Pacotes atualizados!

Entre os diversos pacotes disponíveis no OpenWRT, muitos sofreram atualização. Isto pode trazer aquele recurso que você sentia falta e nem sabia. Ou não.

• Novo tema no Luci

Esta sim é uma mudança perceptível! A parte de "melhoria visual" é pessoal mas achei o novo tema mais limpo.

Se nenhum dos itens acima te motivou, resta o argumento do suporte. A versão anterior cairá em desuso. Neste blog, por exemplo, todos os novos trabalhos serão em relação ao BB. Deixarei as referências ao AA e posso citar como deveria funcionar na versão anterior mas as configurações não serão testadas. O mesmo vale para fóruns, wiki e outros meios.

E algum motivo sério para não atualizar? Sim, se você tem uma conexão com a internet de mais de 180MBit/s. Houve relatos de redução na capacidade de roteamento via NAT, antes em algo como 240Mbit/s, com a atualização. Provavelmente é um problema do kernel ou mesmo do compilador (ou uma interação entre eles). De qualquer forma, vai ser difícil a solução. Melhorias já ocorreram na versão em desenvolvimento mas são marginais. Simplesmente falta capacidade de processamento da CPU (lembre-se, ela normalmente roda em algo como 400Mhz!).

Se você está neste limite e precisa de algo mais rápido, provavelmente o firmware original seja o mais indicado. Ele possui o recurso de aceleração de NAT por hardware, que libera o uso da CPU. Com ele, você vai poder realizar NAT a quase a velocidade do fio (uns 900MBit/s). Como não existe um driver aberto para este recurso, dificilmente ele estará no curto prazo no OpenWRT. Acredito que quem está com uma conexão internet via fibra de mais de 150Mbit/s já deve ter trocado o roteador de R$100 por algo melhor ;-)

Logo vou atualizar o artigo de atualização do OpenWRT para incluir o BB.

E a próxima versão? CC? Sim, Chaos Calmer. Prometeram para o final deste ano mas acho difícil. Não acredito no prazo não tanto pela base do OpenWRT mas sim pelos pacotes extras, os feeds. Muitos pacotes estavam abandonados e desatualizados. Um dos prováveis motivos era a necessidade de enviar as atualizações via lista e esperar a boa vontade de alguém com permissão de commit para aplicá-lo. Isto pode funcionar para o núcleo do OpenWRT mas não é muito prático para as várias centenas de pacotes extra. Desta forma, os pacotes anteriores foram congelados em oldpackages e uma nova fonte foi construída no github. Se seu pacote favorito já não estiver no novo repositório do github e você não quiser que seu pacote desapareça do OpenWRT CC, você pode adotá-lo. Eu já fiz a minha parte adotando o ruby.

Até a próxima.

OpenWRT: Utilizando conexões wireless para ligar duas redes - conceitos

Como este post vai ficar um pouco longo, vou dividi-lo em partes. Nesta vou apresentar o problema. Nas próximas vemos as configurações.

Um dos problemas mais comuns de redes wireless é a cobertura do sinal. Vigas, vidro e diversas coisas desconhecidas podem prejudicar seu sinal. Além disto, o sinal do seu equipamento receptor pode não ser uma das melhores maravilhas. Notei isto logo que recebi minha SmartTV. A qualidade do sinal wireless é péssima. A solução para problemas de cobertura são basicamente: reposicionar seu roteador, melhorar a antena e aumentar a potência.

Também comprei um home theater que tem rede mas a wireless é paga "a parte", e muito cara. Isto é comum também nas TVs, mas não é o meu caso. Pelo preço, prefiro comprar outra coisa. Para solucionar o problema de cobertura e para substituir a necessidade de "módulo wireless", optei por adicionar um segundo roteador.

Roteador como AP

O que, em geral, temos em casa é um roteador wireless, que faz o papel de uma ponte da rede sem fio com as portas da rede LAN cabeada (função AP). A função "roteador" é composta de outras funcionalidades como NAT, DHCP, firewall, fazendo a interligação da rede LAN, cabeada ou sem fio, ao mundo externo, geralmente conectado na porta WAN. Portanto, um roteador wireless inclui as funções de um AP simples. Para usá-lo como somente um AP, basta não usar a porta WAN e desativar o DHCP (não preciso nem dizer que dois servidores DHCP ligados em uma mesma rede é receita para desastre). Isto é comum quando o roteador é fornecido pela telecom (roteador ADSL). Achei esta figura que ilustra como ficaria a conexão entre os dois roteadores (e um modem cabeado):

Fonte:https://lantechca.files.wordpress.com/2011/05/add-wireless-ap.png

Mas essa é a melhor forma de ligar os dois roteadores? Sim. E se eu ligar a LAN do roteador da esquerda na WAN do roteador da direira? Sim, pode funcionar. Se as redes LAN dos dois roteador não forem conflitantes (ex: 10.0.0.0/24 e 192.168.1.0/24), você terá conectividade. Porém, você estará fazendo duas vezes a NAT. Se a NAT é ruim para as aplicações pear-to-pear (skype, torrent, emule), duas é um desastre. Não existe técnica de transversão NAT que ajude. Além disto, computadores que estiverem conectados nas portas LAN do roteador da esquerda não irão "enxergar" os computadores conectados no roteador da direita, seja por cabo ou sem fio (mas o inverso sim). E, para os que gostam de jogar online, vai ter ainda mais latência. Ah, e nada de IPv6 no roteador da direita.

Múltiplos access-point wireless

A tecnologia sem fio 802.11 já foi pensada na possibilidade de um usuário se deslocar ao longo de um determinado local, onde o sinal é fornecido por uma série de equipamentos. O princípio é bem simples: quando existir mais de uma rede com as mesmas características (nome, segurança, senha), é função do equipamento cliente escolher o access-point que forneça o melhor sinal. Isto sem mesmo informar a desconexão ao usuário. No máximo deve ser sentido uma pequena engasgada durante a nova autenticação. Tudo isto funcionará se as estações sem fio estiverem operando como APs e compartilharem a mesma rede local.

Aproveitando, independente do OpenWRT, se for construir uma pequena rede sem fio composta de uma série de APs conectados a uma mesma rede e que usam a mesma senha, não escolha SSID diferentes para cada uma! Só vai te atrapalhar e dificultar a vida do usuário.

Roteador Wireless e AP fornecendo múltiplos access-point wireless

Agora vamos juntar os dois conceitos: roteador operando como AP e mais de uma estação fornecendo a mesma rede sem fio. Voltando a figura anterior, se o roteador "Router" fosse substituído por um roteador wireless, você teria dois provedores do sinal da sua rede sem fio. Um seria o roteador principal, operando como roteador da rede e estação wireless, e o segundo roteador wireless operando apenas como um AP. A interconexão entre os dois é feita através de um cabo convencional. Para qualidade de conexão, é a melhor situação. Os equipamentos conectados, seja por cabo ou sem fio, em ambos os roteadores irão enxergar qualquer outro equipamento conectado.

Para ajudar a melhorar o sinal da rede sem fio, os dois roteadores wireless precisam ficar afastados. Passar um cabo de rede longo pode não ser o que a maioria deseja. Inclusive eu. Não seria melhor que os dois roteadores se comunicassem pela rede sem fio? Seria ótimo! Mas tem alguns problemas ao utilizar redes sem fio para ponte. Vamos simplificar na situação onde é desejado conectar duas áreas de rede, com diversos computadores, através de uma conexão wireless.

Interligando dois setores de rede por conexão wireless

A tecnologia Ethernet cabeada e sem fio operam de maneira diferente. Tanto na cabeada quanto na sem fio, os equipamentos são identificados por um endereço físico (MAC). Por um cabo podem trafegar inúmeras conversas entre computadores diversos. Já em uma conexão sem fio, o access-point wireless somente aceitará dados oriundos do mesmo endereço MAC do cliente que fez a conexão. Isto é um problema? Não para o uso comum. Sim para o nosso caso. Vejamos a figura seguinte, onde é mostrado dois computadores conectados por cabo em equipamentos wireless (um em modo cliente e outro access-point) e estas conversando por sinal wireless:

Fonte:https://wiki.openwrt.org/doc/howto/clientmode

O computador "Bridged Host" está conectado por cabo no cliente wireless "W-LAN Client". Este está conectado como um cliente wireless no "W-LAN AP" que, por fim, conecta em um segundo computador "Target". Esta seria a tentativa de conversa entre "Bridged Host" e "Target":

1. "Bridged Host" prepara um pacote para "Target"  colocando seu endereço MAC de origem e o MAC do computador "Target" como destino. O pacote é enviado à estação "W-LAN Client".
2. A estação "W-LAN Client" recebe o pacote e o envia para "W-LAN AP". Porém, antes de enviar, ela troca o MAC de origem, antes com o MAC do "Bridged Host", pelo seu próprio MAC. Caso contrário, a estação "W-LAN AP" não aceitaria.
3. A estação "W-LAN AP" recebe o pacote e o retransmite para o computador "Target".  Pelo endereço MAC de origem, "Target" acha que quem está falando com ele é "W-LAN Client" e não "Bridged Host".
4. A resposta é enviada para "W-LAN AP"
5. "W-LAN AP" retransmite o pacote sem modificação pois a limitação de usar seu próprio MAC é dos clientes e não da estação.
6. "W-LAN Client" não sabe do que se trata tal pacote e ignora
7. "Bridged Host" nunca recebe uma resposta

Existem algumas soluções para este problema. Vou mostrar as mais interessantes.

WDS - Wireless Distribution System

A solução mais limpa e elegante é utilizar a tecnologia WDS. Com ela, a comunicação entre os equipamentos wireless preservam o MAC de origem. A figura é igual a anterior, com a diferença que, na comunicação entre o "W-LAN Client" e "W-LAN AP", é utilizado o padrão WDS.

Fonte:https://wiki.openwrt.org/doc/howto/clientmode

A figura mostra que existem 4 endereços MAC em todos os pacotes na comunicação wireless WDS: origem e destino das placas sem fio, e origem e destino dos dados. Assim, a informação das entidades envolvidas não é perdida e a comunicação pode se realizar. Porém, WDS depende da implementação do driver e dos softwares envolvidos. Se ambos forem o mesmo equipamento e com OpenWRT, não é problema. Se for com fornecedores diferentes, pode não funcionar.

Ponte com NAT (possivelmente duplo NAT)

Uma segunda solução seria transformar o equipamento "W-LAN Client" em um roteador, traduzindo os endereços por NAT.

Fonte:https://wiki.openwrt.org/doc/howto/clientmode

A conexão "W-LAN Client" funcionaria como uma conexão WAN. Isto é possível com o OpenWRT. Porém, seria a mesma situação do caso onde a ligação entre o roteador da internet e o roteador wireless era feita pela porta WAN: você terá duas NAT, os computadores da rede azul não falarão diretamente com os computadores da rede vermelha, exceto se existir um encaminhamento de porta.

Roteamento entre Redes

Uma última sugestão apresentada aqui seria o uso de roteamento. Ao invés de esconder os computadores atrás de uma NAT, usar uma outra subrede e configurar rotas estáticas nos roteadores da rede azul e vermelha.

Fonte:https://wiki.openwrt.org/doc/howto/clientmode

Esta é uma solução mais complexa de ser implementada. Porém, preserva a conectividade. Ainda assim, os computadores não estarão na mesma rede e algumas facilidades como a descoberta automática de serviços na rede local não irá funcionar entre as redes.

Ainda existem outras soluções como a utilização de um aplicativo que rastreia as conversas que passam pelo "W-LAN Client" e fazem a tradução dos endereços e outras alternativas baseadas em protocolos proprietários. Porém, acho que as 3 propostas apresentadas aqui são as mais recomendadas na maioria das situações.

No próximo artigo vou mostrar como transformar um segundo roteador em uma ponte entre as redes cabeadas e, ao mesmo tempo, um repetidor de sinal wireless.

Até a próxima.

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.