1. Introducción
El grupo de extremos de red (NEG) de Private Service Connect (PSC) admite la encadenación de un balanceador de cargas de HTTPS interno con un balanceador de cargas de HTTPS externo. Esto proporciona verificaciones de estado distribuidas y tráfico de plano de datos a las instalaciones locales con rangos definidos por el cliente. Además, esta topología también admite varias VPC que se conectan a la infraestructura local a través de varias interconexiones regionales.
En este codelab, demostraremos cómo configurar esto de extremo a extremo en función de la siguiente topología. De izquierda a derecha, los clientes locales tienen una VM para simular servicios HTTP, aprovechar la conectividad híbrida (HA-VPN o InterConnect) y el NEG híbrido para exponerse a través del balanceador de cargas HTTPS interno. PSC usa el balanceador de cargas HTTPS interno como archivos adjuntos de servicio. PSC NEG consume los adjuntos como servicio de backend, expuestos al balanceo de cargas de HTTPS externo. Los usuarios de Internet pueden usar la red global de Google para acelerar el acceso a los servicios HTTP locales.
Figura 1: Private Service Connect usa el grupo de extremos de red y los adjuntos de servicio para conectar el balanceador de cargas de HTTPS externo al balanceador de cargas de HTTPS interno y extender el backend al entorno local.
Qué aprenderás
- Balanceador de cargas HTTPS interno con NEG híbrido y verificación de estado distribuido
- Conexión de servicio de PSC con balanceador de cargas HTTPS interno
- Configuración del grupo de extremos de red de PSC
- Cómo exponer el NEG de PSC con un balanceador de cargas HTTPS externo
Requisitos
- Conocimientos de conectividad híbrida, como HA-VPN
- Conocimiento sobre el balanceo de cargas HTTPS interno/externo
- Conocimientos de Private Service Connect
2. Antes de comenzar
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.
El codelab usará un proyecto para simular todo el proceso. También se admiten varios proyectos.
Proyecto único: Actualización del proyecto para admitir las redes de productores y consumidores
En Cloud Shell, asegúrate de que el ID del proyecto esté configurado
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] prodproject=YOUR-PROJECT-NAME echo $prodproject
3. Crea recursos locales
En la siguiente sección, configuraremos una VPC y VMs locales para simular los servicios locales del cliente.
Red de VPC
Desde Cloud Shell
gcloud compute networks create vpc-demo-onprem --project=$prodproject --subnet-mode=custom
Crear subred
Desde Cloud Shell
gcloud compute networks subnets create vpc-demo-onprem-asia-southeast1 --project=$prodproject --range=10.0.0.0/24 --network=vpc-demo-onprem --region=asia-southeast1
Crear reglas de firewall
El balanceador de cargas HTTPS interno admite la verificación de estado distribuida, y las reglas de firewall solo deben permitir el rango de IP de la subred de proxy. Consulta este documento para incluir tus proyectos en la lista de entidades permitidas.
En Cloud Shell, crea una regla de firewall para habilitar las verificaciones de estado del backend y el tráfico del plano de datos desde las subredes del proxy.
gcloud compute firewall-rules create vpc-demo-health-checks --allow tcp:80,tcp:443 --network vpc-demo-onprem --source-ranges 10.0.3.0/24 --enable-logging
En Cloud Shell, crea una regla de firewall para permitir que IAP se conecte a tus instancias de VM.
gcloud compute firewall-rules create psclab-iap-prod --network vpc-demo-onprem --allow tcp:22 --source-ranges=35.235.240.0/20 --enable-logging
4. Crea instancias de VM locales
Esta VM simula servicios locales y se debe exponer con un balanceador de cargas HTTPS interno que usa un NEG híbrido.
Desde Cloud Shell, crea la instancia www01
gcloud compute instances create www01 \ --zone=asia-southeast1-b \ --image-family=debian-11 \ --image-project=debian-cloud \ --network-interface=network-tier=PREMIUM,nic-type=GVNIC,stack-type=IPV4_ONLY,subnet=vpc-demo-onprem-asia-southeast1 \ --shielded-secure-boot \ --shielded-vtpm \ --shielded-integrity-monitoring \ --metadata=startup-script='#! /bin/bash sudo apt-get update sudo apt-get install nginx -y vm_hostname="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/name)" filter="{print \$NF}" vm_zone="$(curl -H "Metadata-Flavor:Google" \ http://169.254.169.254/computeMetadata/v1/instance/zone \ | awk -F/ "${filter}")" echo "Page on $vm_hostname in $vm_zone" | \ tee /var/www/html/index.nginx-debian.html sudo systemctl restart nginx'
En la siguiente sección, usaremos letsencrypt para generar certificados y, luego, instalarlos en Nginx. Descarga el archivo de claves pública y privada para el siguiente paso. Debes abrir temporalmente el puerto TCP 80 a Internet para generar el certificado.
Asegúrate de que esta VM tenga un nombre de dominio resuelto de forma pública. Por ejemplo, en Cloud DNS, agrega un registro A [www01.yinghli.demo.altostrat.com](http://www01.yinghli.demo.altostrat.com)
y apunta a la dirección IP pública de la VM.
gcloud dns --project=$prodproject record-sets create www01.yinghli.demo.altostrat.com. --zone="yinghli-demo" --type="A" --ttl="300" --rrdatas="34.87.77.186"
En la consola de la VM www01, sigue las instrucciones para instalar certificados en Nginx y crea una copia de fullchain.pem y private.pem para los siguientes pasos.
sudo apt install snapd sudo snap install core; sudo snap refresh core sudo snap install --classic certbot sudo ln -s /snap/bin/certbot /usr/bin/certbot sudo certbot --nginx
5. Crea la red de VPC de los productores
Nota: La configuración de redes híbridas NO se incluye en esta configuración.
Red de VPC
Desde Cloud Shell
gcloud compute networks create vpc-demo-producer --project=$prodproject --subnet-mode=custom
Crear subred
Desde Cloud Shell
gcloud compute networks subnets create vpc-demo-asia-southeast1 --project=$prodproject --range=10.0.2.0/24 --network=vpc-demo-producer --region=asia-southeast1
Crear subred de proxy
Desde Cloud Shell
gcloud compute networks subnets create proxy-subnet-asia-southeast1 \ --purpose=REGIONAL_MANAGED_PROXY \ --role=ACTIVE \ --region=asia-southeast1 \ --network=vpc-demo-producer \ --range=10.0.3.0/24
Conectividad híbrida
Sigue la documentación de la VPN de Cloud para implementar la conectividad de VPN con alta disponibilidad entre la VPC local y la de productor. Mantén la configuración predeterminada en el Cloud Router. No necesitamos agregar 130.211.0.0/22, 35.191.0.0/16 a los anuncios de BGP.
6. Crea un NEG híbrido de productores
Crea un grupo de extremos de red híbrido y agrega la dirección IP:PORT de la VM local al NEG.
Desde Cloud Shell
gcloud compute network-endpoint-groups create on-prem-service-neg \ --network-endpoint-type=NON_GCP_PRIVATE_IP_PORT \ --zone=asia-southeast1-b \ --network=vpc-demo-producer gcloud compute network-endpoint-groups update on-prem-service-neg \ --zone=asia-southeast1-b \ --add-endpoint="ip=10.0.0.2,port=443"
7. Crea un balanceador de cargas HTTPS interno del productor
Actualmente, el balanceador de cargas HTTPS externo solo admite el protocolo HTTPS a PSC NEG( documentación). Cuando se publican servicios, debemos usar el balanceador de cargas HTTPS interno y habilitar el acceso global de las reglas de reenvío.
Desde Cloud Shell, crea la verificación de estado regional.
gcloud compute health-checks create https on-prem-service-hc \ --region=asia-southeast1 \ --use-serving-port
En Cloud Shell, crea el servicio de backend y agrega un NEG híbrido.
gcloud compute backend-services create on-premise-service-backend \ --load-balancing-scheme=INTERNAL_MANAGED \ --protocol=HTTPS \ --region=asia-southeast1 \ --health-checks=on-prem-service-hc \ --health-checks-region=asia-southeast1 gcloud compute backend-services add-backend on-premise-service-backend \ --network-endpoint-group=on-prem-service-neg \ --network-endpoint-group-zone=asia-southeast1-b \ --region=asia-southeast1 \ --balancing-mode=RATE \ --max-rate-per-endpoint=100
Crea el mapa de URL desde Cloud Shell
gcloud compute url-maps create on-premise-url \ --default-service on-premise-service-backend \ --region=asia-southeast1
En Cloud Shell, crea los certificados SSL regionales. Se descargan dos archivos de certificado de la VM.
gcloud compute ssl-certificates create www01 \ --certificate=fullchain.pem \ --private-key=private.pem \ --region=asia-southeast1
Desde Cloud Shell, crea https-target-proxy
gcloud compute target-https-proxies create on-premise-httpsproxy \ --ssl-certificates=www01 \ --url-map=on-premise-url \ --url-map-region=asia-southeast1 \ --region=asia-southeast1
Desde Cloud Shell, reservar una IP estática interna y crear la regla de reenvío
gcloud compute addresses create ilbaddress \ --region=asia-southeast1 \ --subnet=vpc-demo-asia-southeast1 \ --addresses=10.0.2.100 gcloud compute forwarding-rules create https-ilb-psc \ --load-balancing-scheme=INTERNAL_MANAGED \ --network=vpc-demo-producer \ --subnet=vpc-demo-asia-southeast1 \ --address=ilbaddress \ --ports=443 \ --region=asia-southeast1 \ --target-https-proxy=on-premise-httpsproxy \ --target-https-proxy-region=asia-southeast1 --allow-global-access
8. Crea una instancia de VM del productor
Crea una VM de productor para la verificación.
Desde Cloud Shell
gcloud compute instances create test01 \ --zone=asia-southeast1-b \ --image-family=debian-11 \ --image-project=debian-cloud \ --network-interface=network-tier=PREMIUM,nic-type=GVNIC,stack-type=IPV4_ONLY,subnet=vpc-demo-asia-southeast1 \ --shielded-secure-boot \ --shielded-vtpm \ --shielded-integrity-monitoring
Para permitir que IAP se conecte a tus instancias de VM, crea una regla de firewall que haga lo siguiente:
Desde Cloud Shell
gcloud compute firewall-rules create psclab-iap-prod --network vpc-demo-producer --allow tcp:22 --source-ranges=35.235.240.0/20 --enable-logging
En la consola de la VM del productor, accede a [
www01.yinghli.demo.altostrat.com](https://www01.yinghli.demo.altostrat.com)
y resuelve la dirección IP del balanceador de cargas HTTPS interno. HTTP 200 indicó que la configuración funcionó como se esperaba.
curl -v --resolve www01.yinghli.demo.altostrat.com:443:10.0.2.100 https://www01.yinghli.demo.altostrat.com * Added www01.yinghli.demo.altostrat.com:443:10.0.2.100 to DNS cache * Hostname www01.yinghli.demo.altostrat.com was found in DNS cache * Trying 10.0.2.100:443... * Connected to www01.yinghli.demo.altostrat.com (10.0.2.100) port 443 (#0) * ALPN, offering h2 * ALPN, offering http/1.1 * successfully set certificate verify locations: * CAfile: /etc/ssl/certs/ca-certificates.crt * CApath: /etc/ssl/certs * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN, server accepted to use h2 * Server certificate: * subject: CN=www01.yinghli.demo.altostrat.com * start date: Jun 4 10:36:43 2023 GMT * expire date: Sep 2 10:36:42 2023 GMT * subjectAltName: host "www01.yinghli.demo.altostrat.com" matched cert's "www01.yinghli.demo.altostrat.com" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. * Using HTTP2, server supports multi-use * Connection state changed (HTTP/2 confirmed) * Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0 * Using Stream ID: 1 (easy handle 0x55865ef982e0) > GET / HTTP/2 > Host: www01.yinghli.demo.altostrat.com > user-agent: curl/7.74.0 > accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing * Connection state changed (MAX_CONCURRENT_STREAMS == 100)! < HTTP/2 200 < server: nginx/1.18.0 < date: Mon, 05 Jun 2023 02:29:38 GMT < content-type: text/html < content-length: 35 < last-modified: Sun, 04 Jun 2023 09:02:16 GMT < etag: "647c5318-23" < accept-ranges: bytes < via: 1.1 google < Page on www01 in asia-southeast1-b * Connection #0 to host www01.yinghli.demo.altostrat.com left intact
Nota: No puedes acceder directamente a los servicios HTTPS de la VM 10.0.0.2 porque el firewall local solo permite el acceso a la subred de proxy 10.0.3.0/24.
9. Crea una subred de NAT de PSC
Desde Cloud Shell
gcloud compute networks subnets create psc-nat-subnet \ --network=vpc-demo-producer \ --region=asia-southeast1 \ --range=10.0.5.0/24 \ --purpose=private-service-connect
10. Crear adjunto de servicio de HTTPS
En Cloud Shell, crea el adjunto de servicio de HTTPS
gcloud compute service-attachments create ilbserviceattach \ --region=asia-southeast1 \ --producer-forwarding-rule=https-ilb-psc \ --connection-preference=ACCEPT_AUTOMATIC \ --nat-subnets=psc-nat-subnet
Valida el adjunto de servicio de HTTPS
gcloud compute service-attachments describe ilbserviceattach --region asia-southeast1
Nombre del adjunto del servicio de registro:
projects/<project>/regions/asia-southeast1/serviceAttachments/ilbserviceattach
11. Crea la red de VPC de consumidores
En la siguiente sección, la VPC del consumidor se configura en el mismo proyecto, pero también se admiten diferentes proyectos. La comunicación entre la red del consumidor y la del productor se realiza a través del adjunto de servicio definido en la red del productor.
Red de VPC
Desde Cloud Shell
gcloud compute networks create vpc-demo-consumer --project=$prodproject --subnet-mode=custom
Crear subred
Desde Cloud Shell
gcloud compute networks subnets create consumer-subnet --project=$prodproject --range=10.0.6.0/24 --network=vpc-demo-consumer --region=asia-southeast1
12. Crear grupo de extremos de red de PSC
Crear un PSC NEG
Copia el nombre del archivo adjunto de los servicios HTTPS anterior y pégalo en los parámetros --psc-target-service
.
Desde Cloud Shell
gcloud beta compute network-endpoint-groups create consumerpscneg \ --project=$prodproject \ --region=asia-southeast1 \ --network-endpoint-type=PRIVATE_SERVICE_CONNECT \ --psc-target-service=projects/<project>/regions/asia-southeast1/serviceAttachments/ilbserviceattach \ --network=vpc-demo-consumer \ --subnet=consumer-subnet
Después de configurar correctamente la NEG de PSC, desde la IU, sigue Private Service Connect
-> Published Services
-> Observa que la conexión ilbserviceattach
publicada ahora indica 1 regla de reenvío.
13. Crea un balanceador de cargas HTTPS externo para consumidores
Crea un balanceador de cargas HTTPS externo y usa PSC NEG como servicios de backend( documentación).
Desde Cloud Shell
gcloud compute addresses create httpspsclb \ --ip-version=IPV4 --global gcloud compute backend-services create consumer-bs \ --load-balancing-scheme=EXTERNAL_MANAGED \ --protocol=HTTPS \ --global gcloud compute backend-services add-backend consumer-bs \ --network-endpoint-group=consumerpscneg \ --network-endpoint-group-region=asia-southeast1 \ --global gcloud compute url-maps create consumer-url \ --default-service=consumer-backend-service \ --global gcloud compute ssl-certificates create wwwglobal \ --certificate=fullchain.pem \ --private-key=private.pem \ --global gcloud compute target-https-proxies create consumer-url-target-proxy \ --url-map=consumer-url \ --ssl-certificates=wwwglobal gcloud compute forwarding-rules create consumer-url-forwarding-rule \ --load-balancing-scheme=EXTERNAL_MANAGED \ --network-tier=PREMIUM \ --address=httpspsclb \ --target-https-proxy=consumer-url-target-proxy \ --ports=443 \ --global
Actualiza el registro DNS de www01.yinghli.demo.altostrat.com y diríjalo a la dirección IP pública del balanceador de cargas HTTPS externo.
gcloud dns --project=$prodproject record-sets update www01.yinghli.demo.altostrat.com. --type="A" --zone="yinghli-demo" --rrdatas="34.102.178.214" --ttl="300"
14. Validación
Desde tu laptop, accede a https://www01.yinghli.demo.altostrat.com con curl.
curl -v https://www01.yinghli.demo.altostrat.com * Trying 34.102.178.214:443... * Connected to www01.yinghli.demo.altostrat.com (34.102.178.214) port 443 (#0) * ALPN: offers h2,http/1.1 * TLSv1.3 (OUT), TLS handshake, Client hello (1): * TLSv1.3 (IN), TLS handshake, Server hello (2): * TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8): * TLSv1.3 (IN), TLS handshake, Certificate (11): * TLSv1.3 (IN), TLS handshake, CERT verify (15): * TLSv1.3 (IN), TLS handshake, Finished (20): * TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1): * TLSv1.3 (OUT), TLS handshake, Finished (20): * SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 * ALPN: server accepted h2 * Server certificate: * subject: CN=www01.yinghli.demo.altostrat.com * start date: Jun 4 10:36:43 2023 GMT * expire date: Sep 2 10:36:42 2023 GMT * subjectAltName: host "www01.yinghli.demo.altostrat.com" matched cert's "www01.yinghli.demo.altostrat.com" * issuer: C=US; O=Let's Encrypt; CN=R3 * SSL certificate verify ok. * using HTTP/2 * h2h3 [:method: GET] * h2h3 [:path: /] * h2h3 [:scheme: https] * h2h3 [:authority: www01.yinghli.demo.altostrat.com] * h2h3 [user-agent: curl/8.0.0] * h2h3 [accept: */*] * Using Stream ID: 1 (easy handle 0x149019a00) > GET / HTTP/2 > Host: www01.yinghli.demo.altostrat.com > user-agent: curl/8.0.0 > accept: */* > * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * TLSv1.3 (IN), TLS handshake, Newsession Ticket (4): * old SSL session ID is stale, removing < HTTP/2 200 < server: nginx/1.18.0 < date: Mon, 05 Jun 2023 02:48:43 GMT < content-type: text/html < content-length: 35 < last-modified: Sun, 04 Jun 2023 09:02:16 GMT < etag: "647c5318-23" < accept-ranges: bytes < via: 1.1 google, 1.1 google < alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000 < Page on www01 in asia-southeast1-b * Connection #0 to host www01.yinghli.demo.altostrat.com left intact
15. Pasos de limpieza
Pasos de limpieza de la red del productor
Nota: Los pasos de limpieza solo muestran la configuración relacionada con el balanceador de cargas y PSC. No se incluye la conectividad híbrida ni la VPC.
Desde una sola instancia de Cloud Shell en la terminal, borra los componentes del lab
gcloud compute forwarding-rules delete consumer-url-forwarding-rule --global gcloud compute target-https-proxies delete consumer-url-target-proxy gcloud compute ssl-certificates delete wwwglobal --global gcloud compute url-maps delete consumer-url gcloud compute backend-services delete consumer-bs --global gcloud compute addresses delete httpspsclb --global gcloud beta compute network-endpoint-groups delete consumerpscneg --region=asia-southeast1 gcloud compute service-attachments delete ilbserviceattach --region=asia-southeast1 gcloud compute networks subnets delete psc-nat-subnet --region=asia-southeast1 gcloud compute forwarding-rules delete https-ilb-psc --region=asia-southeast1 gcloud compute addresses delete ilbaddress --region=asia-southeast1 gcloud compute target-https-proxies delete on-premise-httpsproxy --region=asia-southeast1 gcloud compute ssl-certificates delete www01 --region=asia-southeast1 gcloud compute url-maps delete on-premise-url --region=asia-southeast1 gcloud compute backend-services delete on-premise-service-backend --region=asia-southeast1 gcloud compute health-checks delete on-prem-service-hc --region=asia-southeast1 gcloud compute network-endpoint-groups delete on-prem-service-neg --zone=asia-southeast1-b gcloud compute networks subnets delete proxy-subnet-asia-southeast1 --region=asia-southeast1
16. ¡Felicitaciones!
Felicitaciones por completar el codelab.
Temas abordados
- Balanceador de cargas HTTPS interno con NEG híbrido y verificación de estado distribuido
- Conexión de servicio de PSC con balanceador de cargas HTTPS interno
- Configuración del grupo de extremos de red de PSC
- Cómo exponer el NEG de PSC con un balanceador de cargas HTTPS externo