Présentation de l'équilibrage de charge proxy SSL

L'équilibrage de charge proxy SSL est un équilibreur de charge de proxy inverse qui répartit le trafic SSL provenant d'Internet vers les instances de machines virtuelles (VM) de votre réseau VPC Google Cloud.

Lorsque vous utilisez l'équilibrage de charge proxy SSL pour votre trafic SSL, les connexions SSL (TLS) utilisateur sont interrompues au niveau de la couche d'équilibrage de charge, puis transmises par proxy aux instances backend disponibles les plus proches à l'aide du protocole SSL (recommandé) ou TCP. Pour connaître les types de backends compatibles, consultez la section Backends.

Au niveau Premium, l'équilibrage de charge proxy SSL peut être configuré en tant que service global d'équilibrage de charge. Au niveau Standard, l'équilibreur de charge proxy SSL gère l'équilibrage de charge à l'échelle régionale. Pour en savoir plus, consultez la section Comportement de l'équilibreur de charge dans les niveaux de service réseau.

Dans cet exemple, le trafic des utilisateurs de l'Iowa et de Boston est interrompu au niveau de la couche d'équilibrage de charge et une connexion distincte est établie avec le backend sélectionné.

Cloud Load Balancing avec terminaison SSL (cliquez pour agrandir)
Cloud Load Balancing avec terminaison SSL (cliquez pour agrandir)

L'équilibrage de charge proxy SSL est destiné au trafic autre que HTTP(S). Pour le trafic HTTP(S), nous vous recommandons plutôt d'utiliser l'équilibrage de charge HTTP(S).

Pour en savoir plus sur les différences entre les équilibreurs de charge Google Cloud, consultez les documents suivants :

Avantages

Voici quelques avantages de l'utilisation de l'équilibrage de charge proxy SSL :

  • Terminaison IPv6 L'équilibrage de charge proxy SSL accepte le trafic client provenant d'adresses IPv4 et d'adresses IPv6. Les requêtes client IPv6 sont interrompues au niveau de la couche d'équilibrage de charge, puis transmises par proxy, via IPv4, à vos VM.

  • Routage intelligent. L'équilibreur de charge peut acheminer les requêtes vers les emplacements de backend disposant d'une capacité suffisante. En revanche, un équilibreur de charge L3/L4 ne peut acheminer les requêtes que vers des backends régionaux, sans tenir compte de leur capacité. L'utilisation d'un routage plus intelligent permet de provisionner à N+1 ou N+2 au lieu de x*N.

  • Meilleure utilisation des backends. Le traitement SSL peut être très gourmand en ressources processeur si les algorithmes de chiffrements utilisés ne sont pas optimisés. Pour optimiser les performances des processeurs, utilisez des certificats ECDSA SSL et TLS 1.2, et privilégiez l'utilisation de la suite de chiffrement ECDHE-ECDSA-AES128-GCM-SHA256 pour les connexions SSL entre l'équilibreur de charge et vos instances backend.

  • Gestion des certificats. Les certificats SSL que vous fournissez aux clients peuvent être soit des certificats que vous allez acquérir et gérer vous-même (certificats autogérés), soit des certificats que Google récupère et gère pour votre compte (certificats gérés par Google). Les certificats SSL gérés par Google acceptent jusqu'à 100 domaines. Les domaines gérés par Google sont compatibles avec plusieurs domaines. Il vous suffit de provisionner des certificats au niveau de l'équilibreur de charge. Sur les VM, vous pouvez simplifier la gestion en utilisant des certificats autosignés.

  • Correctifs de sécurité. En cas de failles dans la pile SSL ou TCP, nous appliquons automatiquement des correctifs à l'équilibreur de charge afin de préserver la sécurité de vos VM.

  • Compatibilité avec les ports connus suivants : 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671 , 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200 et 9300. Lorsque vous utilisez des certificats SSL gérés par Google avec l'équilibrage de charge proxy SSL, utilisez le port 443 en tant que port frontal pour le trafic afin de permettre le provisionnement et le renouvellement des certificats SSL gérés par Google.

  • Règles SSL. Les règles SSL vous permettent de contrôler les fonctionnalités SSL que votre équilibreur de charge proxy SSL négocie avec les clients.

  • Contrôle géographique des emplacements où le protocole TLS est interrompu L'équilibreur de charge proxy SSL interrompt le protocole TLS dans les emplacements distribués à l'échelle mondiale, de manière à réduire la latence entre les clients et l'équilibreur de charge. Si vous avez besoin d'exercer un contrôle géographique sur ces emplacements, vous devez plutôt faire appel à l'équilibrage de charge au niveau du réseau, et interrompre le protocole TLS sur les backends situés dans les régions correspondant à vos besoins.

