Lab práctico · Semana 4: Redes en Google Cloud (II): conectividad híbrida, multicloud y entre VPC

HA VPN con Cloud Router y BGP entre dos VPC (simulando on-premises)

⏱ 90-120 minDificultad: avanzadaApartados: 2.11.3

Qué vas a construir

Dos VPC en el mismo proyecto: vpc-nube (tu red de Google Cloud) y vpc-onprem (hace de centro de datos). Las unes con HA VPN: un gateway en cada VPC, cuatro túneles (dos por lado, uno por interfaz) y un Cloud Router en cada VPC que intercambia rutas por BGP. Al final compruebas la conectividad, las rutas aprendidas y la conmutación por error al caer un túnel.

flowchart LR
  subgraph NUBE["vpc-nube 10.1.0.0/24, ASN 65001"]
    VM1["vm-nube"]
    GW1["gw-nube: interfaz 0 e interfaz 1"]
    CR1["router-nube"]
  end
  subgraph ONP["vpc-onprem 192.168.1.0/24, ASN 65002"]
    VM2["vm-onprem"]
    GW2["gw-onprem: interfaz 0 e interfaz 1"]
    CR2["router-onprem"]
  end
  GW1 -->|"túnel if0: BGP 169.254.0.1 y .2"| GW2
  GW1 -->|"túnel if1: BGP 169.254.1.1 y .2"| GW2
  CR1 -.- GW1
  CR2 -.- GW2

En la realidad, vpc-onprem sería tu router físico o virtual on-premises con dos interfaces públicas; la configuración del lado de Google es la misma, cambiando --peer-gcp-gateway por un external VPN gateway.

Antes de empezar

Haber hecho el lab-06-vpc-firewall-nat.
En Cloud Shell:

export PROJECT_ID="tu-proyecto-pca"
export REGION="europe-southwest1"
export ZONE="europe-southwest1-a"
gcloud config set project $PROJECT_ID
gcloud services enable compute.googleapis.com iap.googleapis.com
export SECRETO=$(openssl rand -base64 24)

Paso 1: las dos VPC y sus subredes

Rangos que no se solapan (requisito imprescindible para enrutar entre ambas). El modo de enrutamiento dinámico lo pones en global en la VPC de la nube, como harías en producción.

gcloud compute networks create vpc-nube --subnet-mode=custom --bgp-routing-mode=global
gcloud compute networks subnets create subred-nube \
  --network=vpc-nube --region=$REGION --range=10.1.0.0/24

gcloud compute networks create vpc-onprem --subnet-mode=custom --bgp-routing-mode=regional
gcloud compute networks subnets create subred-onprem \
  --network=vpc-onprem --region=$REGION --range=192.168.1.0/24

Paso 2: firewall

En cada VPC permites SSH desde IAP y el tráfico ICMP y TCP que venga del otro lado.

gcloud compute firewall-rules create nube-allow-iap --network=vpc-nube \
  --direction=INGRESS --action=ALLOW --rules=tcp:22 --source-ranges=35.235.240.0/20
gcloud compute firewall-rules create nube-allow-onprem --network=vpc-nube \
  --direction=INGRESS --action=ALLOW --rules=icmp,tcp --source-ranges=192.168.1.0/24

gcloud compute firewall-rules create onprem-allow-iap --network=vpc-onprem \
  --direction=INGRESS --action=ALLOW --rules=tcp:22 --source-ranges=35.235.240.0/20
gcloud compute firewall-rules create onprem-allow-nube --network=vpc-onprem \
  --direction=INGRESS --action=ALLOW --rules=icmp,tcp --source-ranges=10.1.0.0/24

Paso 3: una VM en cada VPC (sin IP externa)

gcloud compute instances create vm-nube --zone=$ZONE --machine-type=e2-micro \
  --subnet=subred-nube --no-address --image-family=debian-12 --image-project=debian-cloud

gcloud compute instances create vm-onprem --zone=$ZONE --machine-type=e2-micro \
  --subnet=subred-onprem --no-address --image-family=debian-12 --image-project=debian-cloud

Anota la IP interna de vm-onprem:

export IP_ONPREM=$(gcloud compute instances describe vm-onprem --zone=$ZONE \
  --format="value(networkInterfaces[0].networkIP)")
echo $IP_ONPREM

Paso 4: gateways HA VPN y Cloud Routers

