Configurer la redirection HTTP vers HTTPS pour les équilibreurs de charge HTTP(S) internes

Cet exemple montre comment toutes les requêtes vers le port 80 sont redirigées vers leurs services HTTPS respectifs.

Pour apprendre à configurer la redirection HTTP vers HTTPS pour l'équilibrage de charge externe, consultez la page Configurer la redirection HTTP vers HTTPS pour les équilibreurs de charge HTTP(S) externes.

Pour utiliser des redirections HTTP vers HTTPS avec une adresse IP partagée, vous devez créer deux équilibreurs de charge, un pour le trafic HTTPS et un pour le trafic HTTP. Chaque équilibreur de charge possède sa propre règle de transfert et son propre mappage d'URL, mais partage la même adresse IP. Pour l'équilibreur de charge HTTP, il n'est pas nécessaire de configurer un backend, car l'interface redirige le trafic vers le backend de l'équilibreur de charge HTTPS.

Cet exemple montre comment rediriger toutes les requêtes du port 80 vers le port 443.

En règle générale, pour rediriger le trafic HTTP vers HTTPS, vous devez suivre la procédure suivante :

  1. Créez un équilibreur de charge HTTPS interne normal avec une adresse IP interne réservée et partagée.
  2. Testez l'équilibreur de charge HTTPS interne pour vous assurer qu'il fonctionne.
  3. Redirigez le trafic vers l'équilibreur de charge HTTPS interne.
    Pour ce faire, vous devez ajouter un équilibreur de charge HTTP interne partiel contenant une interface, mais aucun backend. L'interface reçoit les requêtes, puis les redirige vers l'équilibreur de charge HTTPS interne. Pour ce faire, elle utilise les éléments suivants :
    • Une règle de transfert avec la même adresse IP interne réservée que celle utilisée par votre équilibreur de charge HTTPS (voir étape 1)
    • Un proxy HTTP cible
    • Un mappage d'URL qui redirige le trafic vers l'équilibreur de charge HTTPS

Comme le montre le schéma suivant, l'équilibreur de charge HTTPS interne est un équilibreur de charge normal avec les composants d'équilibreur de charge attendus.

L'équilibreur de charge HTTP possède la même adresse IP que l'équilibreur de charge HTTPS, une instruction de redirection dans le mappage d'URL et aucun backend.

Configuration de la redirection HTTP vers HTTPS interne (cliquez pour agrandir)
Configuration de la redirection HTTP vers HTTPS interne

Créer l'équilibreur de charge HTTPS interne

Ce processus est identique à la configuration d'un équilibreur de charge HTTP(S) interne.

La configuration de l'équilibrage de charge HTTP(S) interne se compose des deux parties suivantes :

  • Effectuer des tâches préalables, comme s'assurer que les comptes requis disposent des autorisations adéquates et préparer le réseau cloud privé virtuel (VPC)
  • Configurer les ressources de l'équilibreur de charge

Avant de suivre ce guide, familiarisez-vous avec les points suivants :

Autorisations

Pour suivre ce guide, vous devez savoir comment créer des instances et modifier un réseau dans un projet. Vous devez être propriétaire ou éditeur du projet, ou disposer de tous les rôles IAM Compute Engine suivants :

Tâche Rôle requis
Créer des réseaux, des sous-réseaux et des composants de l'équilibreur de charge Administrateur réseau
Ajouter et supprimer des règles de pare-feu Administrateur de sécurité
Créer des instances Administrateur d'instances

Pour en savoir plus, consultez les guides suivants :

Configurer le réseau et les sous-réseaux

Vous avez besoin d'un réseau VPC avec deux sous-réseaux : un pour les backends de l'équilibreur de charge et l'autre pour les proxys de l'équilibreur de charge. Les équilibreurs de charge HTTP(S) internes sont régionaux. Le trafic au sein du réseau VPC est acheminé vers l'équilibreur de charge si la source du trafic se trouve dans un sous-réseau dans la même région que l'équilibreur de charge.

Cet exemple utilise le réseau VPC, la région et les sous-réseaux suivants :

  • Réseau : le réseau est un réseau VPC en mode personnalisé nommé lb-network.

  • Sous-réseau pour les backends : un sous-réseau nommé backend-subnet dans la région us-west1 utilise 10.1.2.0/24 pour sa plage d'adresses IP principale.

  • Sous-réseau pour les proxys : un sous-réseau nommé proxy-only-subnet dans la région us-west1 utilise 10.129.0.0/23 pour sa plage d'adresses IP principale.

Configurer le réseau et le sous-réseau pour les backends

