Sub-redes sobrepostas: como resolver com Inter-VPC NAT no Google Cloud

Na computação em nuvem, o gerenciamento de rede é peça-chave para que suas aplicações e serviços rodem sem sobressaltos.

Overcoming-Overlapping-Subnet-Challenges-with-Inter-VPC-NAT-in-GCP

Foto de Ar_TH no Shutterstock

Introdução

Na computação em nuvem, o gerenciamento de rede é peça-chave para que suas aplicações e serviços rodem sem sobressaltos. Um dos pilares desse gerenciamento é a alocação de endereços IP (Internet Protocol) para os diversos recursos do seu ambiente em nuvem. Esses endereços funcionam como uma identidade digital, permitindo que os recursos conversem entre si e com a internet.

Ao desenhar uma rede, seja em um ambiente on-premises tradicional ou em uma plataforma como o Google Cloud Platform (GCP), você esbarra nos conceitos de faixas de IP sobrepostas e não sobrepostas.

Faixas de IP sobrepostas acontecem quando duas ou mais faixas compartilham endereços em comum — ou seja, se sobrepõem.

Faixas de IP não sobrepostas são conjuntos de endereços em que cada IP é único e não cruza com endereços de outra faixa.

Cada rede Virtual Private Cloud (VPC) no GCP é formada por uma ou mais sub-redes, que podem ou não se sobrepor às faixas de IP de outras VPCs. É fundamental usar uma faixa de IP não sobreposta nas sub-redes, já que, por padrão, o acesso privado à rede não é permitido entre sub-redes sobrepostas.

No meu artigo anterior, mostrei como usar o Private Service Connect (PSC) para acessar de forma privada serviços em redes VPC com faixas de IP sobrepostas.

Recentemente, o GCP lançou o Private NAT em Preview, com o objetivo de viabilizar a comunicação privada entre redes sobrepostas. Neste artigo, vamos ver como configurar o Inter-VPC NAT para acessar de forma privada serviços que rodam em redes VPC distintas e que contêm faixas de IP sobrepostas e não sobrepostas.

O que é o Inter-VPC NAT?

No GCP, o VPC peering não é permitido entre redes sobrepostas, porque ele não admite o compartilhamento de sub-redes específicas entre VPCs. O Inter-VPC NAT é uma modalidade de gateway Private NAT que permite que recursos de uma VPC em sub-redes sobrepostas se comuniquem com recursos em sub-redes não sobrepostas de outra VPC — mesmo quando outras sub-redes se sobrepõem — usando uma configuração NAT do tipo type=PRIVATE.

Ele funciona em conjunto com o Network Connectivity Center, um sistema unificado e simplificado de gerenciamento de conectividade. A proposta é reunir, em uma única interface, os diferentes recursos de rede do Google Cloud, facilitando a conexão e o gerenciamento das suas redes na nuvem e on-premises.

O Network Connectivity Center adota um modelo hub-and-spoke. O hub é o ponto central de conectividade entre suas redes Virtual Private Cloud (VPC) — pense nele como um roteador virtual que agrega a conectividade de vários spokes. Os spokes podem ser VPNs, Interconnects, roteadores de terceiros ou outras redes VPC.

Para habilitar o Inter-VPC NAT entre redes VPC, é preciso configurar cada uma delas como um VPC spoke de um hub do Network Connectivity Center. Os VPC spokes permitem conectar várias VPCs e trocar rotas específicas de sub-redes IPv4 — algo que não é possível com VPC peering. Isso garante conectividade IPv4 completa entre todos os workloads dessas redes.

Ao criar o spoke, você precisa impedir que as faixas de IP sobrepostas sejam compartilhadas com os demais VPC spokes.

Limitações

No momento, o Inter-VPC NAT em Preview tem as seguintes limitações principais.

