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

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

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 Configurare il 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 la propria regola di forwarding e la propria mappa URL, 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 a HTTPS, devi fare quanto segue:

  1. Creare un normale bilanciatore del carico HTTPS interno con un indirizzo IP interno condiviso e riservato.
  2. Testa il bilanciatore del carico HTTPS interno per verificare che funzioni.
  3. Reindirizza il traffico al bilanciatore del carico HTTPS interno.
    Per farlo, devi aggiungere un bilanciatore del carico HTTP interno parziale dotato di frontend. Il frontend riceve le richieste, quindi le reindirizza al bilanciatore del carico HTTPS interno. A questo scopo, utilizza quanto segue:
    • Una regola di forwarding con lo stesso indirizzo IP interno riservato utilizzata dal bilanciatore del carico HTTPS (vedi nel passaggio 1)
    • Un proxy HTTP di destinazione
    • Una mappa 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 interna del reindirizzamento da HTTP a HTTPS (fai clic per ingrandire)
Configurazione di reindirizzamento da HTTP a HTTPS interno

Creazione del bilanciatore del carico HTTPS interno

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

La configurazione del bilanciamento del carico HTTP(S) interno è composta da due parti:

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

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

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 rete Compute
Aggiungere e rimuovere regole firewall Amministratore sicurezza Compute
Creazione delle istanze Amministratore istanze Compute

Per saperne di più, consulta le seguenti guide:

Configura la rete e le 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 regione. Il traffico all'interno della rete VPC viene instradato al bilanciatore del carico se la sorgente del traffico si trova in una subnet nella stessa area geografica del bilanciatore del carico.

Questo esempio utilizza la rete, l'area geografica e le subnet VPC seguenti:

  • Rete. La rete è una rete VPC in modalità personalizzata denominata lb-network.

  • Subnet per i backend. Una subnet denominata backend-subnet nella regione us-west1 utilizza 10.1.2.0/24 per l'intervallo IP principale.

  • Subnet per i proxy. Una subnet denominata proxy-only-subnet nella regione us-west1 utilizza 10.129.0.0/23 per l'intervallo IP principale.

Per dimostrare l'accesso globale, in questo esempio viene creata anche una seconda VM client di test in un'area geografica e una subnet diverse:

  • Regione: europe-west1
  • Subnet: europe-subnet, con intervallo di indirizzi IP principali 10.3.4.0/24

Configura la rete e le subnet

Console

  1. In Google Cloud Console, vai alla pagina Reti VPC.

    Vai a Reti VPC

  2. Fai clic su Crea rete VPC.

  3. In Nome, inserisci lb-network.

  4. Nella sezione Subnet, imposta la modalità di creazione delle subnet su Personalizzata.

  5. Crea una subnet per i backend del bilanciatore del carico. Nella sezione Nuova subnet, inserisci le seguenti informazioni:

    • Nome: backend-subnet
    • Regione: us-west1
    • Intervallo di indirizzi IP: 10.1.2.0/24

  6. Fai clic su Fine.

  7. Fai clic su Aggiungi subnet.

  8. Crea una subnet per dimostrare l'accesso globale. Nella sezione Nuova subnet, inserisci le seguenti informazioni:

    • Nome: europe-subnet
    • Regione: europe-west1
    • Intervallo di indirizzi IP: 10.3.4.0/24

  9. Fai clic su Fine.

  10. Fai clic su Crea.

gcloud

  1. Crea la rete VPC personalizzata con il comando gcloud compute networks create:

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

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

  3. Crea una subnet nella rete lb-network nell'area geografica europe-west1 con il comando gcloud compute networks subnets create:

    gcloud compute networks subnets create europe-subnet \
    --network=lb-network \
    --range=10.3.4.0/24 \
    --region=europe-west1

API

Invia una richiesta POST al metodo networks.insert. Sostituisci 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
}

Invia una richiesta POST al metodo subnetworks.insert. Sostituisci 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",
}

Invia una richiesta POST al metodo subnetworks.insert. Sostituisci PROJECT_ID con l'ID progetto.

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

{
 "name": "europe-subnet",
 "network": "projects/PROJECT_ID/global/networks/lb-network",
 "ipCidrRange": "10.3.4.0/24",
 "region": "projects/PROJECT_ID/regions/europe-west1",
}

Configura la subnet solo proxy

Questa subnet solo proxy è per tutti i bilanciatori del carico basati su Envoy a livello di area geografica nell'area geografica us-west1 di lb-network.

Console

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

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

  1. In Google Cloud Console, vai alla pagina Reti VPC.

    Vai a Reti VPC

  2. Fai clic sul nome della rete VPC lb-network.

  3. Fai clic su Aggiungi subnet.

  4. In Nome, inserisci proxy-only-subnet.

  5. In Regione, seleziona us-west1.

  6. Imposta Finalità su Proxy gestito a livello di area geografica.

  7. In Intervallo di indirizzi IP, inserisci 10.129.0.0/23.

  8. Fai clic su Add (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 il tuo 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 per identificare le VM a cui si applica la regola firewall.

  • fw-allow-health-check. Una regola in entrata, applicabile alle istanze in fase di bilanciamento del carico, che consente l'utilizzo di tutto il traffico TCP proveniente 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 per identificare le VM a cui si applica la regola firewall.

  • 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 dai proxy gestiti del bilanciatore del carico HTTP(S) interno. In questo esempio viene utilizzato il tag di destinazione load-balanced-backend per identificare le VM a cui si applica la regola firewall.

Senza queste regole firewall, la regola default nega 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 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

  1. In Google Cloud Console, vai alla pagina Regole firewall.

    Vai a Regole firewall

  2. 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 della porta.

  3. Fai clic su Crea.

  4. 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 della porta.
        Come best practice, limita questa regola solo ai protocolli e alle porte che corrispondono 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.

  5. Fai clic su Crea.

  6. Fai clic su Crea regola firewall una terza volta per creare la regola per 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 della porta.

  7. Fai clic su Crea.

gcloud

  1. Crea la regola firewall fw-allow-ssh per consentire la connettività SSH alle VM con tag di rete allow-ssh. Quando ometti source-ranges, Google Cloud interpreta la regola in modo da 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

  2. Crea la regola fw-allow-health-check per consentire i controlli di integrità di Google Cloud. Questo esempio consente tutto il traffico TCP da probe di controllo di integrità; tuttavia, puoi configurare un insieme di porte più ristrette per soddisfare le 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

  3. Crea la regola fw-allow-proxies per consentire ai proxy del bilanciatore del carico HTTP(S) interno di connettersi ai tuoi 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 effettuando una richiesta POST al metodo firewalls.insert, sostituendo PROJECT_ID con il tuo 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 effettuando una richiesta POST al metodo firewalls.insert, sostituendo PROJECT_ID con il tuo 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 del bilanciatore del carico HTTPS

In questo esempio viene utilizzato un backend per macchine virtuali su Compute Engine in un gruppo di istanze gestite. In alternativa, puoi 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-10 \
    --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 in corso...

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

Creare 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 regione

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

Utilizzo del certificato SSL a livello di regione 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.

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

gcloud 

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

Connettiti alla VM 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.

Creare 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 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 che venga reindirizzato il 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