Conectar-se a serviços no local por uma rede híbrida usando o Private Service Connect e o proxy TCP de NEG híbrido

1. Introdução

Um balanceador de carga de proxy TCP regional interno com conectividade híbrida permite disponibilizar um serviço hospedado em ambientes locais ou em outros ambientes na nuvem para os clientes na sua rede VPC.

Se você quiser disponibilizar o serviço híbrido em outras redes VPC, use o Private Service Connect para publicar o serviço. Ao colocar um anexo de serviço na frente do balanceador de carga do proxy TCP regional interno, é possível permitir que os clientes em outras redes VPC acessem os serviços híbridos em execução no local ou em outros ambientes de nuvem.

O que você vai criar

Neste codelab, você vai criar um balanceador de carga de proxy TCP interno com conectividade híbrida para um serviço no local usando um grupo de endpoints de rede. A partir da VPC do consumidor, será possível se comunicar com o serviço no local.

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 que você vai aprender

• Como criar um ILB de proxy TCP com serviço de back-end de NEG híbrido
• Como estabelecer um produtor do Private Service Connect (anexo de serviço) e um consumidor (regra de encaminhamento)
• Como testar e validar a comunicação de serviço entre consumidores e produtores

Observação:este codelab é focado na implementação do ILB de proxy TCP com PSC . A configuração de rede híbrida não está documentada, embora sejam fornecidas documentação de apoio e capturas de tela.

O que é necessário

• Rede híbrida estabelecida, por exemplo, VPN de alta disponibilidade, interconexão, SW-WAN
• Projeto do Google Cloud

Estabelecer conectividade híbrida

Seu Google Cloud e ambientes locais ou de outras nuvens precisam estar conectados por conectividade híbrida, usando anexos da VLAN do Cloud Interconnect ou túneis do Cloud VPN com o Cloud Router. Recomendamos que você use uma conexão de alta disponibilidade.

Um Cloud Router ativado com roteamento dinâmico global aprende sobre o endpoint específico por meio do BGP e o programa na rede VPC do Google Cloud. O roteamento dinâmico regional não é compatível. Rotas estáticas também não são compatíveis.

A rede VPC do Google Cloud usada para configurar o Cloud Interconnect ou o Cloud VPN é a mesma usada para configurar a implantação do balanceamento de carga híbrido. Verifique se os intervalos CIDR da sub-rede da sua rede VPC não entram em conflito com os intervalos CIDR remotos. Quando os endereços IP se sobrepõem, as rotas de sub-rede são priorizadas em relação à conectividade remota.

Para instruções, consulte:

• Documentação do Cloud VPN
• Documentação do Cloud Interconnect

Divulgações de rota personalizadas

As sub-redes abaixo exigem divulgações personalizadas do Cloud Router para a rede local, garantindo que as regras de firewall no local sejam atualizadas.

Sub-rede	Descrição
172.16.0.0/23	Sub-rede de proxy TCP usada para comunicação direta com o serviço local
130.211.0.0/22, 35.191.0.0/16	Verificação de integridade do Google Cloud

2. Antes de começar

Atualizar o projeto para oferecer suporte ao codelab

Este codelab usa $variables para ajudar na implementação da configuração da gcloud no Cloud Shell.

No Cloud Shell, faça o seguinte:

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

3. Configuração do Producer

Crie a VPC do produtor

No Cloud Shell, faça o seguinte:

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

Crie as sub-redes do Producer

No Cloud Shell, faça o seguinte:

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

Crie as sub-redes do proxy TCP

A alocação de proxy é feita no nível da VPC, não no nível do balanceador de carga. É preciso criar uma sub-rede somente proxy em cada região de uma rede virtual (VPC) em que você usa balanceadores de carga baseados no Envoy. Se você implantar vários balanceadores de carga na mesma região e na mesma rede VPC, eles vão compartilhar a mesma sub-rede somente proxy para balanceamento de carga.

1. Um cliente estabelece uma conexão com o endereço IP e a porta da regra de encaminhamento do balanceador de carga.
2. Cada proxy detecta o endereço IP e a porta especificados pela regra de encaminhamento do balanceador de carga correspondente. Um dos proxies recebe e encerra a conexão de rede do cliente.
3. O proxy estabelece uma conexão com o endpoint ou a VM de back-end apropriados em um NEG, conforme determinado pelos serviços de back-end e mapa de URL do balanceador de carga.

É preciso criar sub-redes somente proxy, independentemente de sua rede estar no modo automático ou personalizada. Uma sub-rede somente proxy precisa fornecer 64 ou mais endereços IP. Isso corresponde a um comprimento de prefixo de /26 ou menos. O tamanho de sub-rede recomendado é /23 (512 endereços somente proxy).