Console

  1. Accédez à la page "Réseaux VPC" dans Google Cloud Console.
    Accéder à la page "Réseaux VPC"
  2. Cliquez sur Créer un réseau VPC.
  3. Dans le champ Nom, saisissez lb-network.
  4. Dans la section Sous-réseaux :
    • Définissez Mode de création du sous-réseau sur Personnalisé.
    • Dans la section Nouveau sous-réseau, saisissez les informations suivantes :
      • Nom : backend-subnet
      • Région : us-west1
      • Plage d'adresses IP : 10.1.2.0/24
    • Cliquez sur OK.
  5. Cliquez sur Créer.

gcloud

  1. Créez le réseau VPC personnalisé à l'aide de la commande gcloud compute networks create :

    gcloud compute networks create lb-network --subnet-mode=custom
    
  2. Créez un sous-réseau dans le réseau lb-network de la région us-west1 à l'aide de la commande 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

Envoyez une requête POST à la méthode networks.insert, en remplaçant PROJECT_ID par votre ID de projet.

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

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

Envoyez une requête POST à la méthode subnetworks.insert, en remplaçant PROJECT_ID par votre ID de projet.

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

Configurer le sous-réseau proxy réservé

Le sous-réseau proxy réservé est destiné à tous les équilibreurs de charge HTTP(S) internes de la région us-west1.

Console

Si vous utilisez Google Cloud Console, vous pouvez créer le sous-réseau proxy réservé ultérieurement sur la page "Équilibrage de charge".

gcloud

Créez le sous-réseau proxy réservé à l'aide de la commande 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

Créez le sous-réseau proxy réservé avec la méthode subnetworks.insert, en remplaçant PROJECT_ID par votre ID de projet.

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

Configurer les règles de pare-feu

Cet exemple utilise les règles de pare-feu suivantes :

  • fw-allow-ssh : règle d'entrée, applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise la connectivité SSH entrante sur le port TCP 22 à partir de n'importe quelle adresse. Vous pouvez choisir une plage d'adresses IP sources plus restrictive pour cette règle. Par exemple, vous pouvez spécifier uniquement les plages d'adresses IP du système à partir duquel vous souhaitez lancer des sessions SSH. Cet exemple utilise le tag cible allow-ssh.

  • fw-allow-health-check : règle d'entrée, applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise tout le trafic TCP issu des systèmes de vérification d'état Google Cloud (dans 130.211.0.0/22 et 35.191.0.0/16). Cet exemple utilise le tag cible load-balanced-backend.

  • fw-allow-proxies : règle d'entrée applicable aux instances faisant l'objet d'un équilibrage de charge, qui autorise le trafic TCP sur les ports 80, 443 et 8080 à partir des proxys gérés de l'équilibreur de charge HTTP(S) interne. Cet exemple utilise le tag cible load-balanced-backend.

Sans ces règles de pare-feu, la règle d'entrée interdite par défaut bloque le trafic entrant vers les instances backend.

Les tags cibles définissent les instances backend. Sans les tags cibles, les règles de pare-feu s'appliquent à toutes les instances backend du réseau VPC. Lorsque vous créez les VM de backend, veillez à inclure les tags cibles spécifiés, comme décrit dans la section Créer un groupe d'instances géré.

Console

  1. Accédez à la page "Règles de pare-feu" de Google Cloud Console.
    Accéder à la page "Règles de pare-feu"
  2. Cliquez de nouveau sur Créer une règle de pare-feu pour créer la règle autorisant les connexions SSH entrantes :
    • Nom : fw-allow-ssh
    • Réseau : lb-network
    • Sens du trafic : entrée
    • Action en cas de correspondance : autoriser
    • Cibles : Tags cibles spécifiés
    • Tags cibles : allow-ssh
    • Filtre source : Plages d'adresses IP
    • Plages d'adresses IP sources : 0.0.0.0/0
    • Protocoles et ports :
      • Choisissez Protocoles et ports spécifiés.
      • Cochez la case tcp, puis saisissez 22 pour le numéro de port.
  3. Cliquez sur Créer.
  4. Cliquez une deuxième fois sur Créer une règle de pare-feu pour créer la règle autorisant les vérifications d'état Google Cloud :
    • Nom : fw-allow-health-check
    • Réseau : lb-network
    • Sens du trafic : entrée
    • Action en cas de correspondance : autoriser
    • Cibles : Tags cibles spécifiés
    • Tags cibles : load-balanced-backend
    • Filtre source : Plages d'adresses IP
    • Plages d'adresses IP sources : 130.211.0.0/22 et 35.191.0.0/16
    • Protocoles et ports :
      • Choisissez Protocoles et ports spécifiés.
      • Cochez la case tcp, puis saisissez 80 pour le numéro de port.
        Nous vous recommandons de limiter cette règle aux seuls protocoles et ports qui correspondent à ceux utilisés par votre vérification de l'état. Si vous utilisez tcp:80 pour le protocole et le port, Google Cloud peut contacter vos VM via HTTP sur le port 80, mais pas via HTTPS sur le port 443.
  5. Cliquez sur Créer.
  6. Cliquez une troisième fois sur Créer une règle de pare-feu pour créer la règle autorisant les serveurs proxy de l'équilibreur de charge à se connecter aux backends :
    • Nom : fw-allow-proxies
    • Réseau : lb-network
    • Sens du trafic : entrée
    • Action en cas de correspondance : autoriser
    • Cibles : Tags cibles spécifiés
    • Tags cibles : load-balanced-backend
    • Filtre source : Plages d'adresses IP
    • Plages d'adresses IP sources : 10.129.0.0/23
    • Protocoles et ports :
      • Choisissez Protocoles et ports spécifiés.
      • Cochez la case tcp, puis saisissez 80, 443, 8080 pour les numéros de port.
  7. Cliquez sur Créer.