Cada gateway HA VPN recibe dos IP externas (una por interfaz). Cada Cloud Router usa un ASN privado distinto.

Consola: Network Connectivity → VPN → Create VPN connection → High-availability (HA) VPN (el asistente crea gateway, túneles y sesiones BGP).

gcloud compute vpn-gateways create gw-nube --network=vpc-nube --region=$REGION
gcloud compute vpn-gateways create gw-onprem --network=vpc-onprem --region=$REGION

gcloud compute routers create router-nube --network=vpc-nube --region=$REGION --asn=65001
gcloud compute routers create router-onprem --network=vpc-onprem --region=$REGION --asn=65002

gcloud compute vpn-gateways describe gw-nube --region=$REGION

En la salida verás vpnInterfaces con las dos IP públicas del gateway.

Paso 5: los cuatro túneles

Dos túneles desde gw-nube (interfaz 0 y 1) y sus dos parejas desde gw-onprem. Con IKEv2 y la misma clave precompartida en ambos extremos de cada túnel. A partir de aquí empieza el cargo por túnel.

gcloud compute vpn-tunnels create tunel-nube-if0 --region=$REGION \
  --vpn-gateway=gw-nube --interface=0 --peer-gcp-gateway=gw-onprem \
  --ike-version=2 --shared-secret="$SECRETO" --router=router-nube

gcloud compute vpn-tunnels create tunel-nube-if1 --region=$REGION \
  --vpn-gateway=gw-nube --interface=1 --peer-gcp-gateway=gw-onprem \
  --ike-version=2 --shared-secret="$SECRETO" --router=router-nube

gcloud compute vpn-tunnels create tunel-onprem-if0 --region=$REGION \
  --vpn-gateway=gw-onprem --interface=0 --peer-gcp-gateway=gw-nube \
  --ike-version=2 --shared-secret="$SECRETO" --router=router-onprem

gcloud compute vpn-tunnels create tunel-onprem-if1 --region=$REGION \
  --vpn-gateway=gw-onprem --interface=1 --peer-gcp-gateway=gw-nube \
  --ike-version=2 --shared-secret="$SECRETO" --router=router-onprem

Paso 6: interfaces y sesiones BGP en los Cloud Routers

Cada túnel lleva una sesión BGP entre direcciones link-local (169.254.0.0/16, en bloques /30). Un bloque por túnel, y cada extremo usa una IP del bloque.

gcloud compute routers add-interface router-nube --region=$REGION \
  --interface-name=if-nube-0 --ip-address=169.254.0.1 --mask-length=30 \
  --vpn-tunnel=tunel-nube-if0
gcloud compute routers add-bgp-peer router-nube --region=$REGION \
  --peer-name=bgp-nube-0 --interface=if-nube-0 \
  --peer-ip-address=169.254.0.2 --peer-asn=65002

gcloud compute routers add-interface router-nube --region=$REGION \
  --interface-name=if-nube-1 --ip-address=169.254.1.1 --mask-length=30 \
  --vpn-tunnel=tunel-nube-if1
gcloud compute routers add-bgp-peer router-nube --region=$REGION \
  --peer-name=bgp-nube-1 --interface=if-nube-1 \
  --peer-ip-address=169.254.1.2 --peer-asn=65002

gcloud compute routers add-interface router-onprem --region=$REGION \
  --interface-name=if-onprem-0 --ip-address=169.254.0.2 --mask-length=30 \
  --vpn-tunnel=tunel-onprem-if0
gcloud compute routers add-bgp-peer router-onprem --region=$REGION \
  --peer-name=bgp-onprem-0 --interface=if-onprem-0 \
  --peer-ip-address=169.254.0.1 --peer-asn=65001

gcloud compute routers add-interface router-onprem --region=$REGION \
  --interface-name=if-onprem-1 --ip-address=169.254.1.2 --mask-length=30 \
  --vpn-tunnel=tunel-onprem-if1
gcloud compute routers add-bgp-peer router-onprem --region=$REGION \
  --peer-name=bgp-onprem-1 --interface=if-onprem-1 \
  --peer-ip-address=169.254.1.1 --peer-asn=65001

Comprueba que funciona

Estado de los túneles (espera 1-2 minutos). Deben aparecer como ESTABLISHED:

gcloud compute vpn-tunnels list --format="table(name,region,status,detailedStatus)"

