Foto de Ar_TH no Shutterstock
Introdução
No amplo cenário da computação em nuvem, gerenciar a 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) aos diversos recursos do seu ambiente em nuvem. Esses endereços funcionam como uma identificação digital dos recursos, permitindo que eles se comuniquem entre si e com a internet.
Ao projetar 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 ocorrem quando duas ou mais faixas de endereços compartilham IPs 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 coincide 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. Usar faixas não sobrepostas é fundamental, porque, por padrão, o GCP não permite acesso privado entre sub-redes sobrepostas.
No meu artigo anterior, mostrei como usar o Private Service Connect (PSC) para acessar serviços de forma privada em redes VPC com faixas de IP sobrepostas.
Recentemente, o GCP lançou em Preview o Private NAT, que tem como objetivo 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 diferentes redes VPC, com 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, já que ele não suporta o compartilhamento de sub-redes específicas entre VPCs. O Inter-VPC NAT é um 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 que existam outras sub-redes sobrepostas — usando uma configuração de NAT com type=PRIVATE.
Ele funciona em conjunto com o Network Connectivity Center, um sistema unificado e simplificado para gerenciar conectividade de rede. A ideia é reunir as diferentes capacidades de rede do Google Cloud em uma única interface, facilitando a conexão e o gerenciamento das suas redes em nuvem e on-premises.
O Network Connectivity Center adota um modelo hub-and-spoke. O hub é o ponto central de conectividade para 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 como um VPC spoke de um hub do Network Connectivity Center. Os VPC spokes permitem conectar várias redes VPC e trocar rotas específicas de sub-redes IPv4, algo que não é possível no VPC peering. Com isso, você obtém conectividade IPv4 completa entre todos os workloads dessas redes VPC.
Ao criar o spoke, você precisa impedir que as faixas de IP sobrepostas sejam compartilhadas com os demais VPC spokes.
Limitações
Atualmente, em Preview, o Inter-VPC NAT tem as seguintes limitações principais:
- O Inter-VPC NAT não oferece suporte a Endpoint-Independent Mapping.
- O suporte do Inter-VPC NAT entre projetos não está disponível em Preview.
- O suporte a logging para o Inter-VPC NAT não está disponível em Preview.
- Em Preview, use apenas a CLI gcloud para atualizar qualquer gateway Private NAT existente. Atualizá-lo pelo console do Google Cloud pode gerar uma configuração incorreta.
- O Inter-VPC NAT suporta apenas conexões TCP e UDP.
- O Inter-VPC NAT faz network address translation (NAT) somente 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 sub-redes não sobrepostas em uma rede pareada — nunca em sub-redes sobrepostas.
O GCP pode remover algumas dessas limitações antes de o serviço entrar em GA. Consulte a documentação oficial para acompanhar as 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 tem 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.
https://cloud.google.com/nat/docs/private-nat#pvt-nat-flow-example
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 encaminhamento TCP do Identity-Aware Proxy (IAP) e habilitar o acesso SSH às VMs.
Nos próximos passos, vamos criar VMs sem IP externo. O encaminhamento TCP do IAP cria um túnel criptografado pelo qual é possível encaminhar SSH, RDP e outros tipos de tráfego para essas VMs.
Confira se os usuários têm a função roles/iap.tunnelResourceAccessor para realizar o encaminhamento TCP 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 de Cloud NAT para o acesso à internet. Ela não habilita comunicação privada entre VPCs — isso será feito à parte.
#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 NAT para acesso à internet pelas instâncias do Compute Engine na rede
Passo 5: crie instâncias de teste no 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
#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-c
gcloud 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
Instâncias do Compute Engine
Até aqui, a instância vpc-a-subnet-a-test da vpc-a não consegue acessar o serviço que roda na vpc-b-subnet-b-test: não há conectividade de rede e também 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 habilitar a comunicação entre duas redes VPC com sub-redes de IP sobrepostas, configure-as 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. Não esqueça 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 as faixas de IP dessa sub-rede para fazer o NAT. Ela não pode se sobrepor a nenhuma sub-rede existente nos VPC spokes ligados ao mesmo hub do Network Connectivity Center, e seu uso é exclusivo do Private NAT.
Passo 8: crie a sub-rede para o Private NAT na vpc-a, já que é ela que precisa acessar o serviço em execução na vpc-b. O Private NAT só faz NAT para 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_REGION
Passo 10: crie uma regra de NAT no gateway Private NAT para fazer NAT no tráfego que sai pelo VPC spoke de origem em direção a qualquer VPC spoke par ligado a um hub correspondente do Network Connectivity Center. Com base nessa regra, o gateway Private NAT atribui IPs de NAT a partir da sub-rede do Private NAT para tratar o tráfego.
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
Private NAT Gateway
Passo 11: crie uma regra de firewall na vpc-b para liberar as conexões originadas no 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_CIDR
Passo 12: teste a conectividade entre as redes vpc-a e vpc-b.
A captura de tela confirma que a instância da 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, você garante que um recurso possa se comunicar de forma privada com recursos em sub-redes não sobrepostas de outra VPC, mesmo quando esse recurso está em uma sub-rede que tem sobreposição com outras.
Use o Private Service Connect para habilitar comunicação privada entre sub-redes sobrepostas. Espero que este post tenha sido útil — se ficou com alguma dúvida, é só me chamar.