Équilibrage de charge HTTP(S) interne et réseaux connectés

Cette page décrit les scénarios d'accès à un équilibreur de charge interne sur votre réseau cloud privé virtuel (VPC) à partir d'un réseau connecté. Avant de consulter les informations de cette page, vous devez déjà connaître les concepts présentés dans le guide suivant :

Utiliser l'appairage de réseaux VPC

Lorsque vous utilisez l'appairage de réseaux VPC pour connecter votre réseau VPC à un autre réseau, Google Cloud partage les routes de sous-réseau entre les réseaux. Les routes de sous-réseau permettent au trafic provenant du réseau de pairs d'atteindre les équilibreurs de charge internes sur votre réseau. L'accès est autorisé si les conditions suivantes sont remplies :

  • Pour les équilibreurs de charge TCP/UDP internes, vous devez créer des règles de pare-feu d'entrée pour autoriser le trafic provenant des VM clientes du réseau appairé. Les règles de pare-feu Google Cloud ne sont pas partagées entre les réseaux lorsque vous utilisez l'appairage de réseaux VPC.
  • Les instances de machines virtuelles (VM) clientes du réseau de pairs sont situées dans la même région que votre équilibreur de charge interne, sauf si vous configurez l'accès mondial (uniquement pour l'équilibreur de charge TCP/UDP interne). Lorsque l'accès mondial est configuré, les instances de VM clientes de n'importe quelle région du réseau VPC appairé peuvent accéder à votre équilibreur de charge TCP/UDP interne. L'accès mondial n'est pas compatible avec l'équilibrage de charge HTTP(S) interne.

Il est impossible de ne partager que certains équilibreurs de charge TCP/UDP internes ou équilibreurs de charge HTTP(S) internes à l'aide de l'appairage de réseaux VPC. Tous les équilibreurs de charge internes sont partagés automatiquement. Vous pouvez limiter l'accès aux backends de l'équilibreur de charge de plusieurs manières :

  • Pour les équilibreurs de charge TCP/UDP internes, vous pouvez utiliser les règles de pare-feu applicables aux instances de VM de backend.

  • Pour les équilibreurs de charge HTTP(S) internes, vous pouvez configurer les VM ou points de terminaison de backend pour contrôler l'accès à l'aide d'en-têtes HTTP (par exemple, X-Forwarded-For).

Utiliser Cloud VPN et Cloud Interconnect

Vous pouvez accéder à un équilibreur de charge interne à partir d'un réseau de pairs connecté via un tunnel Cloud VPN ou un rattachement d'interconnexion (VLAN) pour une interconnexion dédiée ou une interconnexion partenaire. Le réseau de pairs peut être un réseau sur site, un autre réseau VPC Google Cloud ou un réseau virtuel hébergé par un autre fournisseur cloud.

Accès via les tunnels Cloud VPN

Vous pouvez accéder à un équilibreur de charge interne via un tunnel Cloud VPN lorsque toutes les conditions ci-dessous sont remplies.

Dans le réseau de l'équilibreur de charge interne

  • La passerelle et le tunnel Cloud VPN sont tous deux situés dans la même région que les composants de l'équilibreur de charge interne, sauf si vous configurez l'accès mondial (uniquement pour l'équilibreur de charge TCP/UDP interne).

  • Les routes fournissent des chemins d'accès permettant de renvoyer le trafic sortant au réseau appairé (client). Si vous vous servez de tunnels Cloud VPN avec routage dynamique, envisagez d'utiliser le mode de routage dynamique du réseau Cloud VPN de l'équilibreur de charge. Le mode de routage dynamique détermine les routes dynamiques personnalisées disponibles pour les backends.

  • Pour l'équilibreur de charge TCP/UDP interne, vous avez configuré des règles de pare-feu afin que les clients sur site puissent communiquer avec les VM de backend de l'équilibreur de charge.

Dans le réseau appairé

Le réseau de pairs doit comporter au moins un tunnel Cloud VPN avec des routes à destination du sous-réseau dans lequel l'équilibreur de charge interne est défini.

Si le réseau appairé est un autre réseau VPC Google Cloud :

  • La passerelle Cloud VPN du réseau appairé peut être située dans n'importe quelle région.

  • Pour les tunnels Cloud VPN qui utilisent le routage dynamique, le mode de routage dynamique du réseau VPC détermine les routes disponibles pour les clients dans chaque région. Pour fournir un ensemble cohérent de routes dynamiques personnalisées aux clients de toutes les régions, utilisez le mode de routage dynamique mondial.

Le schéma suivant illustre les concepts clés en cas d'accès à un équilibreur de charge interne au moyen d'une passerelle Cloud VPN et du tunnel associé. Cloud VPN connecte de manière sécurisée votre réseau sur site à votre réseau VPC Google Cloud à l'aide de tunnels Cloud VPN.

Le schéma illustre la configuration d'un équilibreur de charge TCP/UDP interne. Pour l'équilibreur de charge HTTP(S) interne, Cloud VPN et Cloud Router sont identiques, mais les ressources d'équilibrage de charge diffèrent. Par exemple, la configuration de l'équilibreur de charge HTTP(S) interne nécessite un type de règle de transfert, un proxy cible et un mappage d'URL différents.
Équilibrage de charge TCP/UDP interne et Cloud VPN (cliquez pour agrandir)
Équilibrage de charge interne et Cloud VPN (cliquez pour agrandir)

Notez les éléments de configuration suivants associés à cet exemple :

  • Dans le réseau lb-network, un tunnel Cloud VPN appliquant le routage dynamique a été configuré. Le tunnel VPN, la passerelle et le routeur cloud sont tous situés dans la région us-west1, soit la même région que les composants de l'équilibreur de charge interne.
  • Les règles de pare-feu d'autorisation du trafic entrant ont été configurées de sorte à s'appliquer aux VM de backend des deux groupes d'instances, ig-a et ig-c. Ainsi, elles peuvent recevoir le trafic provenant des adresses IP du réseau VPC et du réseau sur site, 10.1.2.0/24 et 192.168.1.0/24. Aucune règle de pare-feu de refus du trafic sortant n'a été créée. Par conséquent, la règle implicite de sortie autorisée s'applique.
  • Les paquets envoyés par les clients des réseaux sur site, y compris depuis 192.168.1.0/24, vers l'adresse IP de l'équilibreur de charge interne, 10.1.2.99, sont transmis directement à une VM de backend opérationnelle, comme vm-a2, en fonction de l'affinité de session configurée.
  • Les réponses envoyées depuis les VM de backend (telles que vm-a2) sont transmises via le tunnel VPN aux clients sur site.

Pour résoudre des problèmes liés à Cloud VPN, consultez la page Dépannage de Cloud VPN.

Accès via Cloud Interconnect

Vous pouvez accéder à un équilibreur de charge interne depuis un réseau de pairs sur site qui est connecté au réseau VPC de l'équilibreur de charge lorsque toutes les conditions suivantes sont remplies :

  • Le rattachement d'interconnexion (VLAN) et son routeur cloud sont tous deux situés dans la même région que les composants de l'équilibreur de charge, sauf si vous configurez l'accès mondial (uniquement pour l'équilibreur de charge TCP/UDP interne).

  • Les routeurs sur site partagent des routes appropriées qui fournissent des chemins de retour pour les réponses des VM backend aux clients sur site. Les rattachements d'interconnexion (VLAN) pour l'interconnexion dédiée et l'interconnexion partenaire utilisent des routeurs cloud. L'ensemble de routes dynamiques personnalisées qu'ils récupèrent dépend du mode de routage dynamique du réseau de l'équilibreur de charge.

  • Pour l'équilibreur de charge TCP/UDP interne, vous avez configuré des règles de pare-feu afin que les clients sur site puissent communiquer avec les VM de backend de l'équilibreur de charge.

Dans le réseau sur site, au moins un rattachement d'interconnexion (VLAN) doit exister avec les routes appropriées. Les destinations de ces routes incluent le sous-réseau dans lequel l'équilibreur de charge interne est défini. Les règles de pare-feu de sortie doivent également être correctement configurées.

Chemins de sortie multiples

Dans les environnements de production, vous devez utiliser plusieurs tunnels Cloud VPN ou rattachements Cloud Interconnect (VLAN) à des fins de redondance. Cette section traite des exigences concernant l'utilisation de plusieurs tunnels ou VLAN.

Dans le schéma suivant, deux tunnels Cloud VPN connectent lb-network à un réseau sur site. Bien que des tunnels Cloud VPN soient utilisés ici, les mêmes principes s'appliquent à Cloud Interconnect.

Équilibrage de charge TCP/UDP interne et tunnels Cloud VPN multiples (cliquez pour agrandir)
Équilibrage de charge interne et tunnels Cloud VPN multiples (cliquez pour agrandir)

Vous devez configurer chaque tunnel ou chaque rattachement Cloud Interconnect (VLAN) dans la même région que l'équilibreur de charge interne, sauf si vous avez activé l'accès mondial (uniquement pour l'équilibrage de charge TCP/UDP interne). Les tunnels ou VLAN multiples peuvent fournir une bande passante supplémentaire ou servir de chemins de secours à des fins de redondance.

Gardez à l'esprit les points suivants :

  • Si le réseau sur site comporte deux routes ayant la même priorité, chacune avec la destination 10.1.2.0/24 et un saut suivant correspondant à un autre tunnel VPN dans la même région que l'équilibreur de charge interne, le trafic peut être envoyé depuis le réseau sur site (192.168.1.0/24) vers l'équilibreur de charge à l'aide du routage ECMP (Equal Cost Multi-Path).
  • Une fois les paquets transmis au réseau VPC, l'équilibreur de charge interne les distribue aux VM de backend en fonction de l'affinité de session configurée.
  • Si le réseau lb-network comporte deux routes, chacune avec la destination 192.168.1.0/24 et un saut suivant correspondant à différents tunnels VPN, les réponses des VM de backend peuvent être transmises sur chaque tunnel selon la priorité des routes sur le réseau. Si des priorités de route différentes sont utilisées, un tunnel peut servir de sauvegarde pour l'autre. Si les priorités sont les mêmes, les réponses sont transmises via le routage ECMP.
  • Les réponses envoyées depuis les VM de backend (telles que vm-a2) sont transmises directement aux clients sur site, via le tunnel approprié. Du point de vue de lb-network, si des routes ou des tunnels VPN changent, le trafic sortant peut utiliser un autre tunnel. Cela peut entraîner la réinitialisation de la session TCP si une connexion en cours est interrompue.

Étape suivante