Por Chandini Penmetsa, Arquiteta de Soluções e
SaiJeevan Devireddy, Arquiteto de Soluções

Introdução

À medida que nossas necessidades de TI evoluem, uma das perguntas mais comuns que ouvimos dos clientes é: “Como gerencio meu espaço de endereço IP privado? Meus endereços IP estão prestes a se esgotar.”

É difícil atribuir intervalos de IP privados separados (RFC 1918) a diferentes unidades de negócios em uma organização porque o intervalo de endereços IPv4 disponível é restrito. Com a crescente popularidade da arquitetura baseada em microsserviços, em que cada tarefa ou pod precisa de seu próprio endereço IP, a necessidade de gerenciar o endereçamento IP está aumentando. Da mesma forma, quando uma organização cresce, os requisitos de endereços IP aumentam. E, eventualmente, eles ficarão sem intervalos de IP privados e serão forçados a usar intervalos de IP privados sobrepostos em algumas unidades de negócios. Isto torna mais difícil estabelecer conectividade entre as unidades de negócios com intervalos CIDR sobrepostos.

Para superar as limitações da sobreposição de endereços IP, os clientes podem implementar soluções como AWS PrivateLink, IPv6 ou usar dispositivos NAT (Network Address Translation) autogerenciados para traduzir endereços IPv4 e permitir a comunicação entre redes com intervalos CIDR sobrepostos. Na última abordagem, o gerenciamento de regras semelhantes ao NAT e a atribuição de endereços IP criarão uma sobrecarga operacional.

Atualmente, a AWS tem uma solução nativa em nuvem para fornecer a funcionalidade de tradução de endereços IPv4 entre ambientes privados, suportada pelo novo Private NAT Gateway. Neste blog, vamos ilustrar como usar um serviço gerenciado, como o Private NAT Gateway, para maximizar o consumo privado de IPv4 e permitir a comunicação entre redes com o mínimo de sobrecarga operacional.

Visão geral da solução:

Essa solução ilustra um mecanismo para conservar e gerenciar a alocação do espaço de endereço IP RFC1918 usando o conceito de intervalos IP roteáveis e não roteáveis. Além disso, a solução descreve como conectar intervalos CIDR sobrepostos usando um gateway NAT privado que está no espaço IP não sobreposto (ou roteável).

Se uma unidade de negócios dentro de uma organização quiser implantar uma carga de trabalho que exija o uso de milhares de endereços IP, a carga de trabalho será implantada na faixa de endereços IP não roteáveis. O espaço IP não roteável é usado por muitas outras unidades de negócios e a natureza sobreposta desse espaço o torna não roteável. A carga de trabalho receberá uma pequena variedade de endereços IP roteáveis pela equipe centralizada de Gerenciamento de Endereços IP (IPAM). O intervalo de IP roteável atribuído pode ser usado por unidades de negócios individuais para se conectar à rede consolidada. Ao identificar espaços IP roteáveis e não roteáveis, use intervalos CIDR compatíveis, pois os blocos CIDR que podem ser unidos como CIDR secundário a uma VPC são restritos com base no bloco CIDR primário da VPC.

O diagrama a seguir (Figura 1) mostra como usar o AWS Transit Gateway e o NAT privado para resolver o problema de esgotamento de IP e permitir a comunicação entre duas Amazon Virtual Private Clouds (VPCs) com intervalos CIDR sobrepostos.

Figura 1: Diagrama da arquitetura

Revisão da Arquitetura:

Nesta seção, usaremos intervalos de endereços IP roteáveis e não roteáveis para estabelecer a conectividade do VPC-A ao VPC-B com CIDR sobreposto usando o gateway NAT privado. Este passo a passo é dividido em três seções da seguinte forma:

1. Identificar o espaço de endereço IP roteável
2. Alocar espaço de endereço IP
3. Configurar o roteamento para ativar a conectividade

1. Identificar o espaço de endereço IP roteável:

Para intervalos de endereços não roteáveis, qualquer intervalo de endereços IPv4, incluindo RFC 1918 ou intervalos de IP roteáveis publicamente, podem ser usados como o bloco CIDR secundário da VPC. Várias equipes podem usar o mesmo intervalo de endereços secundários e, portanto, devem ser tratados como não roteáveis. Lembre-se de que há algumas restrições ao atribuir endereços IP em uma VPC.

