O Cloud Service Mesh e o Traffic Director são agora o Cloud Service Mesh. Para mais informações, consulte a vista geral do Cloud Service Mesh.

Esta página foi traduzida pela API Cloud Translation.

Configure serviços de limite de rede com grupos de pontos finais de rede de conetividade híbrida

A Google oferece vários serviços de limite de rede que podem aumentar as capacidades e a segurança dos serviços baseados fora de Google Cloud(serviços no local e em várias nuvens), por exemplo, num centro de dados no local ou noutra nuvem pública.

Estes serviços de limite de rede permitem-lhe fazer o seguinte:

Aceite e encaminhe o tráfego de clientes externos a nível global com um único VIP Anycast.
Reduza a carga do servidor terminando o tráfego TLS no limite com um balanceador de carga de aplicações externo e certificados SSL geridos pela Google.
Ative regras de firewall de aplicações Web (WAF) pré-configuradas e aplique listas de autorizações e listas de recusas ao tráfego de entrada com o Google Cloud Armor.
Controle o acesso dos utilizadores às suas aplicações e recursos com o Identity-Aware Proxy (IAP).
Otimize o fornecimento de conteúdo e a latência do utilizador final com o Cloud CDN.

Exemplo de serviços de limite de rede. — Exemplo de serviços de limite de rede (clique para aumentar)

Para disponibilizar estas vantagens aos seus serviços privados, no local ou em várias nuvens, implementa um Application Load Balancer externo para receber tráfego da Internet pública. O balanceador de carga da aplicação externo encaminha o tráfego para um proxy intermédio que o Cloud Service Mesh configura. Este proxy intermédio encaminha o tráfego para o seu ambiente nas instalações ou ambiente nãoGoogle Cloud através do Cloud VPN ou do Cloud Interconnect.

Este tutorial explica um exemplo completo que usa o Cloud Armor no limite da rede da Google para permitir seletivamente que os clientes acedam a um serviço no local de forma privada. Os clientes têm acesso permitido com base no respetivo endereço IP.

Conclui as seguintes tarefas:

Implemente o Envoy como um proxy intermédio num grupo de instâncias geridas (MIG). Este proxy do Envoy está automaticamente ligado ao Cloud Service Mesh.
Crie uma instância de máquina virtual (VM) privada e no local simulada. Num exemplo do mundo real, provavelmente já teria uma VM no local.
Configure o Cloud Service Mesh para encaminhar todos os pedidos que chegam ao proxy intermédio para a VM no local simulada.
Crie um Application Load Balancer externo para receber tráfego da Internet pública e encaminhá-lo para o proxy intermédio.
Associe uma política de segurança do Cloud Armor ao Application Load Balancer externo.

Depois de concluir estas tarefas, pode explorar opcionalmente serviços de limite adicionais e funcionalidades avançadas de gestão de tráfego.

Pré-requisitos

Antes de configurar o proxy intermédio, conclua as seguintes tarefas:

Reveja o artigo Prepare-se para configurar a malha de serviço na nuvem com o Envoy e conclua todas as tarefas de pré-requisitos, que incluem a concessão das autorizações e funções necessárias, bem como a ativação da API Cloud Service Mesh.
Certifique-se de que os seus pontos finais privados no local são acessíveis a partir da sua rede da nuvem virtual privada (VPC) através do Cloud VPN ou do Cloud Interconnect. Google Cloud O exemplo usado neste tutorial apenas encaminha tráfego para um ponto final dentro Google Cloud, pelo que não precisa de configurar a conetividade híbrida para acompanhar. Num cenário de implementação real, seria necessário configurar a conetividade híbrida.
Certifique-se de que os intervalos CIDR da sub-rede da VPC não entram em conflito com os intervalos CIDR remotos. Quando os endereços IP se sobrepõem, os encaminhamentos de sub-rede têm prioridade sobre a conetividade remota.
Para esta demonstração, obtenha as autorizações necessárias para criar e atualizar políticas de segurança do Cloud Armor. As autorizações podem variar se quiser usar um serviço diferente, como a RFC na nuvem.

