Como configurar o redirecionamento de HTTP para HTTPS para balanceadores de carga HTTP(S) internos

Este exemplo mostra como todas as solicitações para a porta 80 são redirecionadas para os respectivos serviços HTTPS.

Para saber como configurar o redirecionamento HTTP-HTTPS para balanceamento de carga externo, consulte Como configurar o redirecionamento HTTP para HTTPS em balanceadores de carga HTTP(S) externos.

Para usar redirecionamentos HTTP-HTTPS com um endereço IP compartilhado, crie dois balanceadores de carga, um para o tráfego HTTPS e outro para o tráfego HTTP. Cada balanceador de carga tem sua própria regra de encaminhamento e mapa de URL, mas compartilha o mesmo endereço IP. Para o balanceador de carga HTTP, não é necessário configurar um back-end porque o front-end redireciona o tráfego para o back-end do balanceador de carga HTTPS.

Neste exemplo, você verá como redirecionar todas as solicitações da porta 80 para a porta 443.

Em geral, para redirecionar o tráfego HTTP para HTTPS, é preciso seguir as etapas a seguir:

  1. Crie um balanceador de carga HTTPS interno normal com um endereço IP interno compartilhado reservado.
  2. Teste o balanceador de carga HTTPS interno para verificar se ele está funcionando.
  3. Redirecionar o tráfego para o balanceador de carga HTTPS interno.
    Para fazer isso, você precisa adicionar um balanceador de carga HTTP interno parcial que tenha um front-end, mas não back-ends. O front-end recebe solicitações e as redireciona para o balanceador de carga HTTPS interno. Ele faz isso da seguinte forma:
    • Uma regra de encaminhamento com o mesmo endereço IP interno reservado usado pelo balanceador de carga HTTPS (mencionado na etapa 1)
    • Um proxy HTTP de destino.
    • Um mapa de URL que redireciona o tráfego para o balanceador de carga HTTPS.

Conforme mostrado no diagrama a seguir, o balanceador de carga HTTPS interno é um balanceador de carga normal com os componentes do balanceador de carga esperados.

O balanceador de carga HTTP tem o mesmo endereço IP que o HTTPS, uma instrução de redirecionamento no mapa de URL e nenhum back-end.

Configuração de redirecionamento interno de HTTP para HTTPS (clique para ampliar)
Configuração de redirecionamento HTTP para HTTPS interno

Como criar o balanceador de carga HTTPS interno

Esse processo é semelhante à configuração de um balanceador de carga HTTP(S) interno.

A configuração do balanceamento de carga HTTP(S) interno tem duas partes:

  • Realizar tarefas de pré-requisito, como garantir que as contas necessárias tenham as permissões corretas e preparar a rede de nuvem privada virtual (VPC).
  • Configurar os recursos do balanceador de carga.

Antes de seguir as instruções deste guia, familiarize-se com os itens abaixo:

Permissões

Para seguir as instruções deste guia, você precisa ser capaz de criar instâncias e modificar uma rede em um projeto. É necessário ser um proprietário ou editor de projeto, ou ter todos os seguintes papéis do IAM do Compute Engine:

Tarefa Papel necessário
Criar redes, sub-redes e componentes do balanceador de carga Administrador de rede
Adicionar e remover regras de firewall Administrador de segurança
Criar instâncias Administrador de instâncias

Para mais informações, consulte estes guias:

Como configurar a rede e as sub-redes

Você precisa de uma rede VPC com duas sub-redes: uma para os back-ends do balanceador de carga e a outra para os proxies do balanceador de carga. Um balanceador de carga HTTP(S) interno é regional. O tráfego na rede VPC será direcionado ao balanceador de carga se a origem do tráfego estiver em uma sub-rede na mesma região que o balanceador de carga.

Neste exemplo, usamos a seguinte rede VPC, região e sub-redes:

  • Rede: uma rede VPC de modo personalizado chamada lb-network.

  • Sub-rede para back-ends: uma sub-rede chamada backend-subnet na região us-west1 usa 10.1.2.0/24 como o intervalo de IP primário.

  • Sub-rede para proxies: uma sub-rede chamada proxy-only-subnet na região us-west1 usa 10.129.0.0/23 como o intervalo de IP primário.

Como configurar a rede e a sub-rede para back-ends

