Conéctate a servicios locales a través de redes híbridas con Private Service Connect y el proxy TCP de NEG híbrido

1. Introducción

Un balanceador de cargas de proxy TCP regional interno con conectividad híbrida te permite poner a disposición un servicio alojado en entornos locales o en otros entornos de nube para los clientes en tu red de VPC.

Si quieres que el servicio híbrido esté disponible en otras redes de VPC, puedes usar Private Service Connect para publicar el servicio. Cuando colocas un adjunto de servicio frente a tu balanceador de cargas de proxy TCP regional interno, puedes permitir que los clientes de otras redes de VPC accedan a los servicios híbridos que se ejecutan en entornos locales o en otros entornos de nube.

Qué compilarás

En este codelab, compilarás un balanceador de cargas de proxy TCP interno con conectividad híbrida para un servicio local mediante un grupo de extremos de red. Desde la VPC del consumidor podrán comunicarse con el servicio local.

Nota: El codelab ofrece pasos de configuración y validación según la topología ilustrada. Modifica el procedimiento según sea necesario para cumplir con los requisitos de tu organización. Los permisos de IAM no están dentro del alcance de este codelab.

Qué aprenderás

• Cómo crear un ILB de proxy TCP con servicio de backend de NEG híbrido
• Cómo establecer un productor (adjunto de servicio) y un consumidor (regla de reenvío) de Private Service Connect
• Cómo probar y validar la comunicación de servicio entre el consumidor y el productor

Nota: Este codelab se enfoca en la implementación de ILB del proxy TCP con PSC . La configuración de red híbrida no está documentada, pero se proporcionan documentación de respaldo y capturas de pantalla.

Requisitos

• Redes híbridas establecidas, p. ej., VPN con alta disponibilidad, Interconnect o SW-WAN
• Proyecto de Google Cloud

Establece la conectividad híbrida

Tu Google Cloud y los entornos locales o de otras nubes deben estar conectados a través de conectividad híbrida, ya sea mediante adjuntos de VLAN de Cloud Interconnect o túneles de Cloud VPN con Cloud Router. Te recomendamos usar una conexión de alta disponibilidad.

Un Cloud Router habilitado con enrutamiento dinámico global aprende sobre el extremo específico a través de BGP y lo programa en tu red de VPC de Google Cloud. No se admite el enrutamiento dinámico regional. Tampoco se admiten las rutas estáticas.

La red de VPC de Google Cloud que usas para configurar Cloud Interconnect o Cloud VPN es la misma que usas para configurar la implementación del balanceo de cargas híbrido. Asegúrate de que los rangos de CIDR de la subred de tu red de VPC no entren en conflicto con tus rangos de CIDR remotos. Cuando las direcciones IP se superponen, las rutas de subred tienen prioridad sobre la conectividad remota.

Para obtener instrucciones, consulta los siguientes vínculos:

• Documentación de Cloud VPN
• Documentación de Cloud Interconnect

Anuncios de ruta personalizada

Las subredes que se encuentran a continuación requieren anuncios personalizados del Cloud Router a la red local, lo que garantiza la actualización de las reglas de firewall locales.

Subred	Descripción
172.16.0.0/23	Subred de proxy TCP que se usa para comunicarse directamente con el servicio local
130.211.0.0/22, 35.191.0.0/16	Verificación de estado de Google Cloud

2. Antes de comenzar

Actualiza el proyecto para que sea compatible con el codelab

En este codelab, se usa $variables para facilitar la implementación de la configuración de gcloud en Cloud Shell.

En Cloud Shell, haz lo siguiente

gcloud config list project
gcloud config set project [YOUR-PROJECT-NAME]
psclab=YOUR-PROJECT-NAME
echo $psclab

3. Configuración del productor

Crea la VPC de productor

En Cloud Shell, haz lo siguiente

gcloud compute networks create producer-vpc --project=$psclab --subnet-mode=custom

Crea las subredes de Producer

En Cloud Shell, haz lo siguiente

gcloud compute networks subnets create subnet-201 --project=$psclab --range=10.10.1.0/24 --network=producer-vpc --region=us-central1

Crea las subredes del proxy TCP

La asignación de proxy se realiza a nivel de VPC, no a nivel del balanceador de cargas. Debes crear una subred de solo proxy en cada región de una red virtual (VPC) en la que uses balanceadores de cargas basados en Envoy. Si implementas varios balanceadores de cargas en la misma región y la misma red de VPC, compartirán la misma subred de solo proxy para el balanceo de cargas.

