Configurar serviços de borda de rede para implantações híbridas

O Google oferece vários serviços de borda de rede que podem aumentar os recursos e a segurança dos serviços com base fora do Google Cloud (serviços locais e de várias nuvens), por exemplo, em um data center no local. ou em outra nuvem pública.

Esses serviços de borda de rede permitem que você faça o seguinte:

Aceitar e rotear o tráfego de clientes externos no mundo todo com um único VIP do Anycast.
Reduzir a carga do servidor encerrando o tráfego TLS Edge com um balanceador de carga de aplicativo externo e certificados SSL gerenciados pelo Google.
Ative as regras pré-configuradas do firewall de aplicativos da Web (WAF) e aplique listas de permissões e de proibições ao tráfego de entrada com o Google Cloud Armor.
Controlar o acesso dos usuários aos seus aplicativos e recursos com o Identity-Aware Proxy (IAP)
Otimize a entrega de conteúdo e a latência do usuário final com o Cloud CDN.

Exemplo de serviços de borda de rede. — Exemplo de serviços Edge de rede (clique para ampliar)

Para levar esses benefícios aos seus serviços particulares, locais ou em várias nuvens, implante um balanceador de carga de aplicativo externo para receber tráfego da Internet pública. O balanceador de carga de aplicativo externo encaminha o tráfego para um proxy intermediário configurado pelo Traffic Director. Esse proxy intermediário direciona o tráfego para seu ambiente local ou que não seja do Google Cloud usando Cloud VPN ou Cloud Interconnect.

Neste tutorial, orientamos você em um exemplo completo que usa o Google Cloud Armor na extremidade do Google para permitir seletivamente que os clientes acessem um serviço local de modo privado. Os clientes têm o acesso permitido com base no endereço IP deles.

Conclua as seguintes tarefas:

Implantar o Envoy como um proxy intermediário em um grupo de instâncias gerenciadas (MIG). Esse proxy Envoy será conectado automaticamente ao Traffic Director.
Crie uma instância de máquina virtual (VM) particular, simulada no local. Em um exemplo real, você provavelmente já tem uma VM no local.
Configure o Traffic Director para rotear todas as solicitações que chegam ao proxy intermediário para a VM simulada no local
Crie um balanceador de carga de aplicativo externo para receber tráfego da Internet pública e encaminhá-lo ao proxy intermediário.
Anexe uma política de segurança do Google Cloud Armor ao balanceador de carga de aplicativo externo.

Depois de concluir essas tarefas, você tem a opção de explorar outros serviços Edge e recursos avançados de gerenciamento de tráfego.

Pré-requisitos

Antes de configurar o proxy intermediário, conclua as seguintes tarefas:

Leia Prepare-se para configurar o Traffic Director com o Envoy e conclua todas as tarefas de pré-requisito que incluem a concessão das permissões e dos papéis necessários e a ativação da API Traffic Director.
Garanta que os endpoints particulares locais possam ser acessados na rede da nuvem privada virtual (VPC) do Google Cloud por meio do Cloud VPN ou Cloud Interconnect. O exemplo usado neste tutorial apenas encaminha o tráfego para um endpoint no Google Cloud. Portanto, não é necessário configurar a conectividade híbrida para acompanhar. Em um cenário de implantação real, a configuração da conectividade híbrida seria necessária.
Verifique se os intervalos de CIDR de sub-rede VPC não entram em conflito com os intervalos de CIDR remoto. Quando os endereços IP se sobrepõem, as rotas de sub-rede são priorizadas em relação à conectividade remota.
Para esta demonstração, consiga as permissões necessárias para criar e atualizar as políticas de segurança do Google Cloud Armor. As permissões podem variar se você quiser usar um serviço diferente, como o Cloud CDN.

Implantar o proxy do meio em VMs do Compute Engine

Nesta seção, descrevemos como implantar o Envoy como um proxy intermediário no Compute Engine para receber tráfego do balanceador de carga externo e encaminhá-lo para seu destino remoto.

Criar o modelo de instância para o proxy do meio

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

Use o modelo a seguir para criar instâncias de VM com um proxy Envoy conectado ao Traffic Director:

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

Para personalizar a implantação do Envoy, como ao especificar o nome da rede, definir um caminho de registro e/ou ativar o rastreamento, consulte o Guia de opção de implantação automatizada do Envoy.

Criar o MIG para o proxy do meio

Crie o MIG com base no modelo. Neste exemplo, é possível manter o tamanho do grupo de instâncias de 1 para implantar uma única instância. Para uso em produção, ative o escalonamento automático, por exemplo, com base na utilização da CPU. Isso evita a criação de um gargalo se o proxy intermediário precisar lidar com 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 verificações 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 MIG que contém instâncias de VM que executam o Envoy em us-central1-a. Mais adiante neste tutorial, você criará um balanceador de carga externo para lidar com o tráfego público de Internet dos seus clientes.