gcloud

  1. Créez la règle de pare-feu fw-allow-ssh pour autoriser la connectivité SSH aux VM avec le tag réseau allow-ssh. Lorsque vous omettez source-ranges, Google Cloud interprète la règle comme désignant n'importe quelle source.

    gcloud compute firewall-rules create fw-allow-ssh \
        --network=lb-network \
        --action=allow \
        --direction=ingress \
        --target-tags=allow-ssh \
        --rules=tcp:22
    
  2. Créez la règle fw-allow-health-check pour autoriser les vérifications d'état Google Cloud. Cet exemple autorise tout le trafic TCP provenant des tests de vérification d'état. Toutefois, vous pouvez configurer un ensemble de ports plus restreint en fonction de vos besoins.

    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. Créez la règle fw-allow-proxies pour autoriser les proxys de l'équilibreur de charge HTTP(S) interne à se connecter à vos backends. Définissez source-ranges sur les plages allouées de votre sous-réseau proxy réservé, par exemple 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

Créez la règle de pare-feu fw-allow-ssh en envoyant une requête POST à la méthode firewalls.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

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

Créez la règle de pare-feu fw-allow-health-check en envoyant une requête POST à la méthode firewalls.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

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

Créez la règle de pare-feu fw-allow-proxies pour autoriser le trafic TCP dans le sous-réseau proxy pour la méthode firewalls.insert, en remplaçant PROJECT_ID par l'ID de votre projet.

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

Créer les ressources de l'équilibreur de charge HTTPS interne

Cet exemple utilise des backends de machine virtuelle sur Compute Engine dans un groupe d'instances géré. Vous pouvez également utiliser d'autres types de backends compatibles.

Créer un modèle d'instance avec un serveur 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'

Créer un groupe d'instances géré dans la zone

gcloud

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

Créer une vérification d'état HTTP

gcloud

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

Créer un service de 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

Ajouter des backends au service de 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

Créer un mappage d'URL

gcloud

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

Créer un certificat SSL régional

L'exemple suivant montre comment utiliser gcloud pour créer un certificat SSL autogéré. Pour en savoir plus, consultez les pages Utiliser des certificats SSL autogérés et Utiliser des certificats SSL gérés par Google.

gcloud

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

Utiliser le certificat SSL régional pour créer un proxy cible

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

Réserver une adresse IP partagée pour les règles de transfert

gcloud

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

Créer une règle de transfert 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

Tester l'équilibreur de charge HTTPS

À ce stade, l'équilibreur de charge (y compris le service de backend, le mappage d'URL et la règle de transfert) est prêt. Testez cet équilibreur de charge pour vérifier qu'il fonctionne comme prévu.

Créer une instance de VM cliente pour tester la connectivité.

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

Connectez-vous à la VM cliente via SSH.

gcloud

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

Connectez-vous à l'équilibreur de charge HTTPS à l'aide de Curl.

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

Exemple de résultat :

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

Envoyez 100 requêtes et vérifiez qu'elles font toutes l'objet d'un équilibrage de charge.

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

Exemple de résultat :

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

Rediriger le trafic vers l'équilibreur de charge HTTPS

L'équilibreur de charge HTTP possède une adresse IP partagée qui redirige le trafic du port 80 vers le port 443.

Créer un mappage d'URL pour rediriger le trafic

Créez un fichier YAML avec la configuration de redirection du trafic.

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

Importez le fichier YAML dans un nouveau mappage d'URL.

gcloud

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

Créer le proxy cible de l'équilibreur de charge 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

Créer une règle de transfert et l'adresse IP partagée

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

Testez la redirection du trafic

Connectez-vous à la VM cliente.

gcloud

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

Envoyez une requête HTTP à 10.1.2.99 sur le port 80. Attendez-vous à une redirection de trafic.

curl -L -k 10.1.2.99

Exemple de résultat :

Page served from: l7-ilb-backend-w11t

Vous pouvez ajouter -vvv pour afficher plus de détails.

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

Étape suivante