O Inter-VPC NAT não oferece suporte a Endpoint-Independent Mapping.
O suporte a Inter-VPC NAT entre projetos não está disponível em Preview.
O suporte a logs do Inter-VPC NAT não está disponível em Preview.
Em Preview, é obrigatório usar somente a CLI gcloud para atualizar qualquer gateway Private NAT existente. Atualizar um gateway Private NAT pelo console do Google Cloud pode gerar configurações incorretas.
O Inter-VPC NAT só oferece suporte a conexões TCP e UDP.
O Inter-VPC NAT realiza network address translation (NAT) apenas entre VPC spokes do Network Connectivity Center, e não entre redes Virtual Private Cloud conectadas via VPC Network Peering.
Uma instância de máquina virtual (VM) em uma rede VPC só consegue acessar destinos em uma sub-rede não sobreposta de uma rede em peering — nunca em uma sub-rede sobreposta.

O GCP pode remover algumas dessas restrições antes do GA. Acompanhe a documentação oficial para ficar por dentro das atualizações.

Arquitetura de referência

Nesta configuração, vpc-a e vpc-b têm uma sub-rede com faixa de IP sobreposta. A vpc-b também conta com uma sub-rede não sobreposta, que hospeda uma aplicação de exemplo.

Um gateway Private NAT será implantado na vpc-a para permitir que instâncias da sub-rede sobreposta se conectem à aplicação de exemplo na sub-rede não sobreposta.

alttext

Exemplo de fluxo do Private NAT

Configurar a rede e implantar a aplicação de exemplo

Passo 1: defina as variáveis de ambiente necessárias.

export PROJECT_ID="your-project-id" #ex: chimbu-playground
export VPC_A_SUBNET_REGION="us-east1"
export VPC_A_SUBNET_A_CIDR="192.168.1.0/24"
export VPC_B_SUBNET_REGION="us-west1"
export VPC_B_SUBNET_B_CIDR="192.168.2.0/24" #non-overlapping subnet between vpc-a and vpc-b
export VPC_B_SUBNET_C_CIDR="192.168.1.0/24" #overlapping subnet between vpc-a and vpc-b
export VPC_A_PRIVATE_NAT_GW_CIDR="10.1.2.0/29"

Passo 2: crie as redes VPC e as sub-redes.

#Create vpc-a custom Network and subnet
gcloud beta compute networks create vpc-a \
  --subnet-mode=custom

gcloud beta compute networks subnets create subnet-a \
  --network="vpc-a" \
  --role="ACTIVE" \
  --purpose="PRIVATE" \
  --range=$VPC_A_SUBNET_A_CIDR  \
  --region=$VPC_A_SUBNET_REGION

# Create vpc-b custom Network and subnets
gcloud beta compute networks create vpc-b \
  --subnet-mode=custom

gcloud beta compute networks subnets create subnet-b \
  --network="vpc-b" \
  --role="ACTIVE" \
  --purpose="PRIVATE" \
  --range=$VPC_B_SUBNET_B_CIDR  \
  --region=$VPC_B_SUBNET_REGION

gcloud beta compute networks subnets create subnet-c \
  --network="vpc-b" \
  --role="ACTIVE" \
  --purpose="PRIVATE" \
  --range=$VPC_B_SUBNET_C_CIDR  \
  --region=$VPC_B_SUBNET_REGION

Passo 3: crie regras de firewall para o Identity-Aware Proxy (IAP) TCP forwarding, liberando o acesso SSH às instâncias VM.

Nos passos seguintes, vamos criar instâncias VM sem IP externo. O IAP TCP forwarding permite que os usuários estabeleçam um túnel criptografado para encaminhar tráfego SSH, RDP e outros até as instâncias VM.

Confirme se os usuários têm o papel roles/iap.tunnelResourceAccessor atribuído para executar o TCP forwarding e tarefas relacionadas.

gcloud compute firewall-rules create vpc-a-iap \
  --direction=INGRESS \
  --priority=1000 \
  --network=vpc-a \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20

gcloud compute firewall-rules create vpc-b-iap \
  --direction=INGRESS \
  --priority=1000 \
  --network=vpc-b \
  --action=ALLOW \
  --rules=tcp:22 \
  --source-ranges=35.235.240.0/20

Passo 4: crie uma instância do Cloud NAT para acesso à internet. Essa instância não habilita comunicação privada entre VPCs — isso será feito separadamente.

#vpc-a Cloud router and NAT
gcloud compute routers create vpc-a-internet-nat-router \
  --network=vpc-a \
  --region=$VPC_A_SUBNET_REGION