Sesiones BGP y rutas aprendidas:

gcloud compute routers get-status router-nube --region=$REGION \
  --format="yaml(result.bgpPeerStatus[].name,result.bgpPeerStatus[].status,result.bestRoutes[].destRange)"

Verás las dos sesiones en UP y la ruta 192.168.1.0/24 aprendida (dos veces, una por túnel: tráfico repartido con ECMP).

Rutas dinámicas en la VPC:

gcloud compute routes list --filter="network:vpc-nube"

Las rutas dinámicas no aparecen en esta lista (solo las de sistema y estáticas); se ven en la consola en VPC network → vpc-nube → Routes → pestaña Effective routes. Es un detalle típico de troubleshooting.

Conectividad desde la «nube» al «centro de datos»:

gcloud compute ssh vm-nube --zone=$ZONE --tunnel-through-iap --command="ping -c 5 $IP_ONPREM"

Conmutación por error: borra un túnel de cada lado de la interfaz 0 y repite el ping.

gcloud compute vpn-tunnels delete tunel-nube-if0 tunel-onprem-if0 --region=$REGION --quiet
gcloud compute ssh vm-nube --zone=$ZONE --tunnel-through-iap --command="ping -c 5 $IP_ONPREM"

El ping sigue funcionando por los túneles de la interfaz 1: BGP retira la ruta del túnel caído. Con un solo túnel activo perderías el SLA del 99,99 %, que exige ambas interfaces.

Limpieza

Borra primero los túneles (lo que se cobra por hora), después los routers, los gateways y el resto:

gcloud compute vpn-tunnels delete tunel-nube-if0 tunel-nube-if1 tunel-onprem-if0 tunel-onprem-if1 \
  --region=$REGION --quiet 2>/dev/null
gcloud compute routers delete router-nube router-onprem --region=$REGION --quiet
gcloud compute vpn-gateways delete gw-nube gw-onprem --region=$REGION --quiet
gcloud compute instances delete vm-nube vm-onprem --zone=$ZONE --quiet
gcloud compute firewall-rules delete nube-allow-iap nube-allow-onprem onprem-allow-iap onprem-allow-nube --quiet
gcloud compute networks subnets delete subred-nube subred-onprem --region=$REGION --quiet
gcloud compute networks delete vpc-nube vpc-onprem --quiet

Comprueba que no queda nada: gcloud compute vpn-tunnels list y gcloud compute vpn-gateways list deben estar vacíos.

Preguntas para pensar como arquitecto

Una VM de vpc-nube en europe-west1 no llega a on-premises, pero las de Madrid sí. ¿Qué revisas?

El modo de enrutamiento dinámico de la VPC. Con modo regional, las rutas aprendidas por el Cloud Router de Madrid solo se aplican en Madrid. En este lab lo pusiste en global, así que funcionaría; en producción es un fallo frecuente. También revisaría el firewall on-premises para el rango de la subred de Bélgica y que Cloud Router lo anuncie.

El router on-premises del cliente solo admite rutas estáticas. ¿Puedes usar HA VPN?

No: HA VPN exige enrutamiento dinámico con BGP. Las opciones serían actualizar o sustituir el equipo on-premises (lo recomendable, para tener el SLA del 99,99 %) o usar Classic VPN con rutas estáticas, que es heredado y tiene un SLA del 99,9 %.

Necesitas 8 Gbps estables hacia on-premises. ¿Añades túneles o cambias de producto?

Técnicamente podrías sumar túneles (cada uno da 1-3 Gbps) y repartir con ECMP, pero el tráfico seguiría yendo por Internet con latencia variable y la salida se cobraría a precio de Internet. Con ese volumen sostenido, lo razonable es Partner Interconnect (si no estás en un centro de colocación) o Dedicated Interconnect de 10 Gbps, manteniendo HA VPN como respaldo o para cifrar por encima.

¿Cómo harías que on-premises prefiriera siempre el túnel de la interfaz 0 y usara el otro solo como respaldo?

Configurando la prioridad de ruta anunciada (MED, --advertised-route-priority) en las sesiones BGP de Cloud Router: un valor más bajo en la sesión del túnel preferido y más alto en la de respaldo. El router remoto elige la ruta con menor MED y solo usa la otra si la primera desaparece (activo/pasivo en vez de activo/activo).

Volver al módulo