Observação: a sub-rede proxy requer uma divulgação do BGP do cliente para o local, portanto, roteável para sua rede local. O acesso ao serviço é possível por meio da sub-rede proxy fornecida.

No Cloud Shell, faça o seguinte:

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

Crie as sub-redes NAT do Private Service Connect

Crie uma ou mais sub-redes dedicadas para usar com o Private Service Connect. Se você estiver usando o console do Google Cloud para publicar um serviço, poderá criar as sub-redes durante esse procedimento. Crie a sub-rede na mesma região do balanceador de carga do serviço. Não é possível converter uma sub-rede normal em uma sub-rede do Private Service Connect.

No Cloud Shell, faça o seguinte:

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

Crie as regras de firewall do produtor

Configure regras de firewall para permitir o tráfego entre os endpoints do Private Service Connect e o anexo de serviço. No codelab, criamos uma regra de firewall de entrada que permite que a sub-rede NAT 100.100.10.0/24 acesse o anexo de serviço do Private Service Connect (balanceador de carga interno).

No Cloud Shell, faça o seguinte:

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 do Cloud Shell. Crie a regra fw-allow-health-check para permitir que as verificações de integridade do Google Cloud alcancem o serviço local (serviço de back-end) na porta 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

Criar uma regra de firewall de entrada que permita que os serviços no local se comuniquem com a sub-rede de proxy na porta 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

Configurar o NEG de conectividade híbrida

Ao criar o NEG,use uma ZONA que minimize a distância geográfica entre o Google Cloud e seu ambiente local ou outro ambiente de nuvem. Por exemplo, se você estiver hospedando um serviço em um ambiente local em Frankfurt, na Alemanha, poderá especificar a zona europe-west3-a do Google Cloud ao criar o NEG.

Além disso, se você estiver usando o Cloud Interconnect, a ZONA usada para criar o NEG precisará estar na mesma região em que o anexo do Cloud Interconnect foi configurado.

Para conhecer as regiões e zonas disponíveis, consulte a documentação do Compute Engine: regiões e zonas disponíveis.

No Cloud Shell, crie um NEG de conectividade híbrida usando o 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

No Cloud Shell, adicione o endpoint IP:porta local ao 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"

Configurar o balanceador de carga

Nas etapas a seguir, você vai configurar o balanceador de carga (regra de encaminhamento) e associar ao grupo de endpoints de rede

No Cloud Shell, crie a verificação de integridade regional transmitida ao serviço no local

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

No Cloud Shell, crie o serviço de back-end para o back-end 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

No Cloud Shell, adicione o back-end de NEG híbrido ao serviço de back-end. Para MAX_CONNECTIONS, insira o máximo de conexões simultâneas que o back-end deve processar.

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

No Cloud Shell, crie o proxy de destino

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

No Cloud Shell, crie a regra de encaminhamento (ILB)

Crie a regra de encaminhamento usando o comando gcloud compute encaminhamento-rules create.

Substitua FWD_RULE_PORT por um único número de porta de 1 a 65535. A regra de encaminhamento só encaminha pacotes com uma porta de destino correspondente.

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

Consiga o endereço IP do balanceador de carga 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. Validar o balanceador de carga

No Console do Cloud, acesse Serviços de rede → Balanceamento de carga → Balanceadores de carga. O NEG 1 é verde, indicando uma verificação de integridade bem-sucedida para o serviço local.

Selecionar ‘on-premise-service-backend' gera o endereço IP do front-end

5. Conferir as rotas aprendidas no local

Navegue até Rede VPC → Rotas. A sub-rede de serviço local aprendida 192.168.1.0/27

6. Valide a conectividade com o serviço local

Na VPC dos produtores, vamos criar uma VM para testar a conectividade com o serviço no local depois que o anexo de serviço for configurado.

No Cloud Shell, crie a instância de teste na VPC do produtor

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 o IAP se conecte às instâncias de VM, crie uma regra de firewall que:

• Aplica-se a todas as instâncias de VM que você quer disponibilizar usando o IAP.
• Permite tráfego de entrada no intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para encaminhamento de TCP.

No Cloud Shell, crie a instância de teste na VPC do produtor

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

Faça login em test-box-us-central1 usando o IAP no Cloud Shell para validar a conectividade com o serviço local. Para isso, execute um curl no endereço IP do balanceamento de carga. Tente de novo se houver um tempo limite.

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

Execute um curl validando a conectividade com o serviço no local. Depois de validar, saia da VM e volte ao prompt do Cloud Shell. Substitua o IP do balanceador de carga interno com base na saída identificada nas etapas 3 e 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. Criar o anexo de serviço do Private Service Connect