gcloud beta compute routers nats create vpc-a-internet-nat \
  --router=vpc-a-internet-nat-router \
  --nat-all-subnet-ip-ranges \
  --region=$VPC_A_SUBNET_REGION \
  --auto-allocate-nat-external-ips

#vpc-b Cloud router and NAT
gcloud compute routers create vpc-b-internet-nat-router \
  --network=vpc-b \
  --region=$VPC_B_SUBNET_REGION

gcloud beta compute routers nats create vpc-b-internet-nat \
  --router=vpc-b-internet-nat-router \
  --nat-all-subnet-ip-ranges \
  --region=$VPC_B_SUBNET_REGION \
  --auto-allocate-nat-external-ips

Cloud

Passo 5: crie instâncias de teste do Compute Engine sem IP externo.

#Test instance in vpc-a network and subnet-a
gcloud compute instances create vpc-a-subnet-a-test \
  --project=$PROJECT_ID \
  --zone="us-east1-b" \
  --machine-type=e2-medium \
  --network-interface=stack-type=IPV4_ONLY,subnet=subnet-a,no-address \
  --tags=http-server \
  --create-disk=auto-delete=yes,boot=yes,device-name=vpc-a-subnet-a-test,image=projects/debian-cloud/global/images/debian-11-bullseye-v20230814,mode=rw,size=10,type=projects/$PROJECT_ID/zones/us-east1-b/diskTypes/pd-balanced

Compute

Neste ponto do processo, a instância vpc-a-subnet-a-test na vpc-a não consegue acessar o serviço que roda na instância vpc-b-subnet-b-test, porque não há conectividade de rede — e não dá para criar VPC peering entre as redes por causa da sub-rede sobreposta.

Configurar Hub e VPC Spokes no Network Connectivity Center

Para que duas redes VPC com faixas de IP de sub-rede sobrepostas consigam se comunicar, é preciso configurá-las como VPC spokes ligados ao mesmo hub do Network Connectivity Center.

Passo 6: crie um hub do Network Connectivity Center.

Passo 7: adicione as redes VPC como spokes ao hub. Lembre-se de excluir as redes sobrepostas da exportação.

VPC

VPC Spokes

Exchanged

Rota trocada entre as VPCs

Configurar o Inter-VPC NAT

O Inter-VPC NAT exige uma sub-rede dedicada com a finalidade PRIVATE_NAT. O gateway Private NAT usa faixas de IP dessa sub-rede para realizar o NAT. Ela não pode se sobrepor a nenhuma sub-rede já existente nos VPC spokes ligados ao mesmo hub do Network Connectivity Center, e é usada exclusivamente para o Private NAT.

Passo 8: crie uma sub-rede para o Private NAT. Ela ficará na vpc-a, já que precisa acessar o serviço que roda na vpc-b. O Private NAT executa NAT apenas em requisições de saída.

Create

Passo 9: crie um cloud router e o gateway Private NAT.

Passo 10: crie uma regra NAT no gateway Private NAT para aplicar NAT no tráfego que sai pelo VPC spoke de origem em direção a qualquer VPC spoke par conectado ao mesmo hub do Network Connectivity Center. Com base nessa regra, o gateway Private NAT atribui endereços IP de NAT a partir da sub-rede Private NAT.

Private

Passo 11: crie uma regra de firewall na vpc-b para permitir as conexões vindas do gateway Private NAT.

Passo 12: teste a conectividade entre as redes vpc-a e vpc-b.

non-overlapping

Pela captura de tela, dá para confirmar que a instância na vpc-a consegue acessar o serviço que roda na sub-rede não sobreposta da vpc-b via Inter-VPC NAT.

O Inter-VPC NAT é uma ferramenta poderosa para simplificar a comunicação privada entre redes sobrepostas. Com ele, um recurso pode se comunicar de forma privada com recursos em sub-redes não sobrepostas de outra VPC, mesmo estando em uma sub-rede que se sobrepõe a outras.

Use o Private Service Connect para habilitar a comunicação privada entre sub-redes sobrepostas. Espero que este post tenha sido útil. Se tiver alguma dúvida, é só falar comigo.