Console

  1. Acesse a página da rede VPC no Console do Google Cloud.
    Acessar a página "Redes VPC"
  2. Clique em Criar rede VPC.
  3. Em Nome, insira lb-network.
  4. Na seção Sub-redes:
    • Defina o Modo de criação de sub-rede como Personalizado.
    • Na seção Nova sub-rede, insira as informações a seguir:
      • Nome: backend-subnet
      • Região: us-west1
      • Intervalo de endereços IP: 10.1.2.0/24
    • Clique em Concluído.
  5. Clique em Criar.

gcloud

  1. Crie a rede VPC personalizada com o comando gcloud compute networks create:

    gcloud compute networks create lb-network --subnet-mode=custom

  2. Crie uma sub-rede na rede lb-network na região us-west1 com o comando gcloud compute networks subnets create:

    gcloud compute networks subnets create backend-subnet \
    --network=lb-network \
    --range=10.1.2.0/24 \
    --region=us-west1

API

Faça uma solicitação POST para o método networks.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/networks

{
  "routingConfig": {
    "routingMode": "REGIONAL"
  },
  "name": "lb-network",
  "autoCreateSubnetworks": false
}

Faça uma solicitação POST para o método subnetworks.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "backend-subnet",
  "network": "projects/project-id/global/networks/lb-network",
  "ipCidrRange": "10.1.2.0/24",
  "region": "projects/project-id/regions/us-west1",
}

Como configurar a sub-rede somente prox

A sub-rede somente proxy é para todos os balanceadores de carga HTTP(S) internos da região us-west1.

Console

Se você estiver usando o Console do Google Cloud, poderá esperar e criar a sub-rede somente proxy depois na página "Balanceamento de carga".

gcloud

Crie a sub-rede somente proxy com o comando gcloud compute networks subnets create.

gcloud compute networks subnets create proxy-only-subnet \
  --purpose=INTERNAL_HTTPS_LOAD_BALANCER \
  --role=ACTIVE \
  --region=us-west1 \
  --network=lb-network \
  --range=10.129.0.0/23

API

Crie a sub-rede somente proxy com o método subnetworks.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/projects/PROJECT_ID/regions/us-west1/subnetworks

{
  "name": "proxy-only-subnet",
  "ipCidrRange": "10.129.0.0/23",
  "network": "projects/project-id/global/networks/lb-network",
  "region": "projects/project-id/regions/us-west1",
  "purpose": "INTERNAL_HTTPS_LOAD_BALANCER",
  "role": "ACTIVE"
}

Como configurar regras de firewall

Este exemplo usa as seguintes regras de firewall:

  • fw-allow-ssh: uma regra de entrada, aplicável às instâncias cuja carga está sendo balanceada, que permite a conectividade SSH de entrada na porta TCP 22 proveniente de qualquer endereço. Escolha um intervalo de IP de origem mais restritivo para esta regra. Por exemplo, é possível especificar apenas os intervalos de IP do sistema do qual você inicia sessões SSH. Neste exemplo, usamos a tag de destino allow-ssh.

  • fw-allow-health-check: uma regra de entrada, aplicável às instâncias submetidas ao balanceamento de carga, que permite todo o tráfego TCP dos sistemas de verificação de integridade do Google Cloud (em 130.211.0.0/22 e 35.191.0.0/16). Este exemplo usa a tag de destino load-balanced-backend.

  • fw-allow-proxies: uma regra de entrada, aplicável às instâncias cuja carga está sendo balanceada, que permite o tráfego TCP nas portas 80, 443 e 8080 proveniente do proxies gerenciados pelo balanceador de carga HTTP(S) interno. Neste exemplo, usamos a tag de destino load-balanced-backend.

Sem essas regras de firewall, a regra padrão de negação de entrada bloqueará o tráfego que chega para as instâncias de back-end.

As tags de destino definem as instâncias de back-end. Sem as tags de destino, as regras de firewall se aplicam a todas as instâncias de back-end na rede VPC. Ao criar as VMs de back-end, inclua as tags de destino especificadas, conforme mostrado em Como criar um grupo gerenciado de instâncias.

