Questa pagina è stata tradotta dall'API Cloud Translation.

Configurazione del reindirizzamento da HTTP a HTTPS per i bilanciatori del carico HTTP(S) interni

Questo esempio mostra come tutte le richieste alla porta 80 vengono reindirizzate ai rispettivi servizi HTTPS.

Per informazioni su come configurare il reindirizzamento da HTTP a HTTPS per il bilanciamento del carico esterno, consulta Configurazione del reindirizzamento da HTTP a HTTPS per i bilanciatori del carico HTTP(S) esterni.

Per utilizzare i reindirizzamenti da HTTP a HTTPS con un indirizzo IP condiviso, devi creare due bilanciatori del carico, uno per il traffico HTTPS e un altro per il traffico HTTP. Ogni bilanciatore del carico ha regole di forwarding e mappa URL proprie, ma condivide lo stesso indirizzo IP. Per il bilanciatore del carico HTTP, non è necessario configurare un backend perché il frontend reindirizza il traffico al backend del bilanciatore del carico HTTPS.

Questo esempio mostra come reindirizzare tutte le richieste dalla porta 80 alla porta 443.

A livello generale, per reindirizzare il traffico HTTP su HTTPS, è necessario:

Crea un normale bilanciatore del carico HTTPS interno con un indirizzo IP interno condiviso e riservato.
Testa il bilanciatore del carico HTTPS interno per assicurarti che funzioni.
Reindirizza il traffico al bilanciatore del carico HTTPS interno.
A tale scopo, devi aggiungere un bilanciatore del carico HTTP interno parziale con frontend. Il frontend riceve le richieste e le reindirizza al bilanciatore del carico HTTPS interno. Per farlo, utilizza quanto segue:
- Una regola di forwarding con lo stesso indirizzo IP interno riservato utilizzato dal bilanciatore del carico HTTPS (vedi nel passaggio 1)
- Un proxy HTTP di destinazione
- Una mappa degli URL che reindirizza il traffico al bilanciatore del carico HTTPS

Come mostrato nel diagramma seguente, il bilanciatore del carico HTTPS interno è un normale bilanciatore del carico con i componenti del bilanciatore del carico previsti.

Il bilanciatore del carico HTTP ha lo stesso indirizzo IP del bilanciatore del carico HTTPS e un'istruzione di reindirizzamento nella mappa URL.

Configurazione del reindirizzamento da HTTP a HTTPS interno (fai clic per ingrandire) — Configurazione interna del reindirizzamento da HTTP a HTTPS

Creazione del bilanciatore del carico HTTPS interno

La procedura è simile a quella per configurare un bilanciatore del carico HTTP(S) interno.

La configurazione del bilanciamento del carico HTTP(S) interno si compone di due parti:

Eseguire attività preliminari, ad esempio garantire che gli account richiesti dispongano delle autorizzazioni corrette e preparare la rete Virtual Private Cloud (VPC).
Configurazione delle risorse del bilanciatore del carico.

Prima di seguire questa guida, acquisisci familiarità con quanto segue:

Panoramica del bilanciamento del carico HTTP(S) interno, inclusa la sezione Limitazioni
Panoramica delle regole firewall VPC

Autorizzazioni

Per seguire questa guida, devi essere in grado di creare istanze e modificare una rete in un progetto. Devi essere un proprietario o un editor del progetto oppure devi disporre di tutti i seguenti ruoli IAM di Compute Engine.

Attività	Ruolo richiesto
Crea reti, subnet e componenti del bilanciatore del carico	Amministratore di rete
Aggiungi e rimuovi regole firewall	Amministratore sicurezza
Creare istanze	Amministratore istanza

Per ulteriori informazioni, consulta le seguenti guide:

Configurazione della rete e delle subnet