Comportement de l'équilibreur de charge dans les niveaux de service réseau

L'équilibrage de charge proxy TCP peut être configuré en tant que service global d'équilibrage de charge au niveau Premium et en tant que service régional au niveau standard.

Niveau Premium

Vous ne pouvez disposer que d'un seul service de backend, lequel peut comporter des backends dans plusieurs régions. Pour l'équilibrage de charge global, vous déployez vos backends dans plusieurs régions, et l'équilibreur de charge dirige automatiquement le trafic vers la région la plus proche de l'utilisateur. Si une région est saturée, l'équilibreur de charge redirige automatiquement les nouvelles connexions vers une autre région disposant d'une capacité suffisante. En pareil cas, les connexions utilisateur existantes restent dans la région actuelle.

Le trafic est alloué aux backends de la manière suivante :

  1. Lorsqu'un client envoie une requête, le service d'équilibrage de charge détermine l'origine approximative de la requête à partir de l'adresse IP source.
  2. Le service d'équilibrage de charge connaît les emplacements des backends détenus par le service de backend, leur capacité globale et leur utilisation actuelle globale.
  3. Si les instances backend les plus proches de l'utilisateur disposent d'une capacité suffisante, la requête est transmise à l'ensemble de backends le plus proche.
  4. Les requêtes envoyées vers une région donnée sont réparties de manière équitable entre l'ensemble des instances backend de cette région. Toutefois, pour des charges très faibles, la répartition peut sembler non équitable.
  5. Si aucune instance backend opérationnelle d'une région donnée ne dispose d'une capacité suffisante, l'équilibreur de charge envoie la requête à la région la plus proche avec de la capacité disponible.

Niveau Standard

Avec le niveau Standard, l'équilibrage de charge proxy TCP est un service régional. Ses backends doivent tous être situés dans la région utilisée par l'adresse IP externe et la règle de transfert de l'équilibreur de charge.

Architecture

Les éléments présentés ci-dessous sont les composants des équilibreurs de charge proxy TCP.

Règles de transfert et adresses IP

Les règles de transfert permettent d'acheminer le trafic par adresse IP, port et protocole vers une configuration d'équilibrage de charge comprenant un proxy cible et un service de backend.

Chaque règle de transfert fournit une adresse IP unique que vous pouvez utiliser dans les enregistrements DNS de votre application. Aucun équilibrage de charge DNS n'est requis. Vous pouvez soit réserver une adresse IP statique qui sera utilisée par le service, soit laisser Cloud Load Balancing en attribuer une pour votre compte. Nous vous recommandons de réserver une adresse IP statique. Si vous ne le faites pas, vous devez mettre à jour votre enregistrement DNS avec l'adresse IP éphémère nouvellement attribuée chaque fois que vous supprimez une règle de transfert ou que vous en créez une.

Proxy cibles

L'équilibrage de charge proxy SSL met fin aux connexions SSL du client et crée des connexions vers les backends. Le proxy cible achemine les requêtes entrantes directement vers le service de backend.

Par défaut, l'adresse IP et les informations de port d'origine du client ne sont pas conservées. Vous pouvez conserver ces informations à l'aide du protocole de PROXY.

Certificats SSL

Vous devez installer un ou plusieurs certificats SSL sur le proxy SSL cible.

Ces certificats sont utilisés par les proxys SSL cibles pour sécuriser les communications entre un système GFE (Google Front End) et le client. Il peut s'agir de certificats SSL autogérés ou gérés par Google.

Pour en savoir plus sur les limites et les quotas des certificats SSL, consultez la section Certificats SSL sur la page des quotas d'équilibrage de charge.

Pour une sécurité optimale, utilisez le chiffrement de bout en bout pour votre déploiement d'équilibrage de charge proxy SSL. Pour en savoir plus, consultez la section Chiffrement entre l'équilibreur de charge et les backends.

Pour plus d'informations sur la façon dont Google chiffre le trafic des utilisateurs, consultez le livre blanc Chiffrement en transit sur Google Cloud.

Services de backend

Les services de backend dirigent le trafic entrant vers un ou plusieurs backends associés. Chaque backend est composé d'un groupe d'instances ou d'un groupe de points de terminaison du réseau, ainsi que d'informations sur la capacité de diffusion du backend. La capacité de diffusion du backend peut être basée sur l'utilisation du processeur ou sur le nombre de requêtes par seconde (RPS).