Console

  1. Acesse a página "Regras de firewall" no Console do Google Cloud.
    Acessar a página "Regras de firewall"
  2. Clique em Criar regra de firewall novamente para criar uma regra que autorize conexões SSH de entrada:
    • Nome: fw-allow-ssh
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação na correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: allow-ssh
    • Filtro de origem: IP ranges
    • Intervalos de IP de origem: 0.0.0.0/0
    • Protocolos e portas:
      • Escolha Protocolos e portas especificados.
      • Marque a caixa de seleção tcp e insira 22 como o número da porta.
  3. Clique em Criar.
  4. Clique em Criar regra de firewall pela segunda vez para criar uma regra que autorize as verificações de integridade do Google Cloud:
    • Nome: fw-allow-health-check
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação na correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: load-balanced-backend
    • Filtro de origem: IP ranges
    • Intervalos de IP de origem: 130.211.0.0/22 e 35.191.0.0/16
    • Protocolos e portas:
      • Escolha Protocolos e portas especificados.
      • Marque a caixa de seleção tcp e insira 80 como o número da porta.
        Como prática recomendada, limite esta regra somente aos protocolos e portas que correspondem aos usados por sua verificação de integridade. Se você usar tcp:80 para o protocolo e a porta, o Google Cloud poderá usar HTTP na porta 80 para entrar em contato com suas VMs, mas não poderá usar HTTPS na porta 443 para entrar em contato com elas.
  5. Clique em Criar.
  6. Clique em Criar regra de firewall uma terceira vez para criar a regra que permite que os servidores proxy do balanceador de carga se conectem aos back-ends:
    • Nome: fw-allow-proxies
    • Rede: lb-network
    • Direção do tráfego: entrada
    • Ação na correspondência: permitir
    • Destinos: tags de destino especificadas
    • Tags de meta: load-balanced-backend
    • Filtro de origem: IP ranges
    • Intervalos de IP de origem: 10.129.0.0/23
    • Protocolos e portas:
      • Escolha Protocolos e portas especificados.
      • Marque a caixa de seleção tcp e insira 80, 443, 8080 como os números da porta.
  7. Clique em Criar.

gcloud

  1. Crie a regra de firewall fw-allow-ssh que permita a conectividade SSH para VMs com a tag de rede allow-ssh. Se você omitir source-ranges, o Google Cloud interpretará que a regra autoriza a conexão proveniente de qualquer origem.

    gcloud compute firewall-rules create fw-allow-ssh \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22

  2. Crie a regra fw-allow-health-check para permitir verificações de integridade do Google Cloud. Neste exemplo, é permitido todo o tráfego TCP de sondagens de verificação de integridade. No entanto, é possível configurar um conjunto mais restrito de portas para atender às suas necessidades.

    gcloud compute firewall-rules create fw-allow-health-check \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --source-ranges=130.211.0.0/22,35.191.0.0/16 \
    --target-tags=load-balanced-backend \
    --rules=tcp

  3. Crie a regra fw-allow-proxies para permitir que os proxies do balanceador de carga HTTP(S) interno se conectem aos back-ends. Defina source-ranges para os intervalos alocados da sub-rede somente proxy, por exemplo, 10.129.0.0/23.

    gcloud compute firewall-rules create fw-allow-proxies \
  --network=lb-network \
  --action=allow \
  --direction=ingress \
  --source-ranges=source-range \
  --target-tags=load-balanced-backend \
  --rules=tcp:80,tcp:443,tcp:8080

API

Crie a regra de firewall fw-allow-ssh fazendo uma solicitação POST ao método firewalls.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-ssh",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "0.0.0.0/0"
  ],
  "targetTags": [
    "allow-ssh"
  ],
  "allowed": [
   {
     "IPProtocol": "tcp",
     "ports": [
       "22"
     ]
   }
  ],
 "direction": "INGRESS"
}

Crie a regra de firewall fw-allow-health-check fazendo uma solicitação POST ao método firewalls.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/global/firewalls

{
  "name": "fw-allow-health-check",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "130.211.0.0/22",
    "35.191.0.0/16"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp"
    }
  ],
  "direction": "INGRESS"
}

Crie a regra de firewall fw-allow-proxies para permitir o tráfego TCP na sub-rede proxy para o método firewalls.insert, substituindo PROJECT_ID pelo ID do projeto.

POST https://compute.googleapis.com/compute/v1/projects/{project}/global/firewalls

{
  "name": "fw-allow-proxies",
  "network": "projects/project-id/global/networks/lb-network",
  "sourceRanges": [
    "10.129.0.0/23"
  ],
  "targetTags": [
    "load-balanced-backend"
  ],
  "allowed": [
    {
      "IPProtocol": "tcp",
      "ports": [
        "80"
      ]
    },
  {
      "IPProtocol": "tcp",
      "ports": [
        "443"
      ]
    },
    {
      "IPProtocol": "tcp",
      "ports": [
        "8080"
      ]
    }
  ],
  "direction": "INGRESS"
}

Como criar os recursos do balanceador de carga HTTPS interno