Implemente o proxy intermédio em VMs do Compute Engine

Esta secção descreve como implementar o Envoy como um proxy intermédio no Compute Engine para receber tráfego do equilibrador de carga externo e encaminhá-lo para o seu destino remoto.

Crie o modelo de instância para o proxy intermédio

Um modelo de instância especifica a configuração das VMs num grupo de instâncias geridas (MIG).

Use o seguinte modelo para criar instâncias de VM com um proxy Envoy ligado ao Cloud Service Mesh:

gcloud compute instance-templates create td-middle-proxy \
    --service-proxy=enabled \
    --tags=allow-hc

Para personalizar a implementação do Envoy, por exemplo, especificando o nome da rede, definindo um caminho do registo ou ativando o rastreio, consulte o guia da opção de implementação automatizada do Envoy.

Crie o MIG para o proxy intermédio

Crie o MIG com base no modelo. Neste exemplo, pode manter o tamanho do grupo de instâncias de 1 para implementar uma única instância. Para utilização em produção, ative o dimensionamento automático, por exemplo, com base na utilização da CPU, para evitar criar um gargalo se o seu proxy intermédio tiver de processar muito tráfego.
```
gcloud compute instance-groups managed create td-middle-proxy-us-central1-a \
    --zone=us-central1-a \
    --template=td-middle-proxy \
    --size=1
```

Para configurações e validação futuras, identifique e armazene o endereço IP interno da instância em MIDDLE_PROXY_IP:

MIDDLE_PROXY_IP=$(gcloud compute instances list \
    --filter="name~'td-middle-proxy-us-central1-a-.*'" \
    --zones=us-central1-a \
    --format="value(networkInterfaces.networkIP)")

Neste exemplo, criamos o GIG que contém instâncias de VMs que executam o Envoy em us-central1-a. Mais adiante neste tutorial, vai criar um balanceador de carga externo para processar o tráfego público da Internet dos seus clientes.

Uma vez que o equilibrador de carga externo pode encaminhar automaticamente o tráfego para a região mais próxima dos seus clientes e para o GIG nessa região, recomendamos que considere criar vários GIGs. Para ver uma lista completa das regiões e zonas disponíveis do Google Cloud, consulte o artigo Regiões e zonas.

Implemente o serviço nas instalações simulado

Esta secção descreve a implementação de um grupo de pontos finais de rede (NEG) de conetividade híbrida. Numa implementação de produção, este NEG conteria um ponto final (IP:port) que é resolvido para o seu servidor no local. Neste exemplo, cria uma VM do Compute Engine acessível num IP:port. Esta VM funciona como o seu servidor no local simulado.

Crie a VM no local simulada

Implemente uma única instância de VM para simular um servidor privado no local:

gcloud compute instances create on-prem-vm \
    --zone=us-central1-a \
    --metadata startup-script='#! /bin/bash
## Installs apache and a custom homepage
sudo su -
apt-get update
apt-get install -y apache2
cat <<EOF > /var/www/html/index.html
<html><body><h1>Hello world from on-premises!</h1></body></html>
EOF'

Identificar e armazenar o respetivo endereço IP interno para configurações e validação futuras. O servidor nesta VM escuta pedidos de entrada na porta 80:

ON_PREM_IP=$(gcloud compute instances describe on-prem-vm \
    --zone=us-central1-a \
    --format="value(networkInterfaces.networkIP)" | sed "s/['\[\]]*//g")

Crie o NEG

Crie o NEG para esta configuração de demonstração especificando o non-gcp-private-ip-porttipo de ponto final de rede. Adicione o endereço IP e a porta da sua VM no local simulada como um ponto final a este NEG. Seguindo o passo anterior, o endereço IP é armazenado na variável de ambiente ON_PREM_IP.

Crie o NEG:

gcloud compute network-endpoint-groups create td-on-prem-neg \
    --network-endpoint-type=non-gcp-private-ip-port \
    --zone=us-central1-a

Adicione o IP:port ao seu novo NEG:

