Discuta este tópico no fórum

Se este conteúdo te ajudou, deixe um presente!

terça-feira, 27 de setembro de 2011

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.