Este exemplo usa back-ends de máquina virtual no Compute Engine em um grupo gerenciado de instâncias. Use outros tipos de back-end compatíveis.

Como criar um modelo de instância com um servidor HTTP

gcloud

gcloud compute instance-templates create l7-ilb-backend-template \
    --region=us-west1 \
    --network=lb-network \
    --subnet=backend-subnet \
    --tags=allow-ssh,load-balanced-backend \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --metadata=startup-script='#! /bin/bash
    apt-get update
    apt-get install apache2 -y
    a2ensite default-ssl
    a2enmod ssl
    vm_hostname="$(curl -H "Metadata-Flavor:Google" \
    http://169.254.169.254/computeMetadata/v1/instance/name)"
    echo "Page served from: $vm_hostname" | \
    tee /var/www/html/index.html
    systemctl restart apache2'

Como criar um grupo gerenciado de instâncias na zona

gcloud

gcloud compute instance-groups managed create l7-ilb-backend \
    --zone=us-west1-a \
    --size=2 \
    --template=l7-ilb-backend-template

Como criar uma verificação de integridade HTTP

gcloud

gcloud compute health-checks create http l7-ilb-basic-check \
     --region=us-west1 \
     --use-serving-port

Como criar um serviço de back-end

gcloud

gcloud compute backend-services create l7-ilb-backend-service \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --protocol=HTTP \
    --health-checks=l7-ilb-basic-check \
    --health-checks-region=us-west1 \
    --region=us-west1

Como adicionar back-ends ao serviço de back-end

gcloud

gcloud compute backend-services add-backend l7-ilb-backend-service \
    --balancing-mode=UTILIZATION \
    --instance-group=l7-ilb-backend \
    --instance-group-zone=us-west1-a \
    --region=us-west1

Criar um mapa de URLs

gcloud

gcloud compute url-maps create l7-ilb-service-url-map \
    --default-service=l7-ilb-backend-service \
    --region=us-west1

Como criar um certificado SSL regional

O exemplo a seguir mostra como usar gcloud para criar um certificado SSL autogerenciado. Para mais informações, consulte Como usar certificados SSL autogerenciados e Como usar certificados SSL gerenciados pelo Google.

gcloud

gcloud compute ssl-certificates create CERTIFICATE_NAME \
    --certificate=CERTIFICATE_FILE \
    --private-key=PRIVATE_KEY_FILE \
    --region=us-west1

Como usar o certificado SSL regional para criar um proxy de destino

gcloud

gcloud compute target-https-proxies create l7-ilb-https-proxy \
    --url-map=l7-ilb-service-url-map \
    --region=us-west1 \
    --ssl-certificates=l7-ilb-cert

Como reservar um endereço IP compartilhado para as regras de encaminhamento

gcloud

gcloud beta compute addresses create \
    --addresses=10.1.2.99 \
    --region=us-west1 \
    --subnet=backend-subnet \
    --purpose=SHARED_LOADBALANCER_VIP

Como criar uma regra de encaminhamento HTTPS

gcloud

gcloud compute forwarding-rules create l7-ilb-https-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=10.1.2.99 \
    --ports=443 \
    --region=us-west1 \
    --target-https-proxy=l7-ilb-https-proxy \
    --target-https-proxy-region=us-west1

Como testar o balanceador de carga HTTPS

Nesse momento, o balanceador de carga, incluindo o serviço de back-end, o mapa de URL e a regra de encaminhamento, está pronto. Teste este balanceador de carga para verificar se ele está funcionando como esperado.

Crie uma instância de VM do cliente para testar a conectividade.

gcloud

gcloud compute instances create l7-ilb-client-us-west1-a \
    --image-family=debian-9 \
    --image-project=debian-cloud \
    --network=lb-network \
    --subnet=backend-subnet \
    --zone=us-west1-a \
    --tags=allow-ssh

Conecte-se à VM do cliente via SSH.

gcloud

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

Use o Curl para se conectar ao balanceador de carga HTTPS.

curl -k -s 'https://10.1.2.99:443' --connect-to 10.1.2.99:443

Exemplo de saída:

Page served from: l7-ilb-backend-850t

Envie 100 solicitações e verifique se todas elas estão com balanceamento de carga.

{
  RESULTS=
  for i in {1..100}
  do
      RESULTS="$RESULTS:$(curl -k -s 'https://test.example.com:443' --connect-to test.example.com:443:10.1.2.99:443)"
  done
  echo "***"
  echo "*** Results of load-balancing to 10.1.2.99: "
  echo "***"
  echo "$RESULTS" | tr ':' '\n' | grep -Ev "^$" | sort | uniq -c
  echo
}