Chaque service de backend spécifie les vérifications d'état à effectuer pour les backends disponibles.

Vous pouvez activer le drainage de connexion sur les services de backend afin de garantir à vos utilisateurs un temps d'interruption minimal. De telles interruptions peuvent se produire lorsqu'un backend est arrêté, supprimé manuellement ou supprimé par un autoscaler. Pour en savoir plus sur la manière dont vous pouvez utiliser le drainage de connexion pour minimiser les interruptions de service, consultez la page Activer le drainage de connexion.

Règles de pare-feu

Les instances backend doivent autoriser les connexions à partir des plages GFE ou de vérification d'état de l'équilibreur de charge. Cela signifie que vous devez créer une règle de pare-feu qui permet au trafic de 130.211.0.0/22 et 35.191.0.0/16 d'atteindre vos instances ou points de terminaison principaux. Ces plages d'adresses IP sont utilisées comme sources pour les paquets de vérification de l'état et pour tous les paquets à charge équilibrée envoyés à vos backends.

Les ports que vous configurez pour cette règle de pare-feu doivent autoriser l'acheminement du trafic vers des instances ou des points de terminaison :

  • Vous devez autoriser les ports utilisés par chaque règle de transfert.
  • Vous devez autoriser les ports utilisés par chaque vérification d'état configurée pour chaque service de backend.

Les règles de pare-feu sont mises en œuvre au niveau de l'instance de VM, et non sur les proxys Google Front End (GFE). Vous ne pouvez pas utiliser les règles de pare-feu Google Cloud pour empêcher le trafic d'atteindre l'équilibreur de charge.

Pour plus d'informations sur les vérifications de l'état et découvrir pourquoi il est nécessaire d'autoriser le trafic en provenance de 130.211.0.0/22 et de 35.191.0.0/16, consultez la section Plages d'adresses IP de vérification et règles de pare-feu.

Adresses IP sources

Les adresses IP sources des paquets, telles qu'elles sont perçues par chaque instance de machine virtuelle (VM) ou conteneur backend, proviennent des plages suivantes :

  • 35.191.0.0/16
  • 130.211.0.0/22

L'adresse IP source du trafic réel à équilibrage de charge est identique à celle des plages d'adresses IP des vérifications d'état.

Les adresses IP sources du trafic, telles qu'elles sont perçues par les backends, sont différentes de l'adresse IP externe Google Cloud de l'équilibreur de charge. En d'autres termes, il existe deux sessions HTTP, SSL ou TCP :

  • Session 1, du client d'origine vers l'équilibreur de charge (GFE) :

    • Adresse IP source : le client d'origine (ou l'adresse IP externe si le client est protégé par la fonctionnalité NAT).
    • Adresse IP de destination : l'adresse IP de votre équilibreur de charge.
  • Session 2, de l'équilibreur de charge (GFE) vers la VM de backend ou le conteneur :

    • Adresse IP source : une adresse IP située dans l'une de ces plages : 35.191.0.0/16 ou 130.211.0.0/22.

      Vous ne pouvez pas prédire l'adresse source réelle.

    • Adresse IP de destination : une adresse IP interne de la VM de backend ou du conteneur dans le réseau cloud privé virtuel (VPC).

Conserver les adresses IP sources du client

Pour conserver les adresses IP sources d'origine des connexions entrantes à l'équilibreur de charge, vous pouvez configurer ce dernier de façon à ajouter un préfixe d'en-tête de protocole PROXY version 1 afin de conserver les informations de connexion d'origine. Pour en savoir plus, consultez la section Mettre à jour l'en-tête du protocole de proxy pour le proxy.

Ports ouverts

Les équilibreurs de charge proxy SSL sont des équilibreurs de charge de type "proxy inverse". L'équilibreur de charge interrompt les connexions entrantes, puis ouvre de nouvelles connexions entre lui-même et les backends. La fonctionnalité de proxy inverse est fournie par Google Front End (GFE).

Les règles de pare-feu que vous définissez bloquent le trafic entre les GFE et les instances backend, mais elles ne bloquent pas le trafic entrant vers les GFE.

Les équilibreurs de charge proxy SSL offrent un certain nombre de ports ouverts pour les autres services Google exécutés sur la même architecture. Si vous effectuez une analyse de sécurité ou de port sur l'adresse IP externe de votre équilibreur de charge, vous allez constater que des ports supplémentaires semblent être ouverts.