È necessaria una rete VPC con due subnet: una per i backend del bilanciatore del carico e l'altra per i proxy del bilanciatore del carico. Un bilanciatore del carico HTTP(S) interno è a livello di area geografica. Il traffico nella rete VPC è instradato al bilanciatore del carico, se l'origine del traffico si trova in una subnet nella stessa area geografica del bilanciatore del carico.

Questo esempio utilizza le seguenti reti, aree geografiche e subnet VPC:

Rete. La rete è una rete VPC in modalità personalizzata denominata lb-network.
Subnet per i backend. Una subnet denominata backend-subnet nell'area geografica us-west1 utilizza 10.1.2.0/24 come intervallo IP principale.
Subnet per i proxy. Una subnet denominata proxy-only-subnet nell'area geografica us-west1 utilizza 10.129.0.0/23 come intervallo IP principale.

Configurazione della rete e della subnet per i backend

console

Vai alla pagina di rete VPC in Google Cloud Console.
Vai alla pagina Reti VPC
Fai clic su Crea rete VPC.
In Nome, inserisci lb-network.
Nella sezione Subnet:
- Imposta la modalità di creazione subnet su Personalizzata.
- Nella sezione Nuova subnet, inserisci le seguenti informazioni:
  - Nome: backend-subnet
  - Area geografica: us-west1
  - Intervallo di indirizzi IP: 10.1.2.0/24
- Fai clic su Fine.
Fai clic su Crea.

gcloud

Crea la rete VPC personalizzata con il comando gcloud compute networks create:
```
gcloud compute networks create lb-network --subnet-mode=custom
```

Crea una subnet nella rete lb-network nell'area geografica us-west1 con il 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

Fai una richiesta POST al metodo networks.insert, sostituendo PROJECT_ID con l'ID progetto.

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

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

Fai una richiesta POST al metodo subnetworks.insert, sostituendo PROJECT_ID con l'ID progetto.

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",
}

Configurazione della subnet solo proxy

Questa subnet solo proxy è destinata a tutti i bilanciatori del carico HTTP(S) interni nell'area geografica us-west1.

console

Se utilizzi Google Cloud Console, puoi attendere e creare la subnet solo proxy in un secondo momento nella pagina Bilanciamento del carico.

Se vuoi creare subito una subnet solo proxy, segui questi passaggi:

In Google Cloud Console, vai alla pagina Reti VPC.
Vai alla pagina Reti VPC
Fai clic sul nome della rete VPC condivisa: lb-network.
Fai clic su Aggiungi subnet.
In Nome, inserisci proxy-only-subnet.
Come Area geografica, seleziona us-west1.
Imposta Finalità su Proxy gestito a livello di area geografica.
Per Intervallo di indirizzi IP, inserisci 10.129.0.0/23.
Fai clic su Aggiungi.

gcloud

Crea la subnet solo proxy con il comando gcloud compute networks subnets create.

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

API

Crea la subnet solo proxy con il metodo subnetworks.insert, sostituendo PROJECT_ID con l'ID progetto.

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": "REGIONAL_MANAGED_PROXY",
  "role": "ACTIVE"
}

Configurazione delle regole del firewall

In questo esempio vengono utilizzate le seguenti regole firewall:

fw-allow-ssh. Una regola in entrata, applicabile alle istanze in bilanciamento del carico, che consente la connettività SSH in entrata sulla porta TCP 22 da qualsiasi indirizzo. Puoi scegliere un intervallo IP di origine più restrittivo per questa regola; ad esempio, puoi specificare solo gli intervalli IP del sistema da cui avvii le sessioni SSH. In questo esempio viene utilizzato il tag di destinazione allow-ssh.
fw-allow-health-check. Una regola in entrata, applicabile alle istanze in bilanciamento del carico, che consente tutto il traffico TCP dai sistemi di controllo di integrità di Google Cloud (in 130.211.0.0/22 e 35.191.0.0/16). In questo esempio viene utilizzato il tag di destinazione load-balanced-backend.
fw-allow-proxies. Una regola in entrata, applicabile alle istanze in fase di bilanciamento del carico, che consente il traffico TCP sulle porte 80, 443 e 8080 dal proxy del carico HTTP(S) interno. In questo esempio viene utilizzato il tag di destinazione load-balanced-backend.