gcloud compute network-endpoint-groups update td-on-prem-neg \
    --zone=us-central1-a \
    --add-endpoint="ip=$ON_PREM_IP,port=80"

Configure o Cloud Service Mesh com componentes do Cloud Load Balancing

Esta secção mostra como configurar a malha de serviços na nuvem e ativar o proxy intermédio para encaminhar o tráfego para o seu serviço privado no local. Configura os seguintes componentes:

Uma verificação de funcionamento. Esta verificação do estado de funcionamento comporta-se de forma ligeiramente diferente das verificações do estado de funcionamento configuradas para outros tipos de NEG.
Um serviço de back-end. Para mais informações, consulte a Vista geral dos serviços de back-end.
Um mapa de regras de encaminhamento. Este passo inclui a criação de uma regra de encaminhamento, um proxy de destino e um mapa de URLs. Para mais informações, consulte o artigo Mapas de regras de encaminhamento.

Crie a verificação de funcionamento

As verificações de funcionamento confirmam que os seus pontos finais estão em bom estado e podem receber pedidos. A verificação de funcionamento deste tipo de NEG baseia-se no mecanismo de verificação de funcionamento distribuído do Envoy.

Outros tipos de NEG usam o sistema de verificação do estado de funcionamento centralizado da Google: Google Cloud

gcloud compute health-checks create http td-on-prem-health-check

Crie o serviço de back-end

Crie um serviço de back-end com o esquema de balanceamento de carga INTERNAL_SELF_MANAGED a usar com a malha de serviço do Google Cloud. Quando criar este serviço de back-end, especifique a verificação de funcionamento que criou anteriormente:
```
gcloud compute backend-services create td-on-prem-backend-service \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --health-checks=td-on-prem-health-check
```

Adicione o NEG que criou anteriormente como o back-end deste serviço de back-end:

gcloud compute backend-services add-backend td-on-prem-backend-service \
    --global \
    --network-endpoint-group=td-on-prem-neg \
    --network-endpoint-group-zone=us-central1-a \
    --balancing-mode=RATE \
    --max-rate-per-endpoint=5

Crie o mapa de regras de encaminhamento

O mapa de regras de encaminhamento define como o Cloud Service Mesh encaminha o tráfego para o seu serviço de back-end.

Crie um mapa de URLs que use o serviço de back-end definido anteriormente:

gcloud compute url-maps create td-hybrid-url-map \
    --default-service=td-on-prem-backend-service

Crie um ficheiro denominado target_proxy.yaml com o seguinte conteúdo:

name: td-hybrid-proxy
proxyBind: true
urlMap: global/urlMaps/td-hybrid-url-map

Use o comando import para criar o proxy HTTP de destino (para mais informações, consulte Proxies de destino para a Cloud Service Mesh):
```
gcloud compute target-http-proxies import td-hybrid-proxy \
    --source=target_proxy.yaml
```
Crie uma regra de encaminhamento que faça referência a este proxy HTTP de destino. Defina o endereço IP da regra de encaminhamento como 0.0.0.0. Se definir o endereço IP da regra como 0.0.0.0, o tráfego é encaminhado com base na porta de entrada, no nome do anfitrião HTTP e nas informações de caminho configuradas no mapa de URLs. O endereço IP especificado no pedido HTTP é ignorado.
```
gcloud compute forwarding-rules create td-hybrid-forwarding-rule \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --address=0.0.0.0 \
    --target-http-proxy=td-hybrid-proxy \
    --ports=8080 \
    --network=default
```

Verifique se o proxy intermédio consegue encaminhar pedidos para o serviço no local simulado

O Cloud Service Mesh está agora configurado para encaminhar o tráfego através do proxy intermédio para o seu serviço privado no local simulado. Pode validar esta configuração criando uma VM de cliente de teste, iniciando sessão nessa VM e enviando um pedido ao proxy intermédio que está a executar o Envoy. Depois de validar a configuração, elimine a VM do cliente de teste.

Obtenha o endereço IP do proxy intermédio. Só precisa destas informações para o passo de validação:
```
gcloud compute instances list
```
Anote ou tome nota do endereço IP da instância no td-middle-proxy-us-central1-a MIG.

