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 hacer que un servicio alojado en entornos locales o en otros entornos de nube esté disponible 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. Si colocas un adjunto de servicio frente al balanceador de cargas del 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 a un servicio local mediante un grupo de extremos de red. La VPC del consumidor podrá comunicarse con el servicio local.

Nota: El codelab ofrece pasos de configuración y validación basados en la topología ilustrada. Modifica el procedimiento según sea necesario para satisfacer los requisitos de tu organización. Los permisos de IAM no se incluyen en el alcance de este codelab.

Qué aprenderás

• Cómo crear un ILB de proxy TCP con un 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 del servicio del consumidor al productor

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

Requisitos

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

Establece una conectividad híbrida

Tu Google Cloud y otros entornos de nube deben estar conectados a través de la conectividad híbrida, 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 red 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 los rangos de CIDR remotos. Cuando las direcciones IP se superponen, las rutas de subred se priorizan por 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 indican a continuación requieren anuncios personalizados del Cloud Router a la red local para garantizar que se actualicen las reglas del firewall local.

Subred	Descripción
172.16.0.0/23	Subred del 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 usan 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 del productor

En Cloud Shell, haz lo siguiente:

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

Crea las subredes del productor

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 está a nivel de la 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 múltiples balanceadores de cargas en la misma región y red de VPC, estos comparten 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 correspondientes 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 a la red local, por lo que se puede enrutar a tu red local. El acceso al servicio es posible a través de 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 de 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 del productor

Configura reglas de firewall para permitir el tráfico entre los extremos de Private Service Connect y el adjunto del servicio. En el codelab, se creó 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 lleguen al 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 del 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 de otra 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 en la que 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 de 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 lo asociarás con el grupo de extremos de red.

Dentro de Cloud Shell, crea la verificación de estado regional que se pasó 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 manejar.

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

Dentro de Cloud Shell, crea el proxy de destino.

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

Crea la regla de reenvío (ILB) dentro de Cloud Shell

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

Reemplaza FWD_RULE_PORT por un solo número de puerto, de 1 a 65535. La regla de reenvío solo reenvía los 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 1 NEG es "Verde", lo que indica una verificación de estado exitosa en el servicio local.

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

5. Consulta las rutas aprendidas desde las instalaciones locales

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

6. Valida la conectividad al servicio local

Desde la VPC de los productores, crearemos una VM para probar la conectividad con el servicio local. Luego, se configurará el adjunto de servicio.

Dentro de 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 cumpla con lo siguiente:

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

Dentro de 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

Accede a test-box-us-central1 con IAP en Cloud Shell para validar la conectividad al servicio local realizando una solicitud curl a la dirección IP del balanceador de cargas. Vuelve a intentarlo si se agota el tiempo de espera.

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

Realiza una solicitud curl para validar la conectividad al servicio local. Una vez que se valide, sal de la VM y regresa al símbolo del sistema 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 de servicio de Private Service Connect

En los siguientes pasos, crearemos el adjunto de servicio. Una vez que se vincule con un extremo del consumidor, se logrará el acceso al servicio local sin necesidad de intercambio de tráfico entre VPCs.

Crea el adjunto del servicio

Dentro de Cloud Shell, crea la vinculación de servicio.

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 la conexión del servicio 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.

Si seleccionas Service-1, se proporcionan más detalles, incluido el URI del adjunto de servicio que usa el consumidor para establecer una conexión de Private Service Connect. 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

Dentro de 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

Dentro de 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)

Dentro de 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 anteriormente 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 Private Service Connect para consumidores: VPC del consumidor

Desde la VPC del consumidor, verifica que la conexión de Private Service Connect se haya realizado correctamente. Para ello, navega a Servicios de red → Private Service Connect → Endpoints conectados. Ten en cuenta la conexión psc-consumer-1 establecida y la dirección IP correspondiente que creamos anteriormente.

Cuando se selecciona psc-consumer-1, se proporcionan detalles adicionales, incluido el URI del adjunto de servicio.

11. Valida Private Service Connect del consumidor: VPC del productor

En la VPC del productor, verifica que la conexión privada a servicio se haya establecido correctamente. Para ello, navega a Servicios de red → Private Service Connect→Servicio publicado. Ten en cuenta que la conexión del servicio-1 publicado ahora indica 1 regla de reenvío (extremo de conexión).

12. Crea una zona de DNS privado y un registro A

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

Nota: No se admite el acceso a un extremo del consumidor a través del intercambio de tráfico de 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 con la VM

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

Dentro de 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 cumpla con lo siguiente:

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

Dentro de 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 con el servicio local realizando un curl en el FQDN de DNS service1.codelab.net. Vuelve a intentarlo si se agota el tiempo de espera.

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

Realiza una solicitud curl para validar la conectividad al servicio local. Una vez validada, sal de la VM y regresa al símbolo del sistema de Cloud Shell.

Dentro de Cloud Shell, realiza un curl

$ 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 un ejemplo de captura del servicio local. Ten en cuenta que la dirección IP de origen 172.16.0.2 proviene del rango de subred del 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 consumidores

Borra los componentes de Consumer

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 con el servicio local.

¿Qué sigue?

Consulta algunos codelabs sobre los siguientes temas:

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

Lecturas y videos adicionales

• 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