Cloud Intelligence™
Resolvendo sub-redes sobrepostas com Inter-VPC NAT no Google Cloud
Esta página também está disponível em English, Deutsch, Español, Français, Italiano e 日本語.
About Chimbu Chinnadurai
I've probably debugged a Kubernetes issue in more time zones than I care to count. Based in London, I help engineering teams across EMEA get their clusters to behave — and actually understand why they misbehaved in the first place.
I write, speak, and guest on podcasts about all things cloud-native. Away from the terminal: I enjoy cooking almost as much as simplifying overly complex systems.
My personal pageNa computação em nuvem, o gerenciamento de rede é peça-chave para que suas aplicações e serviços rodem sem sobressaltos.
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.
Cloud bill shouldn't be a mystery
One platform for AI and Cloud optimization.
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-playgroundexport 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-bexport VPC_B_SUBNET_C_CIDR="192.168.1.0/24" #overlapping subnet between vpc-a and vpc-bexport 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 subnetgcloud 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 subnetsgcloud 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_REGIONPasso 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/20Passo 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 NATgcloud 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 NATgcloud 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
Passo 5: crie instâncias de teste do Compute Engine sem IP externo.
#Test instance in vpc-a network and subnet-agcloud 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#Test instance in vpc-b network and subnet-b, Also deployed nginx service.Cloud NAT to download the required ngninx packages.gcloud compute instances create vpc-b-subnet-b-test \ --project=$PROJECT_ID \ --zone="us-west1-a" \ --machine-type=e2-medium \ --network-interface=stack-type=IPV4_ONLY,subnet=subnet-b,no-address \ --metadata=startup-script=\#/bin/sh$'\n'sudo\ \apt\ update$'\n'sudo\ apt\ install\ nginx\ -y\ \ --tags=http-server \ --create-disk=auto-delete=yes,boot=yes,device-name=vpc-b-subnet-b-test,image=projects/debian-cloud/global/images/debian-11-bullseye-v20230814,mode=rw,size=10,type=projects/$PROJECT_ID/zones/us-west1-a/diskTypes/pd-balanced
#Test instance deployed in vpc-b network and subnet-cgcloud compute instances create vpc-b-subnet-c-test \ --project=$PROJECT_ID \ --zone="us-west1-a" \ --machine-type=e2-medium \ --network-interface=stack-type=IPV4_ONLY,subnet=subnet-c,no-address \ --tags=http-server \ --create-disk=auto-delete=yes,boot=yes,device-name=vpc-b-subnet-c-test,image=projects/debian-cloud/global/images/debian-11-bullseye-v20230814,mode=rw,size=10,type=projects/$PROJECT_ID/zones/us-west1-a/diskTypes/pd-balanced
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.
gcloud network-connectivity hubs create private-nat-demo-vpc-hub
Passo 7: adicione as redes VPC como spokes ao hub. Lembre-se de excluir as redes sobrepostas da exportação.
#Add vpc-a to the hub and exclue VPC_A_SUBNET_A_CIDR from export.gcloud network-connectivity spokes linked-vpc-network create vpc-a \ --hub="https://www.googleapis.com/networkconnectivity/v1/projects/$PROJECT_ID/locations/global/hubs/private-nat-demo-vpc-hub" --global \ --vpc-network="https://www.googleapis.com/compute/v1/projects/$PROJECT_ID/global/networks/vpc-a" \ --exclude-export-ranges=$VPC_A_SUBNET_A_CIDR
#Add vpc-b to the hub and exclue VPC_B_SUBNET_C_CIDR from export.VPC_B_SUBNET_B_CIDR will be exported between the VPCs.gcloud network-connectivity spokes linked-vpc-network create vpc-b \ --hub="https://www.googleapis.com/networkconnectivity/v1/projects/$PROJECT_ID/locations/global/hubs/private-nat-demo-vpc-hub" --global \ --vpc-network="https://www.googleapis.com/compute/v1/projects/$PROJECT_ID/global/networks/vpc-b" \ --exclude-export-ranges=$VPC_B_SUBNET_C_CIDR
VPC Spokes
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.
gcloud beta compute networks subnets create private-nat-gateway \ --network=vpc-a \ --region=$VPC_A_SUBNET_REGION \ --range=$VPC_A_PRIVATE_NAT_GW_CIDR \ --purpose=PRIVATE_NAT
Passo 9: crie um cloud router e o gateway Private NAT.
gcloud compute routers create vpc-a-private-nat-gw-router \ --network="vpc-a" \ --region=$VPC_A_SUBNET_REGION
gcloud beta compute routers nats create vpc-a-private-nat-gw \ --router=vpc-a-private-nat-gw-router \ --type=PRIVATE \ --nat-all-subnet-ip-ranges \ --region=$VPC_A_SUBNET_REGIONPasso 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.
gcloud beta compute routers nats rules create 1000 \ --router=vpc-a-private-nat-gw-router \ --nat=vpc-a-private-nat-gw \ --match='nexthop.hub == "//networkconnectivity.googleapis.com/projects/chimbuc-playground/locations/global/hubs/private-nat-demo-vpc-hub"' \ --source-nat-active-ranges=private-nat-gateway \ --region=$VPC_A_SUBNET_REGION
Passo 11: crie uma regra de firewall na vpc-b para permitir as conexões vindas do gateway Private NAT.
gcloud compute firewall-rules create vpc-b-allow-ingress-private-nat-gw \ --direction=INGRESS \ --priority=1000 \ --network=vpc-b \ --action=ALLOW \ --rules=tcp \ --source-ranges=$VPC_A_PRIVATE_NAT_GW_CIDRPasso 12: teste a conectividade entre as redes vpc-a e vpc-b.
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.
