Interactions des produits Cloud NAT

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

Interaction avec les routes

Une passerellePublic NATne peut utiliser que des routes dont les sauts suivants correspondent à 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 correspond à 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'inopérabilité des passerellesPublic NAT:

  • Si vous créez une route statique avec des sauts suivants définis sur saut suivant vers tout type de route statique, les paquets dont les adresses IP de destination correspondent à la destination de la route sont envoyés vers ce saut suivant plutôt qu'à la passerelle Internet par défaut. Par exemple, si vous utilisez des instances de machine virtuelle (VM) exécutant une passerelle NAT, un pare-feu ou un logiciel proxy, vous créez des routes statiques 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 dépendent des VM de saut suivant ou des VM de saut suivant elles-mêmes ne peut pas utiliser les passerellesPublic NAT.

  • Si vous créez une route statique personnalisée dont le saut suivant est un tunnel Cloud VPN, NAT public n'utilise pas cette route. Par exemple, une route statique 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 passerellesPublic NATne peuvent pas utiliser cette route. De même, les passerelles,ne peuvent pas utiliser de routes statiques 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 vers un routeur Cloud Router qui gère un tunnel Cloud VPN ou un rattachement VLAN, les passerellesPublic NATne peuvent pas utiliser cette route. Par exemple, si votre routeur sur site annonce une route dynamique avec la destination 0.0.0.0/0, 0.0.0.0/0 est dirigée vers le tunnel Cloud VPN ou le rattachement VLAN. Ce comportement s'applique même pour des destinations plus spécifiques, y compris 0.0.0.0/1 et 128.0.0.0/1.

Le NAT privé utilise les routes suivantes:

  • Pour les spokes Network Connectivity Center, Private NAT utilise des routes de sous-réseau et des routes dynamiques :
    • Pour le trafic entre deux spokes VPC associés à un hub Network Connectivity Center qui ne contient que des spokes VPC, Private NAT utilise les routes de sous-réseau échangées par les spokes VPC associés. Pour en savoir plus sur les spokes VPC, consultez la section Présentation des spokes VPC.
    • Si un hub Network Connectivity Center contient à la fois des spokes VPC et des spokes hybrides tels que des rattachements de VLAN pour Cloud Interconnect, des tunnels Cloud VPN ou des VM d'appareil de routeur, le NAT privé utilise les routes dynamiques apprises par les spokes hybrides via BGP et les routes de sous-réseau échangées par les spokes VPC associés. Pour en savoir plus sur les spokes hybrides, consultez la section Spokes hybrides.
  • Pour le NAT hybride, le NAT privé utilise des routes dynamiques apprises par Cloud Router via Cloud Interconnect ou Cloud VPN.

Interaction avec l'accès privé à Google

Une passerellePublic NATn'effectue jamais de NAT pour le trafic envoyé aux adresses IP externes sélectionnées pour les API et services Google. À 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 passerellePublic NATpour qu'elle s'applique à cette plage de sous-réseaux, qu'elle soit 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 passerellePublic NATne modifie pas le fonctionnement de l'accès privé à Google. Pour en savoir plus, 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 sur d'autres réseaux VPC connectés via l'appairage de réseau VPC, même si les VM des réseaux appairés se trouvent dans la même région que la passerelle.

Interaction GKE

Une passerellePublic NATpeut effectuer une NAT pour les nœuds et les pods dans un cluster privé, qui est un type de cluster de VPC natif. La passerellePublic NATdoit ê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 pour l'intégralité d'un cluster privé est de configurer une passerellePublic NATà appliquer à toutes les plages d'adresses IP de sous-réseau 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 passerellePublic NATest configurée pour fournir une NAT pour un cluster privé, elle réserve les adresses IP sources et les ports sources NAT de 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 statique est configurée, la procédure de réservation de port NAT public 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 NAT public , Google Kubernetes Engine effectue la traduction d'adresse réseau source (NAT source ou SNAT) à l'aide d'un logiciel exécuté sur chaque nœud lorsque les pods envoient des paquets à Internet, sauf si vous avez modifié la configuration du masquage des 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, Public NAT peuvent également être utiles pour les clusters VPC natifs 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 les deux conditions suivantes sont remplies, les paquets envoyés à partir de pods dans un cluster non privé peuvent être traités par une passerellePublic NAT:

  • Pour les clusters de VPC natif, la passerellePublic NATest configurée pour s'appliquer à la plage d'adresses IP secondaire des pods du cluster.

  • La configuration du masquage des adresses IP du cluster n'est pas configurée pour exécuter la SNAT dans le cluster pour les paquets envoyés depuis des pods vers Internet.