Como o balanceador de carga externo pode rotear automaticamente o tráfego para a região mais próxima de seus clientes e para o MIG dentro dessa região, considere criar vários MIGs. Para uma lista completa das regiões e zonas disponíveis do Google Cloud, consulte Regiões e zonas.

Implante o serviço local simulado

Nesta seção, descrevemos a implantação de um grupo de endpoints de rede (NEG, na sigla em inglês) de conectividade híbrida. Em uma implantação de produção, esse NEG conteria um endpoint (IP:port) resolvido para o servidor local. Neste exemplo, você cria uma VM do Compute Engine que pode ser acessada em uma IP:port. Essa VM atua como seu servidor local simulado.

Crie a VM no local simulada

Implantar uma única instância de VM para simular um servidor local particular:

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'

Identifique e armazene o endereço IP interno para futuras configurações e verificações. O servidor nesta VM detecta solicitações 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")

Criar o NEG

Crie o NEG para essa configuração de demonstração especificando o tipo de endpoint de rede non-gcp-private-ip-port. Adicione o endereço IP e a porta da sua VM simulada no local como um endpoint para esse NEG. Após a etapa 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 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"

Configurar o Traffic Director com componentes do Cloud Load Balancing

Nesta seção, mostramos como configurar o Traffic Director e permitir que seu proxy intermediário encaminhe o tráfego para seu serviço privado local. Você configura os seguintes componentes:

Uma verificação de integridade Essa verificação de integridade se comporta de maneira um pouco diferente das verificações de integridade configuradas para outros tipos de NEG.
Um serviço de back-end Para mais informações, consulte a Visão geral dos serviços de back-end.
Um mapa de regras de roteamento Isso inclui a criação de uma regra de encaminhamento, um proxy de destino e um mapa de URL. Para saber mais, consulte Como mapear mapas de regras.

Criar a verificação de integridade

As verificações de integridade verificam se os endpoints estão íntegros e podem receber solicitações. A verificação de integridade para esse tipo de NEG depende do mecanismo de verificação de integridade distribuída do Envoy.

Outros tipos de NEG usam o sistema de verificação de integridade centralizado do 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 ser usado com o Traffic Director. Ao criar esse serviço de back-end, especifique a verificação de integridade recém-criada.
```
gcloud compute backend-services create td-on-prem-backend-service \
    --global \
    --load-balancing-scheme=INTERNAL_SELF_MANAGED \
    --health-checks=td-on-prem-health-check
```

Em seguida, adicione o NEG criado anteriormente como o back-end desse 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

Criar o mapa de regras de roteamento

O mapa de regras de roteamento define como o Traffic Director encaminha o tráfego para o serviço de back-end.

Crie um mapa de URLs que use o serviço de back-end definido acima.

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

Crie um arquivo chamado target_proxy.yaml com o conteúdo a seguir.

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 o Traffic Director:
```
gcloud compute target-http-proxies import td-hybrid-proxy \
    --source=target_proxy.yaml
```
Crie uma regra de encaminhamento que faça referência a esse proxy HTTP de destino. Defina o endereço IP da regra de encaminhamento como 0.0.0.0. Definir o endereço IP da regra como 0.0.0.0 direciona o tráfego com base na porta de entrada, no nome do host HTTP e nas informações do caminho configuradas no mapa de URL. O endereço IP especificado na solicitação 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
```

Verificar se o proxy do meio pode encaminhar solicitações para o serviço local simulado

O Traffic Director agora está configurado para rotear o tráfego por meio do proxy intermediário para o serviço particular local simulado. É possível verificar essa configuração criando uma VM de cliente de teste, fazendo login nela e enviando uma solicitação ao proxy intermediário que está executando o Envoy. Depois de verificar a configuração, exclua a VM do cliente de teste.

Primeiro, consiga o endereço IP do proxy do meio. Você só precisa dessas informações para a etapa de verificação:
```
gcloud compute instances list
```
Anote ou anote de outra maneira o endereço IP da instância no MIG td-middle-proxy-us-central1-a.

Crie uma instância de cliente de teste:

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

Use ssh para fazer login no cliente de teste:

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

Envie uma solicitação à VM de proxy de meio, substituindo o endereço IP que você recebeu anteriormente para MIDDLE_PROXY_IP:
```
curl $MIDDLE_PROXY_IP:8080
```
Você verá esta resposta:
```
Hello world from on-premises!
```

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

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

Implantar o balanceador de carga de aplicativo externo

Nesta seção, você implantará um balanceador de carga de aplicativo externo que envia tráfego de entrada para o proxy intermediário. Essa implantação é uma configuração de balanceador de carga de aplicativo externo padrão.

Reservar 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. Você recupera esse endereço IP externo durante a etapa de verificação mais adiante neste tutorial.

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

Configurar o balanceador de carga HTTP externo

Configurar o balanceador de carga externo para rotear o tráfego de clientes da Internet para seu proxy intermediário já configurado.

Crie uma verificação de integridade usada para determinar se o MIG que executa o proxy do meio é íntegro e capaz de receber tráfego:
```
gcloud compute health-checks create tcp tcp-basic-check \
    --port=8080