Crie uma instância de cliente de teste:

gcloud compute instances create test-client \
    --zone=us-central1-a

Use o código ssh para iniciar sessão no cliente de teste:

gcloud compute ssh test-client
    --zone=us-central1-a

Envie um pedido para a VM do proxy intermédio, substituindo o endereço IP que obteve anteriormente por MIDDLE_PROXY_IP:
```
curl $MIDDLE_PROXY_IP:8080
```
Deverá ver o seguinte resultado:
```
Hello world from on-premises!
```

Saia da VM do cliente de teste. Depois de sair, pode eliminar a VM:

gcloud compute instances delete test-client \
    --zone=us-central1-a

Implemente o balanceador de carga de aplicações externo

Nesta secção, implementa um Application Load Balancer externo que envia o tráfego recebido para o proxy intermédio. Esta implementação é uma configuração padrão do Application Load Balancer externo.

Reserve um endereço IP externo

Crie um endereço IP externo estático global (external-lb-vip) para o qual os clientes externos enviarão tráfego. Vai obter este endereço IP externo durante o passo de validação mais adiante neste tutorial.

gcloud compute addresses create external-lb-vip \
    --ip-version=IPV4 \
    --global

Configure o balanceador de carga HTTP externo

Configure o equilibrador de carga externo para encaminhar o tráfego de clientes da Internet para o proxy intermédio já configurado.

Crie uma verificação de funcionamento que seja usada para determinar se o MIG que executa o proxy intermédio está em bom estado e é capaz de receber tráfego:
```
gcloud compute health-checks create tcp tcp-basic-check \
    --port=8080
```

Crie uma regra de firewall para permitir a verificação de funcionamento. Aqui, volta a usar a etiqueta allow-hc para aplicar a regra de firewall às VMs de proxy intermédias:

gcloud compute firewall-rules create fw-allow-health-checks \
    --network=default \
    --action=ALLOW \
    --direction=INGRESS \
    --source-ranges=35.191.0.0/16,130.211.0.0/22 \
    --target-tags=allow-hc \
    --rules=tcp

Crie um serviço de back-end:

gcloud compute backend-services create td-middle-proxy-backend-service \
    --protocol=HTTP \
    --health-checks=tcp-basic-check \
    --global

Adicione o MIG intermédio como back-end a este serviço de back-end:

gcloud compute backend-services add-backend td-middle-proxy-backend-service \
    --instance-group=td-middle-proxy-us-central1-a \
    --instance-group-zone=us-central1-a \
    --global

Crie um mapa de URLs para encaminhar os pedidos recebidos para o proxy intermédio como o serviço de back-end predefinido:
```
gcloud compute url-maps create lb-map-http \
    --default-service=td-middle-proxy-backend-service
```
Crie um proxy HTTP de destino para que os pedidos ao endereço IP virtual (VIP) da regra de encaminhamento do balanceador de carga externo sejam processados de acordo com o mapa de URLs:
```
gcloud compute target-http-proxies create http-lb-proxy \
    --url-map=lb-map-http
```

Crie uma regra de encaminhamento global para encaminhar pedidos recebidos para o proxy HTTP de destino:

gcloud compute forwarding-rules create http-forwarding-rule \
    --address=external-lb-vip\
    --global \
    --load-balancing-scheme=EXTERNAL \
    --target-http-proxy=http-lb-proxy \
    --ports=80

Defina a porta com nome do MIG

Defina uma porta com nome para o grupo de instâncias para permitir que o proxy intermédio receba tráfego HTTP do balanceador de carga externo:

gcloud compute instance-groups managed set-named-ports td-middle-proxy-us-central1-a \
    --named-ports=http:8080 \
    --zone=us-central1-a

Valide a configuração do balanceador de carga de aplicações externo

Neste passo, verifica se o equilibrador de carga externo está configurado corretamente.