O espaço roteável é cuidadosamente alocado pela equipe de gerenciamento de IP a partir do pool central de IP roteável. Apenas o espaço IP roteável é exclusivo e anunciado na rede consolidada da organização por meio do Transit Gateway ou da Virtual Private Gateway.

2. Alocar o espaço do endereço IP:

Neste blog, a equipe do projeto fornece às VPCs o CIDR primário do intervalo roteável e usa o intervalo CIDR não roteável como o CIDR secundário. Neste passo a passo, os endereços IP não roteáveis e roteáveis são atribuídos da seguinte forma:

Para o intervalo de endereços não roteável, atribuímos 100.64.0.0/16, o intervalo IP do Espaço de Endereços Compartilhado (RFC 6598: ou seja, 100.64.0.0/10) como CIDR secundário para VPC-A e VPC-B. Para o intervalo de endereços roteáveis, atribuímos 10.0.1.0/24 ao VPC-A e 10.0.2.0/24 ao VPC-B como os intervalos de endereços principais desde o RFC1918. Esses intervalos CIDR foram selecionados após garantir a compatibilidade com as limitações da adição de um bloco CIDR secundário à VPC, conforme descrito na seção “Visão geral da solução”.

A atribuição de endereços IP para VPC-A e VPC-B é representada no diagrama a seguir (Figura 2).

3. Configurar o roteamento para ativar a conectividade:

Agora que atribuímos os intervalos de IP primário e secundário para a VPC-A e a VPC-B, vamos configurar o roteamento para permitir a conectividade entre a VPC-A e a VPC-B. Estamos usando um Application Load Balancer (ALB) interno para expor recursos na sub-rede não roteável dentro da VPC-B. Um Private NAT Gateway é implementado na VPC-A para a fornecer ao NAT de origem, o IP não roteável para um IP roteável na VPC-A.

Para alcançar esse estado de conectividade desejado:

1. O ALB é colocado nas sub-redes roteáveis na VPC-B e as instâncias de back-end nas sub-redes não roteáveis na VPC-B.
2. O gateway NAT privado é criado nas sub-redes roteáveis na VPC-A e o “SourceInstance-VPC-A” é criado nas sub-redes não roteáveis da VPC-A para testar a conectividade.
3. Dois anexos do Transit Gateway (Transit Gateway Attachment) são criados nas sub-redes roteáveis VPC-A e VPC-B.

Agora que entendemos a arquitetura, vamos passar pela vida útil de um pacote quando “SourceInstance-VPC-A” no VPC-A se comunica com o ALB na VPC-B.

Fluxo de pacotes de SourceInstance-VPC-A para o servidor web:

• Etapa 1: “SourceInstance-VPC-A” no VPC-A quer se comunicar com o servidor web no VPC-B, que está localizado atrás do ALB no VPC-B. Como resultado, o pacote é originário do “SourceInstance-VPC-A” (IP de origem: 100.64.0.10/32) e é direcionado para o ALB. O “SourceInstance-VPC-A” realizará uma pesquisa de DNS no nome DNS do ALB para obter o IP de destino (10.0.2.x/32). A “Sub-rede não roteável” na VPC-A está configurada para direcionar o tráfego destinado a 10.0.2.0/24 para o gateway NAT privado.
• Etapa 2: O gateway NAT privado converte o IP de origem de um endereço IP não roteável para um endereço IP roteável e, em seguida, envia o tráfego para o anexo do Transit Gateway na VPC-A porque está associado à tabela de rotas “Routable Subnet-RT” na VPC-A.
• Etapa 3: O Transit Gateway usa a rota 10.0.2.0/24 e envia tráfego para o anexo da VPC-B Transit Gateway.
• Etapa 4: O TGW ENI na VPC-B usa a rota VPC-B local para encaminhar o tráfego para o ALB, que então encaminha o tráfego para o servidor web atrás do ALB.

Etapas para retornar o tráfego do servidor web para SourceInstance-VPC-A:

• Etapa 5: O servidor web por trás do ALB recebe a solicitação enviada pela instância “SourceInstance-VPC-A” e retorna uma resposta ao ALB usando o caminho local VPC-B.
• Etapa 6: O ALB encaminha o tráfego de resposta para o acessório de gateway de trânsito na VPC-B porque está associado à tabela de rotas “Routable Subnet-RT” na VPC-B. Esse tráfego de resposta do ALB tem o endereço IP de origem do ALB e o endereço IP de destino do gateway NAT privado.
• Etapa 7: O Transit Gateway usa a rota 10.0.1.0/24 e envia tráfego para o anexo VPC-A Transit Gateway.
• Etapa 8: O ENI TGW na VPC-A usa a rota local para encaminhar o tráfego para o gateway NAT privado, que então traduz o IP de destino para o da instância “SourceInstance-VPC-A”. Esse pacote é roteado para “SourceInstance-VPC-A” usando o caminho local.

Pré-requisitos:

Para concluir este laboratório, você precisa:

1. Uma conta da AWS
2. Um usuário do IAM com acesso aos recursos da AWS, incluindo Systems Manager, AWS Transit Gateway, VPC e Amazon EC2.

Instruções de implementação:

Nesta seção, demonstramos como implementar a arquitetura da Figura 1, incluindo Transit Gateway, VPC, sub-redes, gateway NAT privado, tabelas de rotas do Transit Gateway, tabelas de rotas do VPC, Application Load Balancer (ALB), EC2 etc., usando o modelo do CloudFormation fornecido.

1. Clique em
2. Por padrão, o link leva você à página Create Stack no console do CloudFormation na região de Norte da Virgínia (us-east-1) e o modelo do CloudFormation da solução é preenchido automaticamente. Você pode alterar a região no canto superior direito do console, se necessário.

   

   Figura 4: Criar a pilha do CloudFormation

3. Insira um nome para a pilha em Nome da pilha e todos os parâmetros necessários serão preenchidos com os valores padrão. Em nosso ambiente de demonstração, escolhemos chamar nossa pilha de “PrivateNatGatewayDemo”. Clique em “Criar pilha” para continuar.

Validação:

1. Para se conectar à instância SourceInstance-VPC-A com segurança usando o Session Manager, selecione o ID da instância no console do EC2 e clique no botão Conectar.
2. Há quatro maneiras diferentes de se conectar à instância do EC2. Selecione a guia Gerenciador de sessões e clique em Conectar, o que abre uma nova sessão baseada em Shell (browser-based shell) no navegador da sua instância. Atente-se que pode levar alguns minutos para se conectar à instância SourceInstance-VPC-A por meio do Gerenciador de Sessões.

1. Para verificar se o “SourceInstance-VPC-A” pode acessar o serviço web em execução na VPC-B (100.64.0.0/24 sub-rede não roteável), use curl para conectar o nome DNS ALB (consulte o valor albHostName na seção de saída da pilha do CloudFormation).

curl <ALB DNS>

Limpeza:

Depois de testar a conectividade, exclua a pilha do CloudFormation para evitar quaisquer custos associados aos recursos lançados pelo modelo do CloudFormation.

Conclusão:

Neste post, você aprendeu a usar intervalos de IP CIDR roteáveis e não roteáveis em conjunto com o AWS Transit Gateway e o Private NAT Gateway para resolver o problema de esgotamento do IP privado e permitir a comunicação entre duas Amazon VPCs com intervalos CIDR sobrepostos. Observe que esta ilustração mostra como estabelecer conectividade entre duas VPCs com CIDRs sobrepostas, a mesma pode ser estendida para uma VPC e uma rede local ou para duas redes locais com CIDRs sobrepostos.

Este artigo foi traduzido do Blog de AWS en Inglês

Sobre o autor

Chandini Penmetsa é arquiteta de infraestrutura de nuvem com os serviços profissionais da AWS. Ele gosta de ajudar os clientes na implementação de soluções complicadas como parte de sua jornada para a nuvem.

SaiJeevan Devireddy é arquiteto de soluções na AWS e trabalha com parceiros do setor público. Ele é apaixonado por ajudar os clientes a projetar e criar sistemas altamente disponíveis na AWS.

Revisores

Servio Reyes é arquiteto de soluções na AWS México.

Alejandro Guevara

Efraín Castilla é arquiteto de soluções com mais de 20 anos de experiência no setor. Seu objetivo é apoiar os clientes da AWS na criação de soluções inovadoras usando os serviços da AWS, considerando as melhores práticas.

Ana Falcão é Business Intelligence Engineer na AWS Brasil