```

Crie uma regra de firewall para permitir verificações de integridade. Reutilize a tag allow-hc aqui para aplicar a regra de firewall às VMs de proxy do meio:

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 de proxy intermediário 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 uma mapa de URL para encaminhar as solicitações recebidas para o proxy intermediário como o serviço de back-end padrão:
```
gcloud compute url-maps create lb-map-http \
    --default-service=td-middle-proxy-backend-service
```
Crie um proxy HTTP de destino para que as solicitações feitas ao endereço IP virtual (VIP) da regra de encaminhamento do balanceador de carga externo sejam processadas de acordo com o mapa de URL:
```
gcloud compute target-http-proxies create http-lb-proxy \
    --url-map=lb-map-http
```

Crie uma regra de encaminhamento global para encaminhar as solicitações recebidas 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

Definir a porta nomeada do MIG

Defina uma porta nomeada para o grupo de instâncias a fim de permitir que o proxy intermediário 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

Verificar a configuração do balanceador de carga de aplicativo externo

Nesta etapa, verifique se o balanceador de carga externo está configurado corretamente.

Será possível enviar uma solicitação para o VIP do balanceador de carga e receber uma resposta da VM simulada no local:
```
PUBLIC_VIP=gcloud compute addresses describe external-lb-vip \
    --format="get(address)" \
    --global
```
Emita uma solicitação curl para o endereço IP público e verifique se você recebe a mensagem Hello world:
```
curl $PUBLIC_VIP
```
A saída a seguir será exibida:
```
Hello world from on-premises!
```

Ativar o Google Cloud Armor

Configure as políticas de segurança do Google Cloud Armor para permitir acesso apenas ao seu serviço do CLIENT_IP_RANGE, que precisa incluir o endereço IP público do dispositivo cliente com o qual você pretende testar, por exemplo, "192.0.2.0/24".

Essas políticas são aplicadas no serviço de back-end do balanceador de carga externo (neste exemplo, td-hybrid-backend-service apontando para o proxy intermediário). Saiba mais sobre as permissões necessárias para definir essas regras em Configurar políticas de segurança do Google Cloud Armor.

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

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

Atualize a regra padrão da política de segurança para negar 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 alta para permitir o tráfego de um intervalo de IP 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"

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

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

Verificação final

Emita uma solicitação curl para o endereço IP virtual público do balanceador de carga de aplicativo externo. Se o endereço IP do dispositivo cliente estiver dentro do CLIENT_IP_RANGE especificado anteriormente, você receberá a resposta esperada.
```
curl $PUBLIC_VIP
```
A saída a seguir será exibida:
```
Hello world from on-premises!
```
Emita a mesma solicitação curl de um dispositivo cliente diferente cujo endereço IP esteja fora de CLIENT_IP_RANGE ou atualizar sua regra de política de segurança para não incluir mais o endereço IP do cliente. Agora você receberá um erro 404 Not Found.

Solução de problemas

Meu serviço local não pode ser acessado pelo endereço IP externo global do balanceador de carga de aplicativo

Se o serviço local já estiver acessível nas VMs do Google Cloud que executam o Envoy, siga estas etapas para resolver os problemas na configuração:

Verifique se o MIG do Google Cloud Envoy é informado como íntegro. No Console do Google Cloud, acesse Serviços de rede > Balanceamento de carga e clique em url-map lb-map-http para visualizar os detalhes. Você verá 1/1 da instância em td-middle-proxy-us-central1-a.
Se não estiver íntegra, verifique se uma regra de firewall foi configurada para permitir o tráfego de verificação de integridade de entrada nas VMs do Google Cloud que estão executando o Envoy:
```
gcloud compute firewall-rules describe fw-allow-health-check
```
Você verá esta resposta:
```
allowed:
‑ IPProtocol: tcp
...
direction: INGRESS
disabled: false
...
...
sourceRanges:
‑ 130.211.0.0/22
‑ 35.191.0.0/16
targetTags:
‑ allow-hc
```

A seguir

Para encontrar políticas de roteamento mais complexas para serviços locais ou com várias nuvens, consulte os recursos avançados de gerenciamento de tráfego do Traffic Director..
Para implantar o Traffic Director, consulte a visão geral do guia de configuração.
Para ativar outros serviços de borda de rede, consulte os seguintes guias:
- Ativar o IAP para o Compute Engine
- Como configurar o Cloud CDN com um grupo de instâncias gerenciadas