Como fazer replicação com mesmo IP para ambiente DR utilizando OCI e Rackware

Para quem está procurando uma solução para configurar o ambiente DR na Oracle Cloud com o mesmo bloco de IP da origem, fizemos um descritivo para configuração de um servidor de NAT. 

Cenário: A solução de replicação precisa conectar na Origem – 192.168.64.0/22 e irá replicar para uma VCN com o mesmo range de IP 192.168.64.0/22. Assim garantindo a funcionalidade de aplicações com Hardcode. Mascaramos o range inicial nos prints por questões de privacidade.

Servidores

  • ORIGEM – vcn-replica-teste-servidor
  • DESTINO – teste-nat
  • NAT – vcn-teste-servidor-nat
  • RMM – vcn-rmm-servidor-teste-nat-priv

Entrando no detalhe:

  1. Estabelecida a comunicação com ambiente de OCI via IPSec (caso tenha dúvidas de como fazê-la: https://docs.cloud.oracle.com/en-us/iaas/Content/Network/Tasks/managingIPsec.htm).

Rota de saída do ambiente On-premisses

2. A VCN-Manager 172.16.0.0/22 contempla 2 subnets – Sub-public e Subpriv, como podem ver, o range 172.14.0.0/16 precisa ser direcionado para a VCN-RMM. Para isso adicionamos uma rota de tráfego no DRG, apontando para um Private IP.

E aplicado a rota de saída para o ambiente on-premisses para a sub-priv

3. Agora vamos começar a falar do NAT.

Instance do Nat precisa ter um shape equivalente a quantidade de VCN que irá se comunicar.

Não por questões de processamento, mas por causa da quantidade de VNICs, o nosso cenário ficou da seguinte forma:

  • VNIC1 – 172.16.70.18 – Default acesso
  • VNIC2 – 172.14.1.10 – Dedicado para o NAT – VCN e Subnet do RMM
  • VNIC3 – 172.16.70.19 – Dedicado para o NAT

O ponto importante que me levou a configurar a rota usando uma VNIC para VCN do RMM, foi o fato de não conseguir configurar uma traffic route de um Local Peering apontando para outro Local Peering, pois construí primeiramente o cenário para comunicação de 2 VNCs com o mesmo IP, para prova de conceito. Mais abaixo mostro a topologia.

No modelo, utilizando o DRG, podemos sim utilizar o tráfego de rota direto para o LGP conectado a VCN-RMM, porém decidi manter o tráfego apontando para o IP privado que é o mesmo cenário de ida.

Configurando o NAT

Habilitar o Forward de IP nas interfaces

Esse comando escreve o número 1 dentro do arquivo ip_forward, ativando o roteamento de pacote. O padrão é 0. Com isso o Linux passa a rotear os pacotes de uma interface para a outra e vice-versa.

Habilitar o tráfego nas interfaces:

Vamos habilitar todo NAT

Detalhe dos comandos:

iptables -t nat -A POSTROUTING -o ens5 -j MASQUERADE

Mascara todos os pacotes que chegam na interface ens5 (VNIC 2) conforme descrito no PREROUTING

iptables -t nat -A PREROUTING -d 172.31.64.0/22 -j NETMAP –to 192.168.64.0/22

Aqui é estabelecido a regra de NAT, apontando todos os pacotes direcionados para 172.31.64.0/22 para rede 192.168.64.0/22.

Exemplo:

  • ping 172.31.64.10 -> será direcionado para -> ping 192.168.64.10
  • ping 172.31.65.52 -> será direcionado para -> ping 192.168.65.52
  • ping 172.31.66.29 -> será direcionado para -> ping 192.168.66.29

ip route add 192.168.64.0/22 via 172.16.70.17 dev ens6

Adicionando uma rota para comunicação com a rede 192.168 será sempre via interface da ens6 (VNIC3)

3. VCN-RMM – Conexão Origem e Destino

Configuramos 3 rotas na sub-priv

  • Rota 1 – Apontando a VNC de Destino – 192.168.64.0/22 para o LGP conectado a VCN-REPLICA.
  • Rota 2 – Apontando para VCN Manager 172.16.0.0/16 via Private IP 172.14.1.10 VNIC 2 do servidor de NAT.
  • Rota 3 – Apontando para a rede com mascaramento 172.31.0.0/16 via Private IP 172.14.1.10 VNIC 2 do servidor de NAT.

Essa é a topologia da VCN-RMM com a VCN-Replica:

3. VCN-Replica – Conexão para o VCN-RMM

Definição de uma rota para o Local Peering apontando a comunicação para 172.14.0.0/16 para o LPG-RMM

Vamos Testar!!!

Saindo do servidor do RMM localizado na VCN-RMM para a ORIGEM

OK, mas como ter certeza que a máquina de Origem é essa mesmo com IP 172.31? Vamos lá.

Saindo do servidor do RMM localizado na VCN-RMM para o DESTINO:

Topologia utilizando VCNs:

Esse cenário centraliza a comunicação entre os ambientes na VCN RMM, caso precise comunicar ida e volta dos pacotes entre as redes com o mesmo IP. Não é o melhor cenário para ambiente produtivos, mas pode ser necessário em tempos obscuros!

Se você tem interesse ou se ainda há duvidas sobre como fazer replicação com mesmo IP para ambiente DR utilizando OCI e Rackware, entre em contato com nosso time técnico especialista em soluções Oracle, deixando sua dúvida na aba contato na home do nosso site e breve falaremos com você!

Somos experts nestes assuntos e podemos ajudar nos negócios da sua empresa.

Matéria feita por nosso Head Oracle – Diego Mariano

Top