1. Un cliente establece una conexión a la dirección IP y al puerto de la regla de reenvío del balanceador de cargas.
2. Cada proxy escucha en la dirección IP y el puerto que especifica la regla de reenvío del balanceador de cargas correspondiente. Uno de los servidores proxy recibe y finaliza la conexión de red del cliente.
3. El proxy establece una conexión con la VM o el extremo de backend adecuados en un NEG, según lo determinan los servicios de backend y el mapa de URL del balanceador de cargas.

Debes crear subredes de solo proxy sin importar si tu red está en modo automático o personalizado. Una subred de solo proxy debe proporcionar 64 direcciones IP o más. Esto corresponde a una longitud de prefijo de /26 o menor. El tamaño de subred recomendado es /23 (512 direcciones de solo proxy).

Nota: La subred de proxy requiere un anuncio de BGP del cliente para el entorno local, por lo que se puede enrutar a tu red local y el acceso al servicio es posible mediante la subred de proxy proporcionada.

En Cloud Shell, haz lo siguiente

gcloud compute networks subnets create proxy-subnet-us-central \
  --purpose=REGIONAL_MANAGED_PROXY \
  --role=ACTIVE \
  --region=us-central1 \
  --network=producer-vpc \
  --range=172.16.0.0/23

Crea las subredes NAT de Private Service Connect

Crea una o más subredes dedicadas para usar con Private Service Connect. Si usas la consola de Google Cloud para publicar un servicio, puedes crear las subredes durante ese procedimiento. Crea la subred en la misma región que el balanceador de cargas del servicio. No puedes convertir una subred normal en una subred de Private Service Connect.

En Cloud Shell, haz lo siguiente

gcloud compute networks subnets create psc-nat-subnet --network=producer-vpc --region=us-central1 --range=100.100.10.0/24 --purpose=private-service-connect

Crea las reglas de firewall de Producer

Configura las reglas de firewall para permitir el tráfico entre los extremos de Private Service Connect y el adjunto de servicio. En el codelab, creaste una regla de firewall de entrada que permite que la subred NAT 100.100.10.0/24 acceda al adjunto de servicio de Private Service Connect (balanceador de cargas interno).

En Cloud Shell, haz lo siguiente

gcloud compute --project=$psclab firewall-rules create allow-to-ingress-nat-subnet --direction=INGRESS --priority=1000 --network=producer-vpc --action=ALLOW --rules=all --source-ranges=100.100.10.0/24

Dentro de Cloud Shell, crea la regla fw-allow-health-check para permitir que las verificaciones de estado de Google Cloud alcancen el servicio local (servicio de backend) en el puerto TCP 80

gcloud compute firewall-rules create fw-allow-health-check \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --rules=tcp:80

Crea una regla de firewall de entrada que permita que los servicios locales se comuniquen con la subred de proxy en el puerto 80

gcloud compute firewall-rules create fw-allow-proxy-only-subnet \
    --network=producer-vpc \
    --action=allow \
    --direction=ingress \
    --source-ranges=172.16.0.0/23 \
    --rules=tcp:80

Configura el NEG de conectividad híbrida

Cuando crees el NEG, usa una ZONA que minimice la distancia geográfica entre Google Cloud y tu entorno local o algún otro entorno de nube. Por ejemplo, si alojas un servicio en un entorno local en Fráncfort, Alemania, puedes especificar la zona europe-west3-a de Google Cloud cuando crees el NEG.

Además, si usas Cloud Interconnect, la ZONA que se usa para crear el NEG debe estar en la misma región donde se configuró el adjunto de Cloud Interconnect.

Para conocer las regiones y zonas disponibles, consulta la documentación de Compute Engine: Regiones y zonas disponibles.

Dentro de Cloud Shell, crea un NEG de conectividad híbrida con el comando gcloud compute network-endpoint-groups create.

gcloud compute network-endpoint-groups create on-prem-service-neg \
    --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \
    --zone=us-central1-a \
    --network=producer-vpc

Dentro de Cloud Shell, agrega el extremo IP:Port local al NEG híbrido.

gcloud compute network-endpoint-groups update on-prem-service-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=192.168.1.5,port=80"

Configura el balanceador de cargas

En los siguientes pasos, configurarás el balanceador de cargas (regla de reenvío) y asociar al grupo de extremos de red

Dentro de Cloud Shell, crea la verificación de estado regional que se pasa al servicio local

