Interactions avec les produits Cloud NAT

Cette page décrit les interactions importantes entre Cloud NAT et d'autres produits Google Cloud.

Interaction avec les routes

Une passerelle NAT publique ne peut utiliser que des routes dont les sauts suivants sont la passerelle Internet par défaut. Chaque réseau cloud privé virtuel (VPC) commence par une route par défaut dont la destination est 0.0.0.0/0 et dont le saut suivant est la passerelle Internet par défaut. Pour obtenir des informations générales essentielles, consultez la présentation des routes.

Les exemples suivants illustrent les situations susceptibles de provoquer l'incompatibilité des passerelles NAT publiques:

  • Si vous créez une route statique personnalisée avec des sauts suivants définis sur tout autre type de route statique personnalisée comme saut suivant, les paquets dont les adresses IP de destination correspondent à la destination de la route sont envoyés à ce saut suivant plutôt qu'à la passerelle Internet par défaut. Par exemple, si vous utilisez des instances de machines virtuelles (VM) exécutant une passerelle NAT, un pare-feu ou un logiciel proxy, vous créez des routes statiques personnalisées pour diriger le trafic vers ces VM en tant que saut suivant. Les VM du saut suivant nécessitent des adresses IP externes. Ainsi, le trafic provenant des VM qui reposent sur les VM de saut suivant ou des VM de saut suivant elles-mêmes ne peut pas utiliser de passerelles NAT publiques.

  • Si vous créez une route statique personnalisée dont le saut suivant est un tunnel Cloud VPN, la NAT publique n'utilise pas cette route. Par exemple, une route statique personnalisée avec la destination 0.0.0.0/0 et un tunnel Cloud VPN de saut suivant dirige le trafic vers ce tunnel, et non vers la passerelle Internet par défaut. Par conséquent, les passerelles NAT publiques ne peuvent pas utiliser cette route. De même, les passerelles NAT publiques ne peuvent pas utiliser de routes statiques personnalisées avec des destinations plus spécifiques, y compris 0.0.0.0/1 et 128.0.0.0/1.

  • Si un routeur sur site annonce une route dynamique personnalisée vers un routeur Cloud Router gérant un tunnel Cloud VPN ou un rattachement de VLAN, les passerelles NAT publiques ne peuvent pas utiliser cette route. Par exemple, si votre routeur sur site annonce une route dynamique personnalisée avec la destination 0.0.0.0/0, 0.0.0.0/0 est dirigé vers le tunnel Cloud VPN ou le rattachement de VLAN. Ce comportement est valable même pour des destinations plus spécifiques, y compris 0.0.0.0/1 et 128.0.0.0/1.

La fonctionnalité NAT privée utilise les routes suivantes:

  • Pour la NAT inter-VPC, la NAT privée n'utilise que les routes de sous-réseau échangées par deux spokes VPC Network Connectivity Center associés à un hub Network Connectivity Center. Pour en savoir plus sur les spokes VPC Network Connectivity Center, consultez la page Présentation des spokes VPC.
  • Pour le NAT hybride (Preview), le NAT privé utilise les routes dynamiques apprises par Cloud Router sur Cloud VPN.

Interaction avec l'accès privé à Google

Une passerelle NAT publique n'exécute jamais de NAT pour le trafic envoyé aux adresses IP externes pour les API et les services Google sélectionnées. À la place, Google Cloud active automatiquement l'accès privé à Google pour une plage d'adresses IP de sous-réseau lorsque vous configurez une passerelle NAT publique pour qu'elle s'applique à cette plage de sous-réseaux, principale ou secondaire. Tant que la passerelle fournit une NAT pour la plage d'un sous-réseau, l'accès privé à Google est appliqué à cette plage et ne peut pas être désactivé manuellement.

Une passerelle NAT publique ne modifie pas le fonctionnement de l'accès privé à Google. Pour plus d'informations, consultez la section Accès privé à Google.

Les passerelles NAT privées ne s'appliquent pas à l'accès privé à Google.

Interaction avec le VPC partagé

Le VPC partagé permet à plusieurs projets de service d'une même organisation d'utiliser un réseau VPC partagé commun dans un projet hôte. Pour fournir la NAT pour les VM dans les projets de service qui utilisent un réseau VPC partagé, vous devez créer des passerelles Cloud NAT dans le projet hôte.

Interaction avec l'appairage de réseau VPC

Les passerelles Cloud NAT sont associées à des plages d'adresses IP de sous-réseau dans une seule région et un seul réseau VPC. Une passerelle Cloud NAT créée dans un réseau VPC ne peut pas fournir de NAT aux VM d'autres réseaux VPC connectés à l'aide de l'appairage de réseaux VPC ou de spokes VPC Network Connectivity Center, même si les VM des réseaux appairés se trouvent dans la même région que la passerelle.

Interaction GKE

Une passerelle NAT publique peut effectuer la NAT pour les nœuds et les pods d'un cluster privé, qui est un type de cluster de VPC natif. La passerelle NAT publique doit être configurée pour s'appliquer au moins aux plages d'adresses IP de sous-réseau suivantes pour le sous-réseau utilisé par votre cluster:

  • Plage d'adresses IP principale du sous-réseau (utilisée par les nœuds)
  • Plage d'adresses IP secondaire du sous-réseau pour les pods du cluster
  • Plage d'adresses IP secondaire du sous-réseau pour les services du cluster

Le moyen le plus simple de fournir une NAT à l'ensemble d'un cluster privé consiste à configurer une passerelle NAT publique à appliquer à toutes les plages d'adresses IP du sous-réseau du cluster.

Pour obtenir des informations générales sur la façon dont les clusters VPC natifs utilisent les plages d'adresses IP de sous-réseau, consultez la section Plages d'adresses IP pour les clusters de VPC natif.

Lorsqu'une passerelle NAT publique est configurée pour fournir la NAT à un cluster privé, elle réserve les adresses IP sources et les ports sources NAT pour chaque VM de nœud. Ces adresses IP sources et ports sources NAT sont utilisables par les pods, car les adresses IP des pods sont mises en œuvre sous la forme de plages d'adresses IP d'alias attribuées à chaque VM de nœud.

Les clusters de VPC natif Google Kubernetes Engine (GKE) attribuent toujours à chaque nœud une plage d'adresses IP d'alias contenant plusieurs adresses IP (masque de réseau inférieur à /32).

  • Si l'allocation de ports statiques est configurée, la procédure de réservation de port public du NAT réserve au moins 1 024 ports sources par nœud. Si la valeur spécifiée pour le nombre minimal de ports par VM est supérieure à 1 024, cette valeur est utilisée.

  • Si l'allocation dynamique de ports est configurée, la valeur spécifiée pour le nombre minimal de ports par VM est initialement allouée par nœud. Le nombre de ports alloués varie ensuite entre les valeurs spécifiées pour le nombre minimal et maximal de ports par VM, en fonction de la demande.

Pour plus d'informations sur les plages d'adresses IP des pods et les clusters de VPC natif, consultez la page Plage d'adresses IP secondaire de sous-réseau utilisée par les pods.

Indépendamment de la NAT publique, Google Kubernetes Engine effectue la traduction d'adresse réseau source (NAT ou SNAT source) à l'aide d'un logiciel exécuté sur chaque nœud lorsque les pods envoient des paquets sur Internet, sauf si vous avez modifié la configuration du masquage d'adresses IP du cluster. Si vous avez besoin d'un contrôle précis du trafic de sortie des pods, vous pouvez utiliser une règle de réseau.

Dans certaines circonstances, la NAT publique peut également être utile pour les clusters de VPC natif non privés. Étant donné que les nœuds d'un cluster non privé ont des adresses IP externes, les paquets envoyés à partir de l'adresse IP interne principale du nœud ne sont jamais traités par Cloud NAT. Toutefois, si vous souhaitez que votre cluster public utilise des adresses IP externes statiques fournies par une passerelle NAT publique, procédez comme suit:

  • Configurez la passerelle NAT publique pour qu'elle ne s'applique qu'à la plage d'adresses IP secondaire des objets pod du cluster.
  • Configurez votre cluster de manière à désactiver la SNAT par défaut afin que GKE conserve les adresses IP des objets pod sources des paquets envoyés sur Internet.
  • Configurez votre agent de masquage d'adresses IP en spécifiant des CIDR appropriés en tant que destinations non masquées, afin que l'agent conserve les adresses IP des objets pod sources des paquets envoyés vers les destinations non masquées.

L'exemple suivant montre une interaction typique d'une NAT publique avec GKE:

NAT public avec GKE
NAT public avec GKE (cliquez pour agrandir).

Dans cet exemple, vous souhaitez que vos conteneurs soient traduits avec la NAT. Pour activer la NAT pour tous les conteneurs et le nœud GKE, vous devez choisir toutes les plages d'adresses IP de Subnet 1 comme candidat pour la NAT:

  • Plage d'adresses IP principale du sous-réseau: 10.240.0.0/24
  • Plage d'adresses IP secondaire du sous-réseau utilisée pour les pods: 10.0.0.0/16

Il n'est pas possible d'activer la NAT uniquement pour Pod1 ou Pod2.

Une passerelle NAT privée peut effectuer la NAT pour les nœuds et les pods d'un cluster privé et d'un cluster non privé. Elle s'applique automatiquement à toutes les plages d'adresses IP du sous-réseau privé utilisé par votre cluster.

Interactions directes de sortie VPC

Les passerelles NAT publiques peuvent exécuter la NAT pour les services Cloud Run ou les tâches configurées avec une sortie VPC directe. Pour permettre à vos instances de sortie VPC directe d'utiliser une passerelle NAT publique, configurez-la avec les paramètres suivants:

  • Spécifiez l'option --nat-all-subnet-ip-ranges pour permettre à toutes les plages d'adresses IP de tous les sous-réseaux de la région d'utiliser la passerelle NAT publique.
  • Définissez la valeur de l'option --endpoint-types sur ENDPOINT_TYPE_VM. Cette valeur garantit que seules les VM (y compris les VM de sortie VPC directe) peuvent utiliser la passerelle NAT publique.
  • Dans le cas d'une allocation de ports statique, définissez la valeur de l'option --min-ports-per-vm sur quatre fois le nombre de ports requis par une seule instance Cloud Run.
  • En cas d'allocation manuelle d'adresses IP NAT, attribuez un nombre approprié d'adresses IP à votre passerelle NAT publique pour prendre en compte la somme du nombre d'instances Google Cloud et du nombre d'instances de sortie VPC directe que vous avez déployées dans votre réseau VPC.

En plus de la configuration de la passerelle, pour envoyer le trafic de sortie à partir d'un service ou d'une tâche Cloud Run, vous devez définir l'option --vpc-egress sur all-traffic lorsque vous créez le service ou la tâche.

Si vous avez configuré un service ou une tâche Cloud Run dont l'option --vpc-egress est définie sur private-ranges-only, le service ou la tâche n'envoie du trafic qu'aux adresses IP internes. Vous n'avez pas besoin d'une passerelle NAT publique pour acheminer le trafic vers des destinations internes.

Pour empêcher les services ou les tâches Cloud Run dont l'option --vpc-egress est définie sur private-ranges-only d'utiliser une passerelle NAT publique, procédez comme suit:

  • Configurez la passerelle NAT publique avec l'option --nat-custom-subnet-ip-ranges.
  • Définissez la valeur de l'option --nat-custom-subnet-ip-ranges sur les noms des sous-réseaux dans lesquels vous avez déployé des services ou des tâches Cloud Run avec l'option --vpc-egress définie sur all-traffic.

Les limites suivantes s'appliquent aux services et tâches Cloud Run qui utilisent des passerelles NAT publiques:

  • Les métriques Cloud NAT pour les points de terminaison de sortie directe du VPC ne sont pas exportées vers Cloud Monitoring.
  • Les journaux Cloud NAT pour la sortie directe du VPC n'affichent pas le nom d'un service, d'une révision ou d'une tâche Cloud Run.

Vous ne pouvez pas utiliser de passerelles NAT privées avec des instances de sortie VPC directe.

Interactions avec les tests de connectivité

Vous pouvez utiliser les tests de connectivité pour vérifier la connectivité entre les points de terminaison du réseau qui utilisent des configurations Cloud NAT. Vous pouvez exécuter des tests de connectivité sur des réseaux qui utilisent des passerelles NAT publiques ou des passerelles NAT privées, ou les deux.

Vous pouvez afficher les détails de la configuration NAT dans le volet Trace d'analyse de la configuration de la page Détails du test de connectivité.

Interaction avec Cloud Load Balancing

Les équilibreurs de charge d'application internes régionaux et les équilibreurs de charge d'application externes régionaux communiquent avec plusieurs backends de groupes de points de terminaison du réseau Internet (NEG) régionaux. En configurant des passerelles Cloud NAT pour les NEG Internet régionaux, vous pouvez allouer votre propre ensemble de plages d'adresses IP externes à partir de l'origine du trafic Google Cloud. Les vérifications d'état et le trafic du plan de données proviennent des adresses IP NAT que vous allouez.

D'autres équilibreurs de charge externes Google Cloud et systèmes de vérification de l'état communiquent avec les VM via des routes spéciales. Les VM de backend n'ont pas besoin d'adresses IP externes, et une passerelle Cloud NAT ne gère pas la communication pour les équilibreurs de charge ni les vérifications d'état. Pour en savoir plus, consultez la page Présentation de Cloud Load Balancing et la page Présentation des vérifications d'état.

Étapes suivantes