Foto de Ar_TH en Shutterstock
Introducción
En el amplio panorama del cómputo en la nube, la gestión de la red es un componente clave para que tus aplicaciones y servicios funcionen sin contratiempos. Un aspecto fundamental de esa gestión es la asignación de direcciones IP (Internet Protocol) a los distintos recursos de tu entorno cloud. Estas direcciones IP funcionan como la identificación digital de tus recursos en la nube y les permiten comunicarse entre sí y con internet.
Al diseñar una red, ya sea en un entorno tradicional on-premises o en una plataforma cloud como Google Cloud Platform (GCP), te encuentras con los conceptos de rangos de direcciones IP superpuestos y no superpuestos.
Los rangos de IP superpuestos ocurren cuando dos o más rangos de direcciones IP comparten direcciones en común; es decir, se traslapan entre sí.
Los rangos de IP no superpuestos son un conjunto de direcciones IP en el que cada dirección es única y no se cruza ni se traslapa con direcciones de otro rango.
Cada red Virtual Private Cloud (VPC) en GCP está formada por una o más subredes, que pueden estar superpuestas o no con los rangos de direcciones IP de otras VPCs. Es fundamental usar un rango de IP no superpuesto para las subredes, ya que el acceso a la red privada no se permite por defecto entre subredes superpuestas.
En mi artículo anterior expliqué cómo usar Private Service Connect (PSC) para acceder de forma privada a servicios en redes VPC con rangos de IP superpuestos.
Recientemente, GCP lanzó Private NAT en versión Preview, con el objetivo de facilitar la comunicación privada entre redes superpuestas. En este artículo veremos cómo configurar Inter-VPC NAT para acceder de forma privada a servicios que corren en distintas redes VPC con rangos de IP superpuestos y no superpuestos.
¿Qué es **Inter-VPC NAT?**
En GCP, el VPC peering no se permite entre redes superpuestas, ya que no admite compartir subredes específicas entre VPCs. Inter-VPC NAT es una opción de Private NAT gateway que permite a los recursos de una red VPC en subredes superpuestas comunicarse con recursos en subredes no superpuestas a través de otra VPC —incluso si otras subredes sí se traslapan— mediante una configuración NAT de type=PRIVATE.
Funciona junto con Network Connectivity Center, un sistema de gestión de conectividad de red unificado, integral y simplificado. Está diseñado para reunir las distintas capacidades de red de Google Cloud en una sola interfaz, lo que facilita conectar y administrar tus redes en la nube y on-premises.
Network Connectivity Center utiliza un modelo hub-and-spoke para la conectividad de red. Un hub es un punto central de conectividad hacia tus redes Virtual Private Cloud (VPC). Puedes pensarlo como un router virtual que agrega la conectividad de varios spokes. Los spokes pueden ser VPNs, Interconnects, routers de terceros u otras redes VPC.
Para habilitar Inter-VPC NAT entre redes VPC, debes configurar cada red VPC como un VPC spoke de un hub de Network Connectivity Center. Los VPC spokes permiten conectar varias redes VPC e intercambiar rutas específicas de subredes IPv4, algo que no es posible con VPC peering. Así se obtiene conectividad IPv4 completa entre todos los workloads que residen en estas redes VPC.
Al crear el spoke, debes evitar que los rangos de direcciones IP superpuestos se compartan con otros VPC spokes.
Limitaciones
Inter-VPC NAT presenta actualmente las siguientes limitaciones clave en Preview.
- Inter-VPC NAT no admite Endpoint-Independent Mapping.
- Inter-VPC NAT con soporte cross-project no está disponible en Preview.
- El soporte de logging para Inter-VPC NAT no está disponible en Preview.
- En Preview, debes usar únicamente la CLI de gcloud para actualizar cualquier Private NAT gateway existente. Hacerlo desde la consola de Google Cloud puede dejar una configuración incorrecta.
- Inter-VPC NAT solo admite conexiones TCP y UDP.
- Inter-VPC NAT solo admite la traducción de direcciones de red (NAT) entre Network Connectivity Center Virtual Private Cloud (VPC) spokes, y no con redes Virtual Private Cloud conectadas mediante VPC Network Peering.
- Una instancia de máquina virtual (VM) en una red VPC solo puede acceder a destinos en una subred no superpuesta de una red emparejada, no en una subred superpuesta.
Es posible que GCP elimine algunas limitaciones antes de que el servicio pase a GA. Consulta los docs oficiales para ver las novedades.
Arquitectura de referencia
En esta configuración, vpc-a y vpc-b tienen una subred con un rango de direcciones IP superpuesto. vpc-b también cuenta con una subred no superpuesta que aloja una aplicación de muestra.
Se desplegará un Private NAT gateway en vpc-a para que las instancias de la subred superpuesta puedan conectarse a la aplicación de muestra en la subred no superpuesta.
https://cloud.google.com/nat/docs/private-nat#pvt-nat-flow-example
Configurar la red y desplegar la aplicación de muestra
Paso 1: configura las variables de entorno necesarias.
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"
Paso 2: crea las redes VPC y las subredes.
#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
Paso 3: crea reglas de firewall para el TCP forwarding de Identity-Aware Proxy (IAP) y habilita el acceso SSH a las instancias de VM.
En los pasos siguientes crearemos instancias de VM sin IPs externas, y el TCP forwarding de IAP permite establecer un túnel cifrado para reenviar SSH, RDP y otro tráfico hacia esas instancias.
Asegúrate de que los usuarios tengan asignado el rol roles/iap.tunnelResourceAccessor para realizar TCP forwarding y tareas 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
Paso 4: crea una instancia de Cloud NAT para el acceso a internet. Esta instancia de Cloud NAT no permite la comunicación privada entre VPCs; eso se configurará por separado.
#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 el acceso a internet de las instancias de Compute Engine en la red
Paso 5: crea instancias de prueba en Compute Engine sin IP externa.
#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
Instancias de Compute Engine
Hasta este punto, la instancia vpc-a-subnet-a-test en vpc-a no puede acceder al servicio que corre en la instancia vpc-b-subnet-b-test porque no hay conectividad de red, y tampoco se puede crear VPC peering entre ambas redes debido a la subred superpuesta.
Configurar Hub y VPC Spokes en Network Connectivity Center
Para habilitar la comunicación entre dos redes VPC con rangos de IP de subred superpuestos, debes configurar las redes VPC como VPC spokes conectados al mismo hub de Network Connectivity Center.
Paso 6: crea un hub de Network Connectivity Center.
gcloud network-connectivity hubs create private-nat-demo-vpc-hub
Paso 7: agrega las redes VPC como Spokes al Hub. Asegúrate de excluir de la exportación las redes superpuestas.
#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
Ruta intercambiada entre las VPCs
Configurar Inter-VPC NAT
Inter-VPC NAT requiere una subred dedicada con propósito PRIVATE_NAT. El Private NAT gateway usa rangos de direcciones IP de esta subred para hacer el NAT. Esta subred no debe traslaparse con ninguna subred existente en los VPC spokes vinculados al mismo hub de Network Connectivity Center y se usa únicamente para Private NAT.
Paso 8: crea una subred para Private NAT. Se creará en vpc-a, ya que necesita acceder al servicio que corre en vpc-b. Private NAT solo aplica NAT a las solicitudes salientes.
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
Paso 9: crea un cloud router y un Private NAT gateway.
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
Paso 10: crea una regla NAT en el Private NAT gateway para aplicar NAT al tráfico que sale del VPC spoke de origen hacia cualquiera de los VPC spokes pares vinculados a un hub de Network Connectivity Center coincidente. Según la regla NAT, el Private NAT gateway asigna direcciones IP NAT desde la subred de Private NAT para aplicar NAT al tráfico.
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
Paso 11: crea una regla de firewall en vpc-b para permitir las conexiones provenientes del Private NAT gateway.
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
Paso 12: prueba la conectividad entre las redes vpc-a y vpc-b.
En la captura se confirma que la instancia en vpc-a puede acceder al servicio que corre en la subred no superpuesta de vpc-b mediante Inter-VPC NAT.
Inter-VPC NAT es una herramienta potente que simplifica la comunicación privada entre redes superpuestas. Al usarla, se garantiza que un recurso pueda comunicarse de forma privada con recursos en subredes no superpuestas de otra VPC, incluso si dicho recurso se encuentra en una subred que se traslapa con otras.
Usa Private Service Connect para habilitar la comunicación privada entre subredes superpuestas. Espero que este post te haya sido útil. Escríbeme si tienes alguna duda.