Exemplo de saída:

***
*** Results of load-balancing to 10.1.2.99:
***
     51  l7-ilb-backend-https-850t
     49  l7-ilb-backend-https-w11t
    100 Page served from

Como redirecionar o tráfego para o balanceador de carga HTTPS

O balanceador de carga HTTP tem um endereço IP compartilhado que redireciona o tráfego da porta 80 para a 443.

Como criar um novo mapa de URL para redirecionar o tráfego

Crie um arquivo YAML com a configuração de redirecionamento de tráfego.

echo "defaultService: regions/us-west1/backendServices/l7-ilb-backend-service
kind: compute#urlMap
name: l7-ilb-redirect-url-map
hostRules:
- hosts:
  - '*'
  pathMatcher: matcher1
pathMatchers:
- name: matcher1
  defaultUrlRedirect:
        hostRedirect: 10.1.2.99:443
        pathRedirect: /
        redirectResponseCode: PERMANENT_REDIRECT
        httpsRedirect: True
        stripQuery: True" > /tmp/url_map.yaml

Importe o arquivo YAML para um novo mapa de URL.

gcloud

gcloud compute url-maps import l7-ilb-redirect-url-map \
    --source /tmp/url_map.yaml \
    --region us-west1

Como criar o proxy de destino do balanceador de carga HTTP

gcloud

gcloud compute target-http-proxies create l7-ilb-http-proxy \
    --url-map=l7-ilb-redirect-url-map \
    --url-map-region=us-west1 \
    --region=us-west1

Como criar uma nova regra de encaminhamento e o endereço IP compartilhado

gcloud

gcloud compute forwarding-rules create l7-ilb-forwarding-rule \
    --load-balancing-scheme=INTERNAL_MANAGED \
    --network=lb-network \
    --subnet=backend-subnet \
    --address=10.1.2.99 \
    --ports=80 \
    --region=us-west1 \
    --target-http-proxy=l7-ilb-http-proxy \
    --target-http-proxy-region=us-west1

Como testar o redirecionamento de tráfego

Conecte-se à VM do cliente.

gcloud

gcloud compute ssh l7-ilb-client-us-west1-a \
    --zone=us-west1-a

Envie uma solicitação HTTP para 10.1.2.99 na porta 80. Haverá um redirecionamento de tráfego.

curl -L -k 10.1.2.99

Um exemplo de saída.

Page served from: l7-ilb-backend-w11t

Você pode adicionar -vvv para ver mais detalhes.

curl -L -k 10.1.2.99 -vvv

* Rebuilt URL to: 10.1.2.99/
*   Trying 10.1.2.99...
* TCP_NODELAY set
* Connected to 10.1.2.99 (10.1.2.99) port 80 (#0)
> GET / HTTP/1.1
> Host: 10.1.2.99
> User-Agent: curl/7.52.1
> Accept: */*
>
< HTTP/1.1 308 Permanent Redirect
< location: https://10.1.2.99:443/
< date: Fri, 07 Aug 2020 05:07:18 GMT
< via: 1.1 google
< content-length: 0
<
* Curl_http_done: called premature == 0
* Connection #0 to host 10.1.2.99 left intact
* Issue another request to this URL: 'https://10.1.2.99:443/'
*   Trying 10.1.2.99...
* TCP_NODELAY set
* Connected to 10.1.2.99 (10.1.2.99) port 443 (#1)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: /etc/ssl/certs
...
...
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
*  subject: O=Google TESTING; CN=test_cert_1
*  start date: Jan  1 00:00:00 2015 GMT
*  expire date: Jan  1 00:00:00 2025 GMT
*  issuer: O=Google TESTING; CN=Intermediate CA
*  SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
* 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 0x561a6b0e3ea0)
> GET / HTTP/1.1
> Host: 10.1.2.99
> User-Agent: curl/7.52.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
< date: Fri, 07 Aug 2020 05:07:18 GMT
< server: Apache/2.4.25 (Debian)
< last-modified: Thu, 06 Aug 2020 13:30:21 GMT
< etag: "2c-5ac357d7a47ec"
< accept-ranges: bytes
< content-length: 44
< content-type: text/html
< via: 1.1 google
<
Page served from: l7-ilb-backend-https-w11t
* Curl_http_done: called premature == 0
* Connection #1 to host 10.1.2.99 left intact

A seguir