Cela n'affecte en rien les équilibreurs de charge proxy SSL. Les règles de transfert externes utilisées dans la définition d'un équilibreur de charge SSL ne peuvent faire référence qu'aux ports TCP 25, 43, 110, 143, 195, 443, 465, 587, 700, 993, 995, 1883, 3389, 5222, 5432, 5671, 5672, 5900, 5901, 6379, 8085, 8099, 9092, 9200 et 9300. Le trafic associé aux autres ports de destination TCP n'est pas transféré vers le backend de l'équilibreur de charge.

Distribution du trafic

La façon dont un équilibreur de charge proxy TCP distribue le trafic vers ses backends dépend du mode d'équilibrage et de la méthode de hachage sélectionnée pour choisir un backend (affinité de session).

Mode d'équilibrage

Lorsque vous ajoutez un backend au service de backend, vous définissez un mode d'équilibrage de charge.

Pour l'équilibrage de charge proxy SSL, le mode d'équilibrage peut être CONNECTION ou UTILIZATION.

Si le mode d'équilibrage de charge est CONNECTION, la charge est répartie en fonction du nombre de connexions simultanées que le backend peut gérer. Vous devez également spécifier l'un des paramètres suivants : maxConnections (sauf pour les groupes d'instances gérés régionaux), maxConnectionsPerInstance ou maxConnectionsPerEndpoint.

Si le mode d'équilibrage de charge est UTILIZATION, la charge est répartie en fonction de l'utilisation des instances dans un groupe d'instances.

Pour en savoir plus sur les différents types d'équilibreurs de charge et les modes d'équilibrage acceptés, consultez la section Méthodes d'équilibrage de charge.

Affinité de session

L'affinité de session permet d'envoyer toutes les requêtes d'un même client au même backend, sous réserve que le backend soit opérationnel et dispose d'une capacité suffisante.

L'équilibrage de charge proxy TCP offre une fonctionnalité d'affinité basée sur les adresses IP client, qui permet de transmettre toutes les requêtes provenant d'une même adresse IP client au même backend.

Basculement

Si un backend n'est plus opérationnel, le trafic est automatiquement redirigé vers des backends opérationnels dans la même région. Si aucun des backends d'une région n'est opérationnel, le trafic est distribué aux backends opérationnels d'autres régions (niveau Premium uniquement). Si aucun des backends n'est opérationnel, l'équilibreur de charge abandonne le trafic.

Remarques et limites concernant l'utilisation

  • En envoyant le trafic via une connexion TCP non chiffrée entre la couche d'équilibrage de charge et vos instances backend, vous pouvez délester vos backends des opérations de traitement SSL. Cette opération affaiblit toutefois la sécurité. C'est pourquoi nous ne vous recommandons pas de procéder ainsi.

  • Vous pouvez créer des règles SSL à l'aide de l'outil de ligne de commande gcloud.

  • Les équilibreurs de charge proxy SSL possèdent chacun une seule ressource de service de backend. Les modifications apportées au service de backend ne sont pas instantanées. La propagation des modifications sur Google Front End (GFE) peut prendre plusieurs minutes.

  • Les équilibreurs de charge proxy SSL n'acceptent pas l'authentification basée sur un certificat client, également appelée authentification TLS mutuelle.

  • Bien que l'équilibrage de charge proxy SSL puisse gérer le trafic HTTPS, nous ne le recommandons pas. Utilisez plutôt l'équilibrage de charge HTTP(S) pour le trafic HTTPS. L'équilibrage de charge HTTP(S) effectue également les opérations suivantes, ce qui en fait un meilleur choix dans la plupart des cas :

    • Négociation HTTP/2 et SPDY/3.1
    • Rejet des requêtes ou réponses HTTP non valides
    • Transfert des requêtes à différentes VM en fonction du nom d'hôte/chemin d'URL
    • Intégration avec Cloud CDN
    • Répartition plus homogène de la charge des requêtes entre les instances backend, ce qui optimise l'utilisation des backends. HTTPS équilibre la charge de chaque requête de manière individuelle, tandis que l'équilibrage de charge proxy SSL envoie tous les octets de la même connexion SSL ou TCP à la même instance backend.
  • Pour les équilibreurs de charge proxy SSL avec des certificats SSL gérés par Google, les ports d'interface doivent inclure 443 pour que les certificats soient provisionnés et renouvelés

    L'équilibrage de charge proxy SSL peut être utilisé pour d'autres protocoles exploitant SSL, tels que WebSockets et IMAP over SSL.

Étape suivante