gcloud compute health-checks create tcp on-prem-service-hc \
    --region=us-central1 \
    --use-serving-port

Dentro de Cloud Shell, crea el servicio de backend para el backend local

gcloud compute backend-services create on-premise-service-backend \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --protocol=TCP \
   --region=us-central1 \
   --health-checks=on-prem-service-hc \
   --health-checks-region=us-central1

Dentro de Cloud Shell, agrega el backend de NEG híbrido al servicio de backend. Para MAX_CONNECTIONS, ingresa la cantidad máxima de conexiones simultáneas que el backend debe controlar.

gcloud compute backend-services add-backend on-premise-service-backend \
   --network-endpoint-group=on-prem-service-neg \
   --network-endpoint-group-zone=us-central1-a \
   --region=us-central1 \
   --balancing-mode=CONNECTION \
   --max-connections=100

Crea el proxy de destino en Cloud Shell

gcloud compute target-tcp-proxies create on-premise-svc-tcpproxy \
   --backend-service=on-premise-service-backend \
   --region=us-central1

Dentro de Cloud Shell, crea la regla de reenvío (ILB).

Crea la regla de reenvío con el comando gcloud compute redirect-rules create.

Reemplaza FWD_RULE_PORT por un solo número de puerto del 1 al 65535. La regla de reenvío solo reenvía paquetes con un puerto de destino coincidente.

gcloud compute forwarding-rules create tcp-ilb-psc \
   --load-balancing-scheme=INTERNAL_MANAGED \
   --network=producer-vpc \
   --subnet=subnet-201 \
   --ports=80 \
   --region=us-central1 \
   --target-tcp-proxy=on-premise-svc-tcpproxy \
   --target-tcp-proxy-region=us-central1

Obtén la dirección IP del balanceador de cargas interno

gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:

Example output:
gcloud compute forwarding-rules describe tcp-ilb-psc --region=us-central1 | grep -i IPAddress:
IPAddress: 10.10.1.2

4. Valida el balanceador de cargas

En la consola de Cloud, navega a Servicios de red → Balanceo de cargas → Balanceadores de cargas. Ten en cuenta que el NEG 1 es “verde”, lo que indica una verificación de estado correcta al servicio local.

Si seleccionas ‘on-premise-service-backend', se obtiene la dirección IP del frontend

5. Visualiza las rutas aprendidas desde la infraestructura local

Navega a Red de VPC → Rutas. Ten en cuenta que la subred de servicio local aprendida 192.168.1.0/27

6. Valida la conectividad al servicio local

Desde la VPC de productores, crearemos una VM para probar la conectividad al servicio local. Luego, el adjunto de servicio será el siguiente para la configuración.

En Cloud Shell, crea la instancia de prueba en la VPC del productor

gcloud compute instances create test-box-us-central1 \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-201 \
    --no-address

Para permitir que IAP se conecte a tus instancias de VM, crea una regla de firewall que haga lo siguiente:

• Se aplica a todas las instancias de VM a las que deseas que se pueda acceder mediante IAP.
• Permite el tráfico de entrada del rango de IP 35.235.240.0/20. Este rango contiene todas las direcciones IP que IAP usa para el reenvío de TCP.

En Cloud Shell, crea la instancia de prueba en la VPC del productor

gcloud compute firewall-rules create ssh-iap \
    --network producer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Inicie sesión en test-box-us-central1 con IAP en Cloud Shell para validar la conectividad al servicio local. Para ello, ejecute un comando curl en función de la dirección IP de balanceo de cargas. Vuelve a intentarlo si se agotó el tiempo de espera.

gcloud compute ssh test-box-us-central1 --project=$psclab --zone=us-central1-a --tunnel-through-iap

Realiza un comando curl que valide la conectividad al servicio local. Una vez validada, salga de la VM y regrese a la ventana de Cloud Shell. Reemplaza la IP del balanceador de cargas interno según el resultado que identificaste en los pasos 3 y 4.

deepakmichael@test-box-us-central1:~$ curl -v 10.10.1.2
* Expire in 0 ms for 6 (transfer 0x55b9a6b2f0f0)
*   Trying 10.10.1.2...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55b9a6b2f0f0)
* Connected to 10.10.1.2 (10.10.1.2) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.10.1.2
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:42:38 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:42:38 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

7. Crea el adjunto del servicio de Private Service Connect

