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

Com um balanceador de carga de proxy TCP regional interno que permite a conectividade híbrida, é possível disponibilizar um serviço hospedado no local ou em outros ambientes de nuvem para 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 clientes em outras redes VPC alcancem os serviços híbridos executados 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 local usando um grupo de endpoints de rede. A VPC do consumidor poderá se comunicar com o serviço 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 do codelab.

O que você vai aprender

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

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, mas há documentação e capturas de tela de suporte.

O que é necessário

• Redes híbridas estabelecidas, como VPN de alta disponibilidade, Interconnect e SW-WAN
• Projeto do Google Cloud

Estabelecer conectividade híbrida

O Google Cloud e os ambientes locais ou em nuvem precisam ser conectados por uma 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 pelo BGP e o programa na sua 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 rede usada para configurar a implantação do balanceamento de carga híbrido. Verifique se os intervalos de CIDR da sub-rede da 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 local sejam atualizadas.

Sub-rede	Descrição
172.16.0.0/23	Sub-rede de proxy TCP usada para se comunicar diretamente 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 $variáveis 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 produtor

Criar a VPC do produtor

No Cloud Shell, faça o seguinte:

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

Criar as sub-redes do produtor

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

Criar as sub-redes de proxy TCP

A alocação de proxy está no nível da VPC, não no nível do balanceador de carga. Crie uma sub-rede somente proxy em cada região de uma rede virtual (VPC) em que você usa balanceadores de carga baseados em Envoy. Se você implantar vários balanceadores de carga na mesma região e 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 adequados em um NEG, conforme determinado pelos serviços de back-end e mapa de URL do balanceador de carga.

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

Observação:a sub-rede de proxy exige um anúncio de BGP do cliente para o ambiente local, portanto, roteável para sua rede local. O acesso ao serviço é possível pela sub-rede de 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

Criar 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 regular 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

Criar 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

No 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

Crie uma regra de firewall de entrada que permita que os serviços locais 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 de outra 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 precisa estar na mesma região em que o anexo de interconexão do Cloud Interconnect foi configurado.

Para ver 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 associá-lo ao grupo de endpoints de rede.

No Cloud Shell, crie a verificação de integridade regional transmitida ao serviço 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 NEG híbrido ao serviço de back-end. Em 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 forwarding-rules create.

Substitua FWD_RULE_PORT por um único número de porta de 1 a 65535. A regra de encaminhamento 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. Observação: o NEG é verde, indicando uma verificação de integridade bem-sucedida para o serviço local.

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

5. Conferir as rotas aprendidas no ambiente local

Acesse Rede VPC → Rotas. Observação: a sub-rede de serviço local aprendida 192.168.1.0/27

6. Validar a conectividade com o serviço local

Na VPC dos produtores, vamos criar uma VM para testar a conectividade com o serviço local. Depois, o anexo de serviço será 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 suas instâncias de VM, crie uma regra de firewall que:

• Aplica-se a todas as instâncias de VM que você quer acessar usando o IAP.
• Permite o tráfego de entrada do intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para o 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 executando um curl no endereço IP do balanceador 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 para validar a conectividade com o serviço local. Depois de validado, 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 do serviço do Private Service Connect

Nas etapas a seguir, vamos criar o anexo de serviço. Depois de pareado com um endpoint do consumidor, o acesso ao serviço 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>

Validar o anexo de serviço TCP

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

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

Ao selecionar Service-1, você tem 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

Criar a VPC do consumidor

No Cloud Shell, faça o seguinte:

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

Criar 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

No 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

Criar 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.

No 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 Private Service Connect do consumidor: VPC do consumidor

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

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

11. Validar o Private Service Connect do consumidor: VPC do produtor

Na VPC do produtor, verifique se a conexão de serviço particular foi bem-sucedida navegando até Serviços de rede → Private Service Connect → Serviço publicado. Observe que a conexão do serviço-1 publicado agora indica uma regra de encaminhamento (endpoint de conexão).

12. Criar uma zona de DNS particular e um registro A

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

Observação:o acesso a um endpoint do consumidor por peering de VPC não é compatível.

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 dos produtores usando a VM

Na VPC do consumidor, vamos criar uma VM para testar a conectividade com o serviço 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 suas instâncias de VM, crie uma regra de firewall que:

• Aplica-se a todas as instâncias de VM que você quer acessar usando o IAP.
• Permite o tráfego de entrada do intervalo de IP 35.235.240.0/20. Esse intervalo contém todos os endereços IP que o IAP usa para o 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 consumer-vm usando o IAP no Cloud Shell para validar a conectividade com o serviço local executando um curl no FQDN 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 para validar a conectividade com o serviço local. Depois de validado, saia da VM e volte ao prompt do Cloud Shell.

No 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!!

Confira 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 de contas de consumidor

Excluir componentes do consumidor

No Cloud Shell, exclua os componentes do 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. Parabéns

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

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

Qual é a próxima etapa?

Confira alguns destes codelabs:

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

Leituras e vídeos complementares

• 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