Deve conseguir enviar um pedido para o VIP do balanceador de carga e receber uma resposta da VM no local simulada:
```
PUBLIC_VIP=gcloud compute addresses describe external-lb-vip \
    --format="get(address)" \
    --global
```
Envie um pedido curl para o endereço IP externo (PUBLIC_VIP) e verifique se recebe a mensagem Hello world:
```
curl $PUBLIC_VIP
```
Vê o seguinte resultado:
```
Hello world from on-premises!
```

Ative o Cloud Armor

Configure as políticas de segurança do Cloud Armor para permitir apenas o acesso ao seu serviço a partir de CLIENT_IP_RANGE, que deve incluir o endereço IP externo do dispositivo cliente com o qual pretende testar, por exemplo, "192.0.2.0/24".

Estas políticas são aplicadas no serviço de back-end do balanceador de carga externo (neste exemplo, td-hybrid-backend-service aponta para o proxy intermédio). Para mais informações sobre as autorizações necessárias para definir estas regras, consulte o artigo Configure políticas de segurança do Cloud Armor.

Crie a política de segurança do Cloud Armor:

gcloud compute security-policies create external-clients-policy \
    --description="policy for external clients"

Atualize a regra predefinida da política de segurança para recusar todo o tráfego:

gcloud compute security-policies rules update 2147483647 \
    --security-policy=external-clients-policy \
    --action="deny-404"

Adicione uma regra de prioridade mais elevada para permitir tráfego de um intervalo de IPs específico:

gcloud compute security-policies rules create 1000 \
    --security-policy=external-clients-policy \
    --description="allow traffic from CLIENT_IP_RANGE" \
    --src-ip-ranges="CLIENT_IP_RANGE" \
    --action="allow"

Associe as políticas de segurança do Cloud Armor ao seu serviço de back-end:

gcloud compute backend-services update td-middle-proxy-backend-service \
    --security-policy=external-clients-policy

Validação final

Envie um pedido curl para o endereço IP virtual público do Application Load Balancer externo. Se o endereço IP do dispositivo cliente estiver dentro do intervalo permitido CLIENT_IP_RANGE especificado anteriormente, deve receber a resposta esperada.
```
curl $PUBLIC_VIP
```
Vê o seguinte resultado:
```
Hello world from on-premises!
```
Emitir o mesmo pedido curl a partir de um dispositivo cliente diferente cujo endereço IP se encontre fora de CLIENT_IP_RANGE ou atualizar a regra da política de segurança para deixar de incluir o endereço IP do cliente. Agora, deve receber um erro 404 Not Found.

Resolução de problemas

As instruções seguintes descrevem como corrigir problemas com a sua configuração.

O meu serviço no local não está acessível através do endereço IP do Application Load Balancer externo global

Partindo do princípio de que o seu serviço no local já está acessível nas VMs onde os Envoys estão a ser executados, siga estes passos para resolver problemas de configuração:Google Cloud

Certifique-se de que o Google Cloud MIG do Envoy é comunicado como estando em bom estado. Na Google Cloud consola, aceda a Serviços de rede > Equilíbrio de carga e clique em url-map lb-map-http para ver os respetivos detalhes. Deve conseguir ver que 1/1 da instância em td-middle-proxy-us-central1-a está em bom estado.
Se não estiver em bom estado, verifique se foi configurada uma regra de firewall para permitir o tráfego de verificação de estado de entrada para as VMs que estão a executar o Envoy: Google Cloud
```
gcloud compute firewall-rules describe fw-allow-health-check
```
Deverá ver o seguinte resultado:
```
allowed:
‑ IPProtocol: tcp
...
direction: INGRESS
disabled: false
...
...
sourceRanges:
‑ 130.211.0.0/22
‑ 35.191.0.0/16
targetTags:
‑ allow-hc
```

O que se segue?

Para encontrar políticas de encaminhamento mais complexas para os seus serviços no local ou multinuvem, consulte as funcionalidades avançadas de gestão de tráfego do Cloud Service Mesh.
Para implementar a Cloud Service Mesh, consulte a Vista geral do guia de configuração.
Para ativar serviços de limite de rede adicionais, consulte os seguintes guias:
- Ative o IAP para o Compute Engine
- Configure o Cloud CDN com um grupo de instâncias gerido