En los siguientes pasos, crearemos el adjunto de servicio, una vez que se vincula con un extremo del consumidor, el acceso al servicio local se logra sin necesidad de un intercambio de tráfico entre VPC.

Crea el adjunto de servicio

Crea el adjunto de servicio en Cloud Shell

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=psc-nat-subnet

Opcional: Si usas una VPC compartida, crea el adjunto de servicio en el proyecto de servicio.

gcloud compute service-attachments create service-1 --region=us-central1 --producer-forwarding-rule=tcp-ilb-psc --connection-preference=ACCEPT_AUTOMATIC --nat-subnets=projects/<hostproject>/regions/<region>/subnetworks/<natsubnet>

Valida el adjunto de servicio de TCP

gcloud compute service-attachments describe service-1 --region us-central1

8. Opcional: Navega a Servicios de red → Private Service Connect para ver el adjunto de servicio recién establecido

Seleccionar Service-1 proporciona más detalles, incluido el URI del adjunto de servicio que usa el consumidor para establecer una conexión de servicio privada. Toma nota del URI, ya que lo usarás en un paso posterior.

Detalles del adjunto de servicio: projects/<projectname>/regions/us-central1/serviceAttachments/service-1

9. Configuración del consumidor

Crea la VPC del consumidor

En Cloud Shell, haz lo siguiente

gcloud compute networks create consumer-vpc --project=$psclab --subnet-mode=custom

Crea las subredes del consumidor

En Cloud Shell, crea la subred de GCE

gcloud compute networks subnets create subnet-101 --project=$psclab --range=10.100.1.0/24 --network=consumer-vpc --region=us-central1

En Cloud Shell, crea la subred del extremo del consumidor

gcloud compute networks subnets create subnet-102 --project=$psclab --range=10.100.2.0/24 --network=consumer-vpc --region=us-central1

Crea el extremo del consumidor (regla de reenvío)

En Cloud Shell, crea la dirección IP estática que se usará como extremo del consumidor.

gcloud compute addresses create psc-consumer-ip-1 --region=us-central1 --subnet=subnet-102 --addresses 10.100.2.10

Usemos el URI del adjunto de servicio generado con anterioridad para crear el extremo del consumidor

Dentro de Cloud Shell, crea el extremo del consumidor

gcloud compute forwarding-rules create psc-consumer-1 --region=us-central1 --network=consumer-vpc --address=psc-consumer-ip-1 --target-service-attachment=projects/$psclab/regions/us-central1/serviceAttachments/service-1

10. Valida Consumer Private Service Connect: VPC del consumidor

Desde la VPC del consumidor, navega a Servicios de red → Private Service Connect→ Extremos conectados para verificar que haya una conexión de servicio privada exitosa. Observa la conexión psc-consumer-1 establecida y la dirección IP correspondiente que creamos anteriormente.

Cuando se seleccionan los detalles de adición psc-consumer-1, incluido el URI del adjunto de servicio

11. Valida Consumer Private Service Connect: VPC del productor

Desde la VPC del productor, navega a Servicios de red → Private Service Connect→Servicio publicado para verificar que se haya establecido una conexión de servicio privado correctamente. Observa que la conexión service-1 publicada ahora indica 1 regla de reenvío (extremo de conexión).

12. Crea una zona de DNS privada y Registro A

Crea la zona de DNS privada asignada al extremo de conexión de PSC, lo que permite el acceso sin interrupciones al productor desde cualquier host dentro de la VPC.

Nota: No se admite el acceso a un extremo de consumidor a través del intercambio de tráfico entre VPC.

Desde Cloud Shell

gcloud dns --project=$psclab managed-zones create codelab-zone --description="" --dns-name="codelab.net." --visibility="private" --networks="consumer-vpc"

gcloud dns --project=$psclab record-sets create service1.codelab.net. --zone="codelab-zone" --type="A" --ttl="300" --rrdatas="10.100.2.10"

13. Valida el acceso del consumidor al servicio de productores mediante la VM

Desde la VPC de consumidores, crearemos una VM para probar la conectividad al servicio local accediendo al servicio del extremo del consumidor 1.codelabs.net

En Cloud Shell, crea la instancia de prueba en la VPC del consumidor

gcloud compute instances create consumer-vm \
    --zone=us-central1-a \
    --image-family=debian-10 \
    --image-project=debian-cloud \
    --subnet=subnet-101 \
    --no-address

Para permitir que IAP se conecte a tus instancias de VM, crea una regla de firewall que haga lo siguiente:

• Se aplica a todas las instancias de VM a las que deseas que se pueda acceder mediante IAP.
• Permite el tráfico de entrada del rango de IP 35.235.240.0/20. Este rango contiene todas las direcciones IP que IAP usa para el reenvío de TCP.

En Cloud Shell, crea la instancia de prueba en la VPC del consumidor

gcloud compute firewall-rules create ssh-iap-consumer \
    --network consumer-vpc \
    --allow tcp:22 \
    --source-ranges=35.235.240.0/20

Accede a consumer-vm con IAP en Cloud Shell para validar la conectividad al servicio local. Para ello, ejecuta un comando curl en el FQDN de dns service1.codelab.net. Vuelve a intentarlo si se agotó el tiempo de espera.

gcloud compute ssh consumer-vm --project=$psclab --zone=us-central1-a --tunnel-through-iap

Realiza un comando curl que valide la conectividad al servicio local. Una vez validada, salga de la VM y regrese al prompt de Cloud Shell.

Realiza un curl en Cloud Shell

$ curl -v service1.codelab.net
*   Trying 10.100.2.10...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x5650fc3390f0)
* Connected to service1.codelab.net (10.100.2.10) port 80 (#0)
> GET / HTTP/1.1
> Host: service1.codelab.net
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Content-Type: text/html; charset=utf-8
< Accept-Ranges: bytes
< ETag: "3380914763"
< Last-Modified: Mon, 05 Dec 2022 15:10:56 GMT
< Expires: Mon, 05 Dec 2022 15:15:41 GMT
< Cache-Control: max-age=0
< Content-Length: 37
< Date: Mon, 05 Dec 2022 15:15:41 GMT
< Server: lighttpd/1.4.53
< 
Welcome to my on-premise service!!

A continuación, se proporciona una captura de ejemplo del servicio local. Ten en cuenta que la dirección IP de origen 172.16.0.2 es del rango de subred de proxy TCP 172.16.0.0/23.

14. Limpieza del productor

Cómo borrar componentes de Producer

Dentro de Cloud Shell, borra los componentes del productor

gcloud compute instances delete test-box-us-central1 --zone=us-central1-a --quiet

gcloud compute service-attachments delete service-1 --region=us-central1 --quiet 

gcloud compute forwarding-rules delete tcp-ilb-psc --region=us-central1 --quiet

gcloud compute target-tcp-proxies delete on-premise-svc-tcpproxy --region=us-central1 --quiet

gcloud compute backend-services delete on-premise-service-backend --region=us-central1 --quiet

gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=us-central1-a --quiet

gcloud compute networks subnets delete psc-nat-subnet subnet-201 proxy-subnet-us-central --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap fw-allow-proxy-only-subnet allow-to-ingress-nat-subnet fw-allow-health-check --quiet

gcloud compute health-checks delete on-prem-service-hc --region=us-central1 --quiet

gcloud compute networks delete producer-vpc --quiet

15. Limpieza de los consumidores

Borra componentes de consumidor

Dentro de Cloud Shell, borra los componentes del consumidor.

gcloud compute instances delete consumer-vm --zone=us-central1-a --quiet

gcloud compute forwarding-rules delete psc-consumer-1 --region=us-central1 --quiet

gcloud compute addresses delete psc-consumer-ip-1 --region=us-central1 --quiet

gcloud compute networks subnets delete subnet-101 subnet-102 --region=us-central1 --quiet

gcloud compute firewall-rules delete ssh-iap-consumer --quiet

gcloud dns record-sets delete service1.codelab.net --type=A --zone=codelab-zone --quiet

gcloud dns managed-zones delete codelab-zone --quiet 

gcloud compute networks delete consumer-vpc --quiet 

16. Felicitaciones

Felicitaciones, configuraste y validaste correctamente Private Service Connect con el proxy TCP.

Creaste la infraestructura del productor y agregaste un adjunto de servicio en la VPC del productor que apunta a un servicio local. Aprendiste a crear un extremo del consumidor en la VPC del consumidor que permitía la conectividad al servicio local.

¿Qué sigue?

Consulta algunos codelabs sobre los siguientes temas:

• Usa Private Service para publicar y consumir servicios con GKE
• Usa Private Service Connect para publicar y consumir servicios

Lecturas adicionales y Videos

• Descripción general de Private Service Connect
• ¿Qué es Private Service Connect?

Documentos de referencia

• Proxy TCP interno
• Descripción general de las verificaciones de estado
• Cómo publicar un servicio