Senza queste regole firewall, la regola predefinita per il traffico in entrata blocca il traffico in entrata verso le istanze di backend.

I tag di destinazione definiscono le istanze di backend. Senza i tag di destinazione, le regole firewall si applicano a tutte le tue istanze di backend nella rete VPC. Quando crei le VM di backend, assicurati di includere i tag di destinazione specificati, come mostrato nella sezione Creazione di un gruppo di istanze gestite.

console

Vai alla pagina Regole firewall in Google Cloud Console.
Vai alla pagina Regole firewall
Fai clic su Crea regola firewall per creare la regola per consentire le connessioni SSH in entrata:
- Nome: fw-allow-ssh
- Rete: lb-network
- Direzione del traffico: in entrata
- Azione in caso di corrispondenza: Consenti
- Target: tag di destinazione specificati
- Tag di destinazione: allow-ssh
- Filtro di origine: intervalli IPv4
- Intervalli IPv4 di origine: 0.0.0.0/0
- Protocolli e porte:
  - Scegli Protocolli e porte specificati.
  - Seleziona la casella di controllo tcp, quindi inserisci 22 per il numero di porta.
Fai clic su Crea.
Fai clic su Crea regola firewall una seconda volta per creare la regola per consentire i controlli di integrità di Google Cloud:
- Nome: fw-allow-health-check
- Rete: lb-network
- Direzione del traffico: in entrata
- Azione in caso di corrispondenza: Consenti
- Target: tag di destinazione specificati
- Tag di destinazione: load-balanced-backend
- Filtro di origine: intervalli IPv4
- Intervalli IPv4 di origine: 130.211.0.0/22 e 35.191.0.0/16
- Protocolli e porte:
  - Scegli Protocolli e porte specificati.
  - Seleziona la casella di controllo tcp, quindi inserisci 80 per il numero di porta.
    Come best practice, limita questa regola solo ai protocolli e alle porte corrispondenti a quelli utilizzati dal controllo di integrità. Se utilizzi tcp:80 per il protocollo e la porta, Google Cloud può utilizzare HTTP sulla porta 80 per contattare le tue VM, ma non può utilizzare HTTPS sulla porta 443 per contattarli.
Fai clic su Crea.
Fai clic su Crea regola firewall una terza volta per creare la regola e consentire ai server proxy del bilanciatore del carico di connettere i backend:
- Nome: fw-allow-proxies
- Rete: lb-network
- Direzione del traffico: in entrata
- Azione in caso di corrispondenza: Consenti
- Target: tag di destinazione specificati
- Tag di destinazione: load-balanced-backend
- Filtro di origine: intervalli IPv4
- Intervalli IPv4 di origine: 10.129.0.0/23
- Protocolli e porte:
  - Scegli Protocolli e porte specificati.
  - Seleziona la casella di controllo tcp, quindi inserisci 80, 443, 8080 per i numeri di porta.
Fai clic su Crea.

gcloud

Crea la regola firewall fw-allow-ssh per consentire la connettività SSH alle VM con il tag di rete allow-ssh. Se ometti source-ranges, Google Cloud interpreta la regola per indicare qualsiasi origine.
```
gcloud compute firewall-rules create fw-allow-ssh \
    --network=lb-network \
    --action=allow \
    --direction=ingress \
    --target-tags=allow-ssh \
    --rules=tcp:22
```
Crea la regola fw-allow-health-check per consentire i controlli di integrità di Google Cloud. Questo esempio consente a tutto il traffico TCP da probe di controllo di integrità; tuttavia, puoi configurare un insieme di porte più ristretto in base alle tue esigenze.
```
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
```