Nas etapas a seguir, vamos criar o anexo de serviço. Quando pareado com um endpoint do consumidor, o acesso ao serviço no local é feito sem a necessidade de peering de VPC.

Criar o anexo de serviço

No Cloud Shell, crie o anexo de serviço

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: se você estiver usando uma VPC compartilhada, crie o anexo de serviço no projeto de serviço

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>

Valide o anexo de serviço TCP

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

8. Opcional: acesse Serviços de rede → Private Service Connect para conferir o anexo de serviço recém-criado

Selecionar Service-1 oferece mais detalhes, incluindo o URI do anexo de serviço usado pelo consumidor para estabelecer uma conexão de serviço particular. Anote o URI, porque ele será usado em uma etapa posterior.

Detalhes do anexo de serviço:projects/<projectname>/regions/us-central1/serviceAttachments/service-1

9. Configuração do consumidor

Crie a VPC do consumidor

No Cloud Shell, faça o seguinte:

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

Crie as sub-redes do consumidor

No Cloud Shell, crie a sub-rede do GCE

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

Dentro do Cloud Shell, crie a sub-rede do endpoint do consumidor

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

Crie o endpoint do consumidor (regra de encaminhamento)

No Cloud Shell, crie o endereço IP estático que será usado como um endpoint do consumidor

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

Vamos usar o URI do anexo de serviço gerado anteriormente para criar o endpoint do consumidor

Dentro do Cloud Shell, crie o endpoint do 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. Validar o Consumer Private Service Connect - VPC de consumidor

Na VPC do consumidor, verifique se o Private Service Connect foi bem-sucedido navegando até Serviços de rede → Private Service Connect→ Endpoints conectados. Observe a conexão psc-consumer-1 estabelecida e o endereço IP correspondente que criamos anteriormente.

Ao selecionar psc-consumer-1, detalhes de adição são fornecidos, incluindo o URI do anexo de serviço

11. Validar o Consumer Private Service Connect - VPC do produtor

Na VPC do produtor, verifique se está tudo certo com o Private Service Connect. Para isso, acesse Serviços de rede → Private Service Connect→Serviço publicado. A conexão service-1 publicada agora indica uma regra de encaminhamento (endpoint de conexão).

12. Criar uma zona DNS particular e Registro A

Crie a zona de DNS particular mapeada para o endpoint de conexão do PSC, permitindo acesso contínuo ao produtor de qualquer host na VPC.

Observação: não é possível acessar um endpoint do consumidor por peering de VPC

No 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. Validar o acesso do consumidor ao serviço de produtores usando a VM

Na VPC Consumers, vamos criar uma VM para testar a conectividade com o serviço no local acessando o endpoint do consumidor service1.codelabs.net

No Cloud Shell, crie a instância de teste na VPC do 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 o IAP se conecte às instâncias de VM, crie uma regra de firewall que:

• Aplica-se a todas as instâncias de VM que você quer disponibilizar usando o IAP.
• Permite tráfego de entrada no intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para encaminhamento de TCP.

No Cloud Shell, crie a instância de teste na VPC do consumidor

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

Faça login na VM do consumidor usando o IAP no Cloud Shell para validar a conectividade com o serviço local executando um curl no FQDN do DNS service1.codelab.net. Tente de novo se houver um tempo limite.

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

Execute um curl validando a conectividade com o serviço no local. Após a validação, saia da VM e retorne ao prompt do Cloud Shell.

Dentro do Cloud Shell, execute um 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!!

Veja abaixo um exemplo de captura do serviço local. O endereço IP de origem 172.16.0.2 é do intervalo de sub-rede do proxy TCP 172.16.0.0/23.

14. Limpeza do produtor

Excluir componentes do Producer

No Cloud Shell, exclua os componentes do produtor

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. Limpeza do consumidor

Excluir componentes do consumidor

Excluir os componentes do consumidor no Cloud Shell

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. Parabéns

Parabéns, você configurou e validou com sucesso o Private Service Connect com o proxy TCP.

Você criou a infraestrutura do produtor e adicionou um anexo de serviço à VPC do produtor que aponta para um serviço no local. Você aprendeu a criar um endpoint na VPC do consumidor que permite a conectividade com o serviço no local.

Qual é a próxima etapa?

Confira alguns destes codelabs:

• Como usar serviços particulares para publicar e consumir serviços com o GKE
• Como usar o Private Service Connect para publicar e consumir serviços

Leia mais e Vídeos

• Visão geral do Private Service Connect
• O que é o Private Service Connect?

Documentos de referência

• Proxy TCP interno
• Visão geral das verificações de integridade
• Como publicar um serviço