Interactions avec les produits Cloud NAT

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

Interaction avec les routes

Une passerelle Public NAT ne peut utiliser que des routes dont les sauts suivants sont la passerelle Internet par défaut. Chaque réseau de 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 importantes, consultez la présentation des routes.

Les exemples suivants illustrent des situations pouvant entraîner l'inopérabilité des passerelles Public NAT :

  • Si vous créez une route statique personnalisée avec les prochains sauts définis sur tout autre type de prochain saut de route statique personnalisée, 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 machine virtuelle (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 dépendent des VM du saut suivant ou des VM de saut suivant elles-mêmes ne peut pas utiliser les passerelles Public NAT .

  • Si vous créez une route statique personnalisée dont le saut suivant est un tunnel Cloud VPN, Public NAT 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 Public NAT ne peuvent pas utiliser cette route. De même, les passerelles Public NAT 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, Public NAT les passerelles 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 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 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 section Présentation des spokes VPC.
  • Pour la NAT hybride (version preview), Private NAT utilise les routes dynamiques apprises par Cloud Router via Cloud VPN.

Interaction avec l'accès privé à Google

Une passerelle Public NAT n'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 passerelle Public NAT pour s'appliquer à cette plage de sous-réseau, 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 Public NAT ne 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 d'autres réseaux VPC connectés à l'aide de l'appairage de réseaux VPC ou des 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 Public NAT peut effectuer une NAT pour les nœuds et les pods d'un cluster privé, qui est un type de cluster de VPC natif. La passerelle Public NAT 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 pour l'ensemble d'un cluster privé consiste à configurer une passerelle Public 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 passerelle Public NAT est configurée pour fournir une 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 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 Public NAT , 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 d'adresses IP du cluster. Si vous avez besoin d'un contrôle précis sur le trafic de sortie des pods, vous pouvez utiliser une règle de réseau.

Dans certains cas, la fonctionnalitéPublic NAT peut également s'avérer utile pour les clusters de 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 des pods d'un cluster non privé peuvent être traités par une passerellePublic NAT:

  • Pour les clusters de VPC natif, la passerelle Public NAT est 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 de Public NAT avec GKE:

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

Dans cet exemple, vous souhaitez que vos conteneurs soient traduits via la NAT. Pour activer la fonctionnalité NAT pour tous les conteneurs et le nœud GKE, vous devez choisir toutes les plages d'adresses IP de Subnet 1 en tant que traduction automatique 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 le NAT uniquement pour Pod1 ou Pod2.

Une passerelle NAT privée peut effectuer une 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 de sous-réseau du sous-réseau privé utilisé par votre cluster.

Interactions directes de sortie VPC

Public NAT Les passerelles peuvent effectuer une NAT pour les services Cloud Run ou les jobs configurés avec une sortie VPC directe. Pour permettre à Cloud Run d'utiliser une passerelle Public NAT vous devez configurer votre passerelle Public NAT avec 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 passerelle Public NAT , spécifiez l'option --nat-all-subnet-ip-ranges ou --nat-custom-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 Public NAT , spécifiez l'option --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 avec l'option --nat-custom-subnet-ip-ranges.
  • Définissez la valeur de l'option --endpoint-types sur ENDPOINT_TYPE_VM. Cette valeur garantit que seuls les VM et les points de terminaison de VM de sortie VPC direct peuvent utiliser la passerelle Public NAT .
  • En cas d'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 Public NAT afin de prendre en compte 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 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 le trafic qu'aux adresses IP internes. Vous n'avez pas besoin d'une passerelle Public NAT pour acheminer le trafic vers des destinations internes.

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

  • Configurez la passerellePublic NATavec 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 sur 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 aux tâches Cloud Run qui utilisent des passerelles Public NAT:

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

Interactions des tests de connectivité

Vous pouvez utiliser des 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.

Affichez 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 d'où doit provenir le 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 à l'aide de routes spéciales. Les VM de backend ne nécessitent pas d'adresses IP externes, et une 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.

Étapes suivantes