Crea la regola fw-allow-proxies per consentire ai proxy del bilanciatore del carico HTTP(S) interno di connettersi ai backend. Imposta source-ranges sugli intervalli allocati della subnet solo proxy, ad esempio 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

Crea la regola firewall fw-allow-ssh inviando una richiesta POST al metodo firewalls.insert, sostituendo PROJECT_ID con l'ID progetto.

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"
}

Crea la regola firewall fw-allow-health-check inviando una richiesta POST al metodo firewalls.insert, sostituendo PROJECT_ID con l'ID progetto.

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"
}

Crea la regola firewall fw-allow-proxies per consentire il traffico TCP all'interno della subnet proxy per il metodo firewalls.insert, sostituendo PROJECT_ID con l'ID progetto.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/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"
}

Creazione delle risorse interne per il bilanciatore del carico HTTPS

Questo esempio utilizza un backend di macchina virtuale su Compute Engine in un gruppo di istanze gestite. Puoi invece utilizzare altri tipi di backend supportati.

Creazione di un modello di istanza con un server 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'

Creazione di un gruppo di istanze gestite nella zona

gcloud

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

Creazione di un controllo di integrità HTTP

gcloud

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

Creazione di un servizio di backend

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

Aggiunta di backend al servizio di backend

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

Creazione di una mappa URL

gcloud

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

Creazione di un certificato SSL a livello di area geografica

L'esempio seguente mostra come utilizzare gcloud per creare un certificato SSL autogestito. Per ulteriori informazioni, consulta Utilizzo dei certificati SSL autogestiti e Utilizzo dei certificati SSL gestiti da Google.

gcloud

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

Usare il certificato SSL a livello di area geografica per creare un proxy di destinazione

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

Prenotazione di un indirizzo IP condiviso per le regole di forwarding

gcloud

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

Creazione di una regola di forwarding 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

Test del bilanciatore del carico HTTPS

A questo punto, il bilanciatore del carico (inclusi il servizio di backend, la mappa URL e la regola di forwarding) è pronto. Testa questo bilanciatore del carico per verificare che funzioni come previsto.

Crea un'istanza VM del client per testare la connettività.

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

Connettiti alla VM del client tramite SSH.

gcloud

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

Usa Curl per connetterti al bilanciatore del carico HTTPS.

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

Esempio di output:

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

Invia 100 richieste e verifica che siano tutte bilanciate.

{
  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
}

Esempio di output:

***
*** 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

Reindirizzamento del traffico al bilanciatore del carico HTTPS

Il bilanciatore del carico HTTP ha un indirizzo IP condiviso che reindirizza il traffico dalla porta 80 alla 443.

Creazione di una nuova mappa URL per il reindirizzamento del traffico

Crea un file YAML con la configurazione del reindirizzamento del traffico.

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

Importa il file YAML in una nuova mappa URL.

gcloud

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

Creazione del proxy di destinazione del bilanciatore del carico HTTP

gcloud

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

Creazione di una nuova regola di forwarding e dell'indirizzo IP condiviso

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

Test del reindirizzamento del traffico

Connettiti alla VM del tuo client.

gcloud

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

Invia una richiesta http alla 10.1.2.99 sulla porta 80, aspettati un reindirizzamento del traffico.

curl -L -k 10.1.2.99

Un output di esempio.

Page served from: l7-ilb-backend-w11t

Puoi aggiungere -vvv per visualizzare ulteriori dettagli.

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

Passaggi successivi

Per informazioni sul funzionamento del bilanciamento del carico HTTP(S) interno, consulta Panoramica del bilanciamento del carico HTTP(S) interno.
Per gestire la risorsa di subnet solo proxy richiesta dal bilanciamento del carico HTTP(S) interno, consulta la sezione Subnet solo proxy per i bilanciatori del carico HTTP(S) interni.
Pulisci la configurazione del bilanciatore del carico.