L'exemple suivant montre l'interaction entre, le NAT publicavec GKE:

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

Dans cet exemple, vous souhaitez appliquer la NAT à vos conteneurs. Pour activer la NAT pour tous les conteneurs et le nœud GKE, vous devez sélectionner toutes les plages d'adresses IP de Subnet 1 comme candidat 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 par les pods: 10.0.0.0/16

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

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

Interactions de sortie VPC directe

NAT public Les passerelles peuvent effectuer la NAT pour les services ou les tâches Cloud Run configurés avec la sortie VPC directe. Pour permettre à Cloud Run d'utiliser une passerellePublic NAT, configurez votre passerellePublic NATavec les paramètres suivants:

  • Pour configurer les sous-réseaux et les plages d'adresses IP de sous-réseau associés à vos instances Cloud Run qui peuvent utiliser la passerellePublic NAT, spécifiez l'indicateur --nat-all-subnet-ip-ranges ou --nat-custom-subnet-ip-ranges :
    • Pour autoriser toutes les plages d'adresses IP de tous les sous-réseaux de la région à utiliser la passerelle Public NAT, spécifiez l'indicateur --nat-all-subnet-ip-ranges.
    • Pour n'autoriser que des sous-réseaux et des plages d'adresses IP de sous-réseau spécifiques à utiliser la passerelle Public NAT, spécifiez-les à l'aide de l'indicateur --nat-custom-subnet-ip-ranges.
  • Définissez la valeur de l'option --endpoint-types sur ENDPOINT_TYPE_VM. Cette valeur garantit que seules les VM et les points de terminaison de VM de sortie VPC directe peuvent utiliser la passerelle Public NAT.
  • En cas d'allocation de port statique, définissez la valeur de l'indicateur --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 passerellePublic NATpour tenir compte de la somme du nombre d'instances Google Cloud et du nombre d'instances Cloud Run déployées dans votre réseau VPC.

En plus de la configuration de la passerelle, pour envoyer du trafic sortant à partir d'un service ou d'un job Cloud Run, vous devez définir l'indicateur --vpc-egress sur all-traffic lorsque vous créez le service ou le job.

Si vous avez configuré un service ou un job Cloud Run pour lequel l'indicateur --vpc-egress est défini sur private-ranges-only, le service ou le job n'envoie du trafic qu'aux adresses IP internes. Vous n'avez pas besoin d'une passerellePublic NATpour router le trafic vers des destinations internes.

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

  • Configurez la passerellePublic NAT,avec l'indicateur --nat-custom-subnet-ip-ranges.
  • Définissez la valeur de l'indicateur --nat-custom-subnet-ip-ranges sur les noms de sous-réseaux où vous avez déployé des services ou des tâches Cloud Run avec l'indicateur --vpc-egress défini sur all-traffic.

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

  • Les métriques Cloud NAT pour les points de terminaison de sortie VPC directs ne sont pas exportées vers Cloud Monitoring.
  • Les journaux Cloud NAT pour la sortie VPC directe 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 points de sortie VPC directs.

Interactions avec Tests de connectivité

Vous pouvez utiliser les tests de connectivité pour vérifier la connectivité entre les points de terminaison 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.

Affichez les détails de la configuration NAT dans le volet Trace de l'analyse de la configuration de la page Informations sur le 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 de Google Cloud communiquent avec plusieurs backends de groupe de points de terminaison réseau Internet régionaux (NEG). 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 desquelles le trafic Google Cloud doit être émis. Les vérifications de l'é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 à l'aide de chemins de routage spéciaux. Les VM de backend ne nécessitent pas d'adresses IP externes, et la passerelle Cloud NAT ne gère pas la communication pour les équilibreurs de charge et 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.

Étape suivante