Interactions du produit 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 tout autre type de saut suivant 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 de saut suivant nécessitent des adresses IP externes : Ainsi, le trafic provenant des VM qui dépendent des VM de saut suivant, ou celui 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,Public NATn'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 passerellesPublic NATne 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 de 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 de VLAN. Ce principe s'applique même pour des destinations plus spécifiques, y compris 0.0.0.0/1 et 128.0.0.0/1.

Private NAT 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 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, Private NAT 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 Spokes hybrides.
Pour Hybrid NAT, Private NAT utilise les routes dynamiques apprises par Cloud Router sur Cloud Interconnect ou Cloud VPN.

Interactions avec l'accès privé à Google

Une passerellePublic NATn'effectue jamais d'opération de NAT pour le trafic envoyé aux adresses IP externes sélectionnées pour les API et services Google. Au lieu de cela,Google Cloud active automatiquement l'accès privé à Google pour une plage d'adresses IP de sous-réseau lorsque vous configurez une passerellePublic NATà appliquer à cette plage de sous-réseaux, qu'elle soit principale ou secondaire. Tant que la passerelle fournit une fonctionnalité NAT pour une 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 mode de fonctionnement de l'accès privé à Google. Pour plus d'informations, consultez Accès privé à Google.

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

Interactions avec les VPC partagés

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

Interactions avec l'appairage de réseaux 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 fonctionnalité NAT aux VM d'autres réseaux VPC connectés via l'appairage de réseaux VPC, même si les VM des réseaux appairés se trouvent dans la même région que la passerelle.

Interactions avec GKE

Une passerelleCloud NATpeut effectuer des opérations de NAT pour les nœuds et les pods dans un cluster privé, qui est un type de cluster VPC natif. La passerelleCloud NATdoit être configurée de sorte à 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 utilisée pour les services du cluster

Le moyen le plus simple de fournir une fonctionnalité NAT pour l'intégralité d'un cluster privé est de configurer une passerellePublic NATdevant s'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 Plages d'adresses IP pour les clusters de VPC natif.

Lorsqu'une passerellePublic NATest configurée pour fournir une fonctionnalité NAT pour un cluster privé, elle réserve des 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 implémentées 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 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 de ports dynamique 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 le nombre 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 Plage d'adresses IP secondaire de sous-réseau utilisée par les pods.

Indépendamment dePublic 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 vers 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,Public NATpeut é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 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 dédiée aux pods du cluster.
Le masquage des adresses IP du cluster n'est pas configuré pour exécuter le SNAT dans le cluster pour les paquets envoyés depuis des pods vers Internet.

L'exemple suivant illustre l'interaction dePublic NATavec GKE :

Dans cet exemple, vous souhaitez appliquer le NAT à vos conteneurs. Pour activer la fonctionnalité NAT pour tous les conteneurs et le nœud GKE, vous devez sélectionner toutes les plages d'adresses IP de Subnet 1 comme candidats 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 fonctionnalité NAT uniquement pour Pod1 ou Pod2.

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

Interactions avec la sortie VPC directe

Les passerelles Cloud NAT peuvent fournir une fonctionnalité NAT pour les ressources Cloud Run configurées avec la sortie VPC directe. Pour permettre à Cloud Run d'utiliser une passerelle Cloud NAT pour Public NAT ou Private NAT, configurez les éléments suivants :

Lorsque vous déployez vos ressources Cloud Run, définissez l'option --vpc-egress. Si vous souhaitez utiliser Public NAT, la valeur doit être définie sur all-traffic.
Configurez la passerelle Cloud NAT avec les paramètres suivants :
- Spécifiez les plages de sous-réseaux sources pouvant utiliser la passerelle en définissant l'option --nat-custom-subnet-ip-ranges. Définissez la valeur sur les noms de sous-réseaux dans lesquels vous déployez vos ressources Cloud Run.
- Définissez la valeur de l'option --endpoint-types sur ENDPOINT_TYPE_VM.
- Pour Public NAT, assurez-vous que la valeur de l'option --min-ports-per-vm est définie sur le double du nombre de ports nécessaires à une seule instance Cloud Run. Pour Private NAT, cette option doit être définie sur le quadruple du nombre de ports nécessaires par instance Cloud Run.
- Si vous souhaitez configurer l'allocation manuelle d'adresses IP NAT (Public NAT uniquement), attribuez à votre passerelle un nombre d'adresses IP suffisant pour couvrir le nombre d'instances de VM et d'instances Cloud Run desservies par la passerelle.

Les journaux Cloud NAT pour la sortie VPC directe n'affichent pas les noms des ressources Cloud Run.

Interactions avec les 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 les réseaux qui utilisent des passerelles Public NAT, des passerelles Private NAT, ou les deux.

Vous pouvez afficher 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 communiquent avec plusieurs backends de groupe de points de terminaison réseau (NEG) Internet régionaux.Google Cloud En configurant des passerelles Cloud NAT pour les NEG Internet régionaux, vous pouvez allouer un ensemble spécifique 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 et systèmes de vérification de l'état Google Cloud 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 présentation de Cloud Load Balancing et la présentation des vérifications d'état.

Interactions avec les connexions propagées Private Service Connect

Lorsque vous utilisez la Private NAT pour Network Connectivity Center et les connexions propagées Private Service Connect dans le même spoke VPC, les règles suivantes s'appliquent :

Si un sous-réseau est configuré avec Private NAT, le trafic du sous-réseau vers les connexions propagées Private Service Connect est abandonné.
Pour éviter de perdre du trafic provenant de sous-réseaux qui ne se chevauchent pas, tenez compte des points suivants lorsque vous configurez Private NAT :
- Spécifiez les sous-réseaux qui se chevauchent à l'aide de l'option --nat-custom-subnet-ip-ranges.
- Ne spécifiez pas de sous-réseaux ne se chevauchant pas qui doivent accéder aux connexions propagées.
- N'utilisez pas l'option --nat-all-subnet-ip-ranges.

Étapes suivantes

Obtenez plus d'informations sur les adresses et ports Cloud NAT.
Configurez une passerelle Public NAT.
Configurez des règles Cloud NAT.
Configurez une passerelle Private NAT.