1. Introdução
O grupo de endpoints de rede (NEG) do Private Service Connect (PSC) oferece suporte ao encadeamento de um balanceador de carga HTTPS interno com um 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, várias VPCs que se conectam ao local usando vários InterConnects regionais também são compatíveis com essa topologia.
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 PSC NEG consome os anexos como serviço de back-end, expostos ao HTTPS LB 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 do serviço PSC com balanceador de carga HTTPS interno
- Configuração do grupo de endpoints da rede PSC
- Exponha o PSC NEG com o balanceador de carga HTTPS externo
O que é necessário
- Conhecimento de conectividade híbrida, como VPN de alta disponibilidade.
- Conhecimento sobre balanceamento de carga HTTPS interno/externo
- Conhecimento sobre o 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 deste codelab.
O codelab usará um projeto para simular todo o processo. Vários projetos também são aceitos.
Projeto único: atualizar o projeto para oferecer suporte às redes do produtor e do consumidor
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 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
Criar 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. Confira a documentação abaixo para autorizar seus projetos.
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 seção a seguir, usaremos o letsencrypt para gerar certificados e instalá-los no Nginx. Faça o download do arquivo das chaves pública e privada para a próxima etapa. É necessário abrir temporariamente a porta TCP 80 na Internet para gerar o certificado.
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 dos arquivos fullchain.pem e private.pem para seguir as etapas.
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 rede VPC de 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 de 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 balanceador de carga HTTPS interno do produtor
No momento, 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 o 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
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 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 do 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 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 como 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 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 a rede VPC dos consumidores
Na seção a seguir, a VPC do consumidor é configurada no mesmo projeto, mas projetos diferentes também são compatíveis. 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 dos 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
-> 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 PSC NEG 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
Atualize o registro DNS de www01.yinghli.demo.altostrat.com e aponte 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 as configurações relacionadas ao balanceador de carga e ao PSC. A VPC e a conectividade híbrida não estão incluídas.
Exclua os componentes do laboratório em um único Cloud Shell no terminal
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 do serviço PSC com balanceador de carga HTTPS interno
- Configuração do grupo de endpoints da rede PSC
- Exponha o PSC NEG com o balanceador de carga HTTPS externo