1. Introdução
O grupo de endpoints de rede (NEG) do Private Service Connect (PSC) oferece suporte à vinculação de um balanceador de carga HTTPS interno com um balanceador de carga HTTPS externo. Isso fornece verificações de integridade distribuídas e tráfego do plano de dados para o local usando intervalos definidos pelo cliente. Além disso, essa topologia também oferece suporte a várias VPCs conectadas ao local físico por várias interconexões regionais.
Neste codelab, vamos demonstrar como configurar isso de ponta a ponta com base na topologia abaixo. Da esquerda para a direita, os clientes no local têm uma VM para simular serviços HTTP, aproveitar a conectividade híbrida (HA-VPN ou InterConnect) e o NEG híbrido para expor pelo balanceador de carga HTTPS interno. O PSC usa o HTTPS LB interno como anexos de serviço. O NEG do PSC consome os anexos como serviço de back-end, exposto ao balanceador de carga HTTPS externo. Os usuários da Internet podem usar a rede global do Google para acelerar o acesso aos serviços HTTP no local.
Figura 1. O Private Service Connect usa o grupo de endpoints de rede e os anexos de serviço para conectar o balanceador de carga HTTPS externo ao balanceador de carga HTTPS interno e estender o back-end para o local.
O que você vai aprender
- Balanceador de carga HTTPS interno com NEG híbrido e verificação de integridade distribuída
- Anexo de serviço do PSC com balanceador de carga HTTPS interno
- Configuração do grupo de endpoints de rede do PSC
- Exponha o PSC NEG com o balanceador de carga HTTPS externo
O que é necessário
- Conhecimento sobre conectividade híbrida, como VPN de alta disponibilidade
- Conhecimento sobre balanceamento de carga HTTPS interno/externo
- Conhecimento do Private Service Connect
2. Antes de começar
Observação: o Codelab oferece etapas de configuração e validação com base na topologia ilustrada. Modifique o procedimento conforme necessário para atender aos requisitos da sua organização. As permissões do IAM não estão no escopo do codelab.
O codelab vai usar um projeto para simular todo o processo. Também é possível usar vários projetos.
Projeto único: atualizar o projeto para oferecer suporte à rede de produtores e consumidores
No Cloud Shell, verifique se o ID do projeto está configurado
gcloud config list project gcloud config set project [YOUR-PROJECT-NAME] prodproject=YOUR-PROJECT-NAME echo $prodproject
3. Criar recursos no local
Na seção a seguir, vamos configurar uma VPC e VMs no local para simular os serviços do cliente no local.
Rede VPC
No Cloud Shell
gcloud compute networks create vpc-demo-onprem --project=$prodproject --subnet-mode=custom
Criar sub-rede
No 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
Crie regras de firewall.
O balanceador de carga HTTPS interno oferece suporte à verificação de integridade distribuída. As regras de firewall só precisam permitir o intervalo de IP da sub-rede do proxy. Siga o documento para adicionar seus projetos à lista de permissões.
No Cloud Shell, crie uma regra de firewall para ativar as verificações de integridade do back-end e o tráfego do plano de dados das sub-redes 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
No Cloud Shell, crie uma regra de firewall para permitir que o IAP se conecte às suas instâncias 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. Criar instâncias de VM no local
Esta VM simula serviços no local e precisa ser exposta com o balanceador de carga HTTPS interno usando um NEG híbrido.
No Cloud Shell, crie a instância 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'
Na próxima seção, vamos usar o letsencrypt para gerar certificados e instalar no Nginx. Faça o download do arquivo de chave pública e privada para a próxima etapa. É necessário abrir temporariamente a porta TCP 80 para a Internet para a geração de certificados.
Verifique se a VM tem um nome de domínio resolvido publicamente. Por exemplo, no Cloud DNS, adicione um registro A [www01.yinghli.demo.altostrat.com](http://www01.yinghli.demo.altostrat.com)
e aponte para o endereço IP público da 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"
No console da VM www01, siga as orientações para instalar certificados no Nginx e faça uma cópia de fullchain.pem e private.pem para as etapas a seguir.
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. Criar a rede VPC dos produtores
Observação: a configuração de rede híbrida NÃO está incluída nesta configuração.
Rede VPC
No Cloud Shell
gcloud compute networks create vpc-demo-producer --project=$prodproject --subnet-mode=custom
Criar sub-rede
No 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
Criar sub-rede de proxy
No 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
Conectividade híbrida
Siga a documentação do Cloud VPN para implementar a conectividade VPN de alta disponibilidade entre a VPC do local e do produtor. Mantenha a configuração padrão no Cloud Router. Não precisamos adicionar 130.211.0.0/22, 35.191.0.0/16 às divulgações do BGP.
6. Criar NEG híbrido para produtores
Criar um grupo de endpoints de rede híbrido e adicionar o IP:PORT da VM no local ao NEG.
No 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. Criar o balanceador de carga HTTPS interno do produtor
Atualmente, o balanceador de carga HTTPS externo só oferece suporte ao protocolo HTTPS para o PSC NEG( documentos). Ao publicar serviços, precisamos usar o balanceador de carga HTTPS interno e ativar o acesso global das regras de encaminhamento.
No Cloud Shell, crie a verificação de integridade regional.
gcloud compute health-checks create https on-prem-service-hc \ --region=asia-southeast1 \ --use-serving-port
No Cloud Shell, crie o serviço de back-end e adicione a NEG híbrida.
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
No Cloud Shell, crie o mapa de URLs
gcloud compute url-maps create on-premise-url \ --default-service on-premise-service-backend \ --region=asia-southeast1
No Cloud Shell, crie os certificados SSL regionais. É feito o download de dois arquivos de certificado da VM.
gcloud compute ssl-certificates create www01 \ --certificate=fullchain.pem \ --private-key=private.pem \ --region=asia-southeast1
No Cloud Shell, crie um 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
No Cloud Shell, reserve um IP estático interno e crie a regra de encaminhamento
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. Criar instância de VM do produtor
Crie uma VM de produtor para verificação.
No 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 o IAP se conecte às suas instâncias de VM, crie uma regra de firewall que:
No 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
No console da VM do produtor, acesse [
www01.yinghli.demo.altostrat.com](https://www01.yinghli.demo.altostrat.com)
e resolva o endereço IP do balanceador de carga HTTPS interno. O HTTP 200 indicou que a configuração funcionou conforme o esperado.
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
Observação: não é possível acessar os serviços HTTPS da VM 10.0.0.2 diretamente porque o firewall local só permite o acesso à sub-rede de proxy 10.0.3.0/24.
9. Criar sub-rede NAT do PSC
No 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. Criar um anexo de serviço HTTPs
No Cloud Shell, crie o anexo de serviço 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
Valide o anexo do serviço HTTPs
gcloud compute service-attachments describe ilbserviceattach --region asia-southeast1
Nome do anexo do serviço de registro:
projects/<project>/regions/asia-southeast1/serviceAttachments/ilbserviceattach
11. Criar rede VPC dos consumidores
Na seção a seguir, a VPC consumidora é configurada no mesmo projeto, mas também é possível usar projetos diferentes. A comunicação entre as redes do consumidor e do produtor é realizada por meio do anexo de serviço definido na rede do produtor.
Rede VPC
No Cloud Shell
gcloud compute networks create vpc-demo-consumer --project=$prodproject --subnet-mode=custom
Criar sub-rede
No 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. Criar grupo de endpoints da rede PSC
Criar PSC NEG
Copie o nome do anexo de serviços https anterior e cole nos parâmetros --psc-target-service
No 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
Após a configuração do PSC NEG na interface, siga Private Service Connect
-> Published Services
-> Observe que a conexão ilbserviceattach
publicada agora indica uma regra de encaminhamento.
13. Criar balanceador de carga HTTPS externo do consumidor
Crie um balanceador de carga HTTPS externo e use o NEG do PSC como serviços de back-end (documentação).
No 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
Atualizar o registro DNS de www01.yinghli.demo.altostrat.com e apontar para o endereço IP público do balanceador de carga 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. Validação
No seu laptop, acesse https://www01.yinghli.demo.altostrat.com com 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. Etapas de limpeza
Etapas de limpeza da rede do produtor
Observação: as etapas de limpeza mostram apenas a configuração relacionada ao Load Balancer e ao PSC. A VPC e a conectividade híbrida não estão incluídas.
Em um único Cloud Shell no terminal, exclua os componentes do laboratório
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. Parabéns!
Parabéns por concluir o codelab.
O que vimos
- Balanceador de carga HTTPS interno com NEG híbrido e verificação de integridade distribuída
- Anexo de serviço do PSC com balanceador de carga HTTPS interno
- Configuração do grupo de endpoints de rede do PSC
- Exponha o PSC NEG com o balanceador de carga HTTPS externo