Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Présentation de Cloud NAT

Cloud NAT (traduction d'adresses réseau) permet à certaines ressources sans adresse IP externe de créer des connexions sortantes sur Internet.

Cloud NAT fournit une connectivité sortante pour les ressources suivantes :

Architecture

Cloud NAT est un service géré distribué et défini par logiciel. Il n'est pas basé sur les VM ou les appareils de proxy. Cloud NAT configure le logiciel Andromeda qui alimente votre réseau de cloud privé virtuel (VPC), afin qu'il effectue la traduction des adresses réseau sources (NAT source ou SNAT) pour les VM sans adresse IP externe. Cloud NAT fournit également une traduction des adresses réseau de destination (NAT de destination ou DNAT) pour les paquets de réponses entrants établis.

Comparaison de la fonctionnalité NAT traditionnelle à Cloud NAT (cliquez pour agrandir)
Comparaison de la fonctionnalité NAT traditionnelle à Cloud NAT (cliquez pour agrandir)

Cloud NAT met en œuvre la NAT sortante via des routes statiques de votre réseau VPC dont les sauts suivants correspondent à la passerelle Internet par défaut. Dans une configuration de base, une route par défaut dans votre réseau VPC répond à cette exigence.

Cloud NAT ne met pas en œuvre de connexions entrantes non sollicitées en provenance d'Internet. La traduction DNAT n'est effectuée que pour les paquets qui arrivent en tant que réponses aux paquets sortants.

Avantages

Cloud NAT offre les avantages suivants :

  • Sécurité

    Vous pouvez réduire le besoin de chaque VM de disposer chacune d'une adresse IP externe. Sous réserve des règles de pare-feu de sortie, les VM sans adresse IP externe peuvent accéder aux destinations sur Internet. Par exemple, vous avez peut-être des VM qui n'ont besoin que d'un accès Internet pour télécharger des mises à jour ou effectuer le provisionnement.

    Si vous utilisez l'attribution manuelle d'adresses IP NAT pour configurer une passerelle Cloud NAT, vous pouvez partager sans difficulté un ensemble d'adresses IP sources courantes avec groupe de destination. Par exemple, un service de destination peut autoriser uniquement les connexions à partir d'adresses IP externes connues.

  • Disponibilité

    Cloud NAT est un service géré distribué et défini par logiciel. Il ne dépend d'aucune VM de votre projet, ni d'un seul appareil avec passerelle physique. Vous configurez une passerelle NAT sur un routeur Cloud Router, qui fournit le plan de contrôle pour NAT, contenant les paramètres de configuration que vous spécifiez. Google Cloud exécute et gère les processus sur les machines physiques qui exécutent vos VM Google Cloud.

  • Évolutivité

    Cloud NAT peut être configuré pour effectuer le scaling automatique du nombre d'adresses IP NAT qu'il utilise. Il accepte les VM appartenant à des groupes d'instances gérés, y compris celles disposant de l'autoscaling activé.

  • Performances

    Cloud NAT ne réduit pas la bande passante réseau par VM. Cloud NAT est mis en œuvre par le réseau défini par logiciel Andromeda de Google. Pour plus d'informations, consultez la section Bande passante réseau de la documentation Compute Engine.

Spécifications

Cloud NAT peut être configuré pour fournir une NAT à destination d'Internet pour les paquets envoyés depuis les ressources suivantes :

  • Adresse IP interne principale de l'interface réseau de la VM Compute Engine, à condition que l'interface réseau ne dispose pas d'une adresse IP externe. Si une adresse IP externe est attribuée à l'interface réseau, Google Cloud applique automatiquement une NAT de type un à un aux paquets dont les sources correspondent à l'adresse IP interne principale de l'interface, car l'interface réseau satisfait aux conditions d'accès à Internet de Google Cloud. L'existence d'une adresse IP externe sur une interface est toujours prioritaire et effectue toujours une NAT de type "un à un", sans utiliser Cloud NAT.

  • Une plage d'adresses IP d'alias attribuée à l'interface réseau de la VM. Même si une adresse IP externe est attribuée à l'interface réseau, vous pouvez configurer une passerelle Cloud NAT pour fournir une NAT aux paquets dont les sources proviennent d'une plage d'adresses IP d'alias de l'interface. Une adresse IP externe sur une interface n'effectue jamais de NAT de type un à un pour les adresses IP d'alias.

  • Pour les clusters GKE, Cloud NAT peut fournir le service même si le cluster dispose d'adresses IP externes dans certaines circonstances. Pour en savoir plus, consultez la section Interaction GKE.

Cloud NAT autorise les connexions sortantes et les réponses entrantes à destination de ces connexions. Chaque passerelle Cloud NAT effectue une NAT source en sortie et une NAT de destination pour les paquets de réponses établis.

Cloud NAT ne met pas en œuvre des requêtes entrantes à partir d'Internet, même si des règles de pare-feu autorisent ces requêtes. Pour en savoir plus, consultez la page Documents RFC applicables.

Chaque passerelle Cloud NAT est associée à un seul réseau VPC, une seule région et un seul routeur Cloud Router. La passerelle Cloud NAT et le routeur Cloud Router fournissent un plan de contrôle. Ils ne sont pas impliqués dans le plan de données. Par conséquent, les paquets ne passent pas par la passerelle Cloud NAT ou le routeur Cloud Router.

Routes et règles de pare-feu

Cloud NAT s'appuie sur des routes statiques personnalisées dont les sauts suivants correspondent à la passerelle Internet par défaut. Pour utiliser pleinement une passerelle Cloud NAT, votre réseau VPC a besoin d'une route par défaut dont le saut suivant correspond à la passerelle Internet par défaut. Pour plus d'informations, reportez-vous à la section Interaction avec les routes.

Cloud NAT ne comporte aucune règle de pare-feu Google Cloud. Les règles de pare-feu sont appliquées directement aux interfaces réseau des VM Compute Engine, et non aux passerelles Cloud NAT.

Vous n'avez pas besoin de créer de règles de pare-feu spéciales autorisant les connexions vers ou depuis les adresses IP NAT. Lorsqu'une passerelle Cloud NAT fournit une NAT pour l'interface réseau d'une VM, les règles de pare-feu de sortie applicables sont évaluées comme des paquets avant la NAT. Les règles de pare-feu d'entrée sont évaluées après que les paquets ont été traités par la NAT.

Applicabilité de la plage d'adresses IP du sous-réseau

Une passerelle Cloud NAT peut fournir des services NAT pour les paquets envoyés depuis l'interface réseau d'une VM Compute Engine, tant qu'aucune adresse IP externe n'est affectée à cette interface réseau. Pour les clusters GKE, Cloud NAT peut fournir le service même si les nœuds de cluster possèdent des adresses IP externes dans certaines circonstances. Pour en savoir plus, consultez la section Interaction GKE.

La passerelle Cloud NAT peut être configurée pour fournir une NAT pour l'adresse IP interne principale de l'interface réseau de la VM, aux plages d'adresses IP principales de l'interface réseau de la VM, ou aux deux. Pour effectuer cette configuration, choisissez les plages d'adresses IP du sous-réseau auxquelles la passerelle doit s'appliquer.

Vous pouvez configurer une passerelle Cloud NAT pour fournir une NAT aux éléments suivants :

  • Plages d'adresses IP principales et secondaires de tous les sous-réseaux de la région. Une passerelle Cloud NAT unique fournit une NAT aux adresses IP internes principales et à toutes les plages d'adresses IP d'alias des VM éligibles dont les interfaces réseau utilisent un sous-réseau dans la région. Cette option utilise exactement une passerelle NAT par région.

  • Plages d'adresses IP principales de tous les sous-réseaux de la région. Une passerelle Cloud NAT unique fournit une NAT aux adresses IP internes principales et aux plages d'adresses IP d'alias appartenant aux plages d'adresses IP principales du sous-réseau des VM éligibles, dont les interfaces réseau utilisent un sous-réseau de la région. Vous pouvez créer des passerelles Cloud NAT supplémentaires dans la région afin de fournir une NAT aux plages d'adresses IP d'alias appartenant aux plages d'adresses IP secondaires du sous-réseau des VM éligibles.

  • Plages d'adresses IP de sous-réseau personnalisées. Vous pouvez créer autant de passerelles Cloud NAT que nécessaire, à condition de respecter les quotas et limites de Cloud NAT. Vous choisissez les plages d'adresses IP principales ou secondaires du sous-réseau qui doivent être utilisées par chaque passerelle.

Bande passante

L'utilisation d'une passerelle Cloud NAT ne modifie pas la quantité de bande passante sortante ou entrante qu'une VM peut utiliser. Pour connaître les spécifications de bande passante, qui varient en fonction du type de machine, consultez la section Bande passante réseau de la documentation Compute Engine.

VM dotées de plusieurs interfaces réseau

Si vous configurez une VM avec plusieurs interfaces réseau, chaque interface doit se trouver dans un réseau VPC distinct. Par conséquent :

  • Une passerelle Cloud NAT ne peut s'appliquer qu'à une seule interface réseau d'une VM. Des passerelles Cloud NAT distinctes peuvent fournir une NAT à la même VM, où chaque passerelle s'applique à une interface distincte.

  • Une interface d'une VM à interfaces réseau multiples peut avoir une adresse IP externe et donc ne pas bénéficier de Cloud NAT, tandis qu'une autre de ses interfaces peut être éligible à la NAT si cette interface n'a pas d'adresse IP externe et si vous avez configuré une passerelle Cloud NAT qui s'applique à la plage d'adresses IP de sous-réseau appropriée.

Adresses IP NAT et ports

Lorsque vous créez une passerelle Cloud NAT, vous pouvez demander à la passerelle d'allouer automatiquement des adresses IP externes régionales. Vous pouvez également attribuer manuellement un nombre fixe d'adresses IP externes régionales à la passerelle. Pour plus d'informations sur chaque méthode, consultez la section Adresses IP NAT.

Vous pouvez configurer le nombre de ports sources que chaque passerelle Cloud NAT réserve à chaque VM à laquelle elle doit fournir des services NAT. Vous pouvez configurer l'allocation de ports statique, où le même nombre de ports est réservé pour chaque VM, ou l'allocation de ports dynamique, où le nombre de ports réservés peut varier entre les limites minimale et maximale que vous spécifiez.

Les VM pour lesquelles le NAT doit être fourni sont déterminées par les plages d'adresses IP de sous-réseau que la passerelle est configurée pour diffuser.

Pour plus d'informations, consultez la section Ports et la procédure de réservation de port.

Documents RFC applicables

Cloud NAT est compatible avec le mappage indépendant des points de terminaison et le filtrage dépendant du point de terminaison, tel que défini dans le document RFC 5128. Vous pouvez activer ou désactiver le mappage indépendant des points de terminaison. Par défaut, le mappage indépendant des points de terminaison est désactivé lorsque vous créez une passerelle NAT.

Le mappage indépendant du point de terminaison implique que si une VM envoie des paquets à partir d'une adresse IP interne donnée et d'une paire de ports vers plusieurs destinations différentes, la passerelle mappe tous ces paquets sur la même adresse IP et paire de ports NAT, quelle que soit la destination des paquets. Pour en savoir plus sur le mappage indépendant des points de terminaison et ses implications, consultez la section Réutilisation simultanée de ports et mappage indépendant des points de terminaison.

Le filtrage indépendant des points de terminaison implique que les paquets de réponse provenant d'Internet ne sont autorisés à entrer que s'ils proviennent d'une adresse IP et d'un port sur lesquels une VM a déjà envoyé des paquets. Le filtrage est dépendant du point de terminaison, quel que soit le type de mappage des points de terminaison. Cette fonctionnalité est toujours activée et ne peut pas être configurée par l'utilisateur.

Pour plus d'informations sur la relation entre les ports et les connexions, consultez la section Ports et connexions et l'exemple de flux NAT.

Cloud NAT est une NAT en cône à restriction de port telle que définie dans le document RFC 3489.

NAT-T (NAT traversal)

Si le mappage indépendant des points de terminaison est activé, Cloud NAT est compatible avec les protocoles NAT-T courants tels que STUN et TURN, si vous déployez vos propres serveurs STUN ou TURN :

  • STUN (Session Traversal Utilities for NAT, RFC 5389) permet la communication directe entre les VM protégées par la NAT lorsqu'un canal de communication est établi.
  • TURN (Traversal Using Relays around NAT, document RFC 5766) permet la communication entre les VM protégées par la NAT via un troisième serveur qui possède une adresse IP externe. Chaque VM se connecte à l'adresse IP externe du serveur et celui-ci retransmet la communication entre les deux VM. TURN est plus stable, mais consomme plus de bande passante et de ressources.

Expiration de la NAT

Les passerelles Cloud NAT utilisent les délais d'expiration suivants : Vous pouvez modifier les valeurs par défaut des délais avant expiration pour diminuer ou augmenter la vitesse à laquelle les ports sont réutilisés. Chaque valeur de délai avant expiration correspond à un équilibre entre une utilisation efficace des ressources Cloud NAT et une perturbation possible des connexions, flux ou sessions actifs.

Délai avant expiration Description Valeur par défaut de Cloud NAT Configurable

Délai d'inactivité du mappage UDP

RFC 4787 REQ-5

Spécifie le délai, en secondes, au-delà duquel les flux UDP doivent cesser d'envoyer du trafic aux points de terminaison afin de supprimer les mappages Cloud NAT.

Le délai d'inactivité du mappage UDP affecte deux points de terminaison qui cessent d'envoyer du trafic l'un à l'autre. Il affecte également les points de terminaison dont la réponse prend plus de temps ou si la latence du réseau augmente.

Vous pouvez augmenter la valeur spécifiée pour le délai avant expiration afin de réduire la fréquence de réutilisation des ports. Une valeur plus élevée du délai d'expiration signifie que les ports sont conservés pour des connexions plus longues et protège ainsi contre les interruptions du trafic qui transite via un socket UDP spécifique.

30 secondes Yes

Délai d'inactivité de la connexion TCP établie

RFC 5382 REQ-5

Spécifie le délai d'inactivité d'une connexion, en secondes, avant la suppression des mappages Cloud NAT.

Le délai d'inactivité de la connexion TCP établie affecte les points de terminaison dont la réponse prend plus de temps ou si la latence du réseau augmente.

Vous pouvez augmenter la valeur de ce délai avant expiration lorsque vous souhaitez ouvrir des connexions TCP et les garder ouvertes longtemps sans mettre en place de mécanisme keepalive.

1 200 secondes (20 minutes) Yes

Délai d'inactivité de la connexion TCP transitoire

RFC 5382 REQ-5

Spécifie le délai, en secondes, pendant lequel les connexions TCP peuvent rester à l'état semi-ouvert avant la suppression des mappages Cloud NAT.

Le délai d'inactivité de la connexion TCP transitoire affecte un point de terminaison lorsqu'un point de terminaison externe prend plus de temps que le délai spécifié ou lorsque la latence du réseau augmente. Contrairement au délai d'inactivité de la connexion TCP établie, le délai d'inactivité de la connexion TCP transitoire n'affecte que les connexions semi-ouvertes.

30 secondes

Remarque : Quelle que soit la valeur définie pour ce délai d'expiration, Cloud NAT peut nécessiter jusqu'à 30 secondes supplémentaires avant qu'un tuple d'adresse IP source et de port source Cloud NAT puisse être utilisé pour traiter une nouvelle connexion.

 Yes

Délai d'inactivité de la connexion TCP TIME_WAIT

RFC 5382 REQ-5

Spécifie le délai, en secondes, pendant lequel une connexion TCP entièrement fermée est conservée dans les mappages Cloud NAT après expiration de la connexion.

Le délai TCP TIME_WAIT empêche vos points de terminaison internes de recevoir des paquets non valides appartenant à une connexion TCP fermée et qui sont retransmis.

Vous pouvez réduire la valeur de ce délai avant expiration pour améliorer la réutilisation des ports Cloud NAT au prix d'une réception possible de paquets retransmis depuis une connexion sans lien et précédemment fermée.

120 secondes

Remarque : Quelle que soit la valeur définie pour ce délai d'expiration, Cloud NAT peut nécessiter jusqu'à 30 secondes supplémentaires avant qu'un tuple d'adresse IP source et de port source Cloud NAT puisse être utilisé pour traiter une nouvelle connexion.

 Yes

Délai d'inactivité du mappage ICMP

RFC 5508 REQ-2

Spécifie le délai, en secondes, au-delà duquel les mappages Cloud NAT ICMP (Internet Control Message Protocol) sans flux de trafic sont fermés.

Le délai d'inactivité du mappage ICMP affecte un point de terminaison lorsque celui-ci prend plus de temps que le délai spécifié ou lorsque la latence du réseau augmente.

30 secondes Yes

Interaction avec les produits

Les sections suivantes décrivent les interactions importantes entre Cloud NAT et d'autres produits Google Cloud.

Interaction avec les routes

Une passerelle Cloud NAT ne peut utiliser que des routes dont les sauts suivants correspondent à la passerelle Internet par défaut. Chaque réseau 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 passerelles Cloud NAT :

  • Si vous créez une route statique personnalisée avec des sauts suivants définis sur saut suivant vers tout type de route statique personnalisée, 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 VM exécutant une NAT, un pare-feu ou un logiciel proxy, vous devriez nécessairement créer 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, ni le trafic provenant des VM qui dépendent des VM du saut suivant, ni les VM du saut suivant elles-mêmes ne peuvent utiliser Cloud NAT.

  • Si vous créez une route statique personnalisée dont le saut suivant est un tunnel Cloud VPN, Cloud 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 Cloud NAT ne pourront pas utiliser cette route. 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.

  • Si un routeur sur site annonce une route dynamique personnalisée vers un routeur Cloud Router qui gère un tunnel Cloud VPN ou un rattachement d'interconnexion Cloud Interconnect (VLAN), les passerelles Cloud NAT ne peuvent pas utiliser cette route. Par exemple, si votre routeur sur site annonce une route dynamique personnalisée à destination de 0.0.0.0/0, 0.0.0.0/0 est dirigé vers le tunnel Cloud VPN ou le rattachement Cloud Interconnect (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.

Interaction avec l'accès privé à Google

Cloud NAT n'exécute 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 Cloud NAT pour 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 passerelle Cloud NAT ne modifie pas le mode de fonctionnement de l'accès privé à Google. Pour plus d'informations, consultez la section 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éseaux 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 passerelle Cloud NAT peut effectuer une NAT pour les nœuds et les pods dans un cluster privé, qui est un type de cluster VPC natif. La passerelle Cloud 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'intégralité d'un cluster privé est de configurer une passerelle Cloud NAT à appliquer à toutes les plages d'adresses IP de 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 Cloud NAT est 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 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 Cloud 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 Cloud NAT, GKE exécute la 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, Cloud NAT peut également être utile 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, les paquets envoyés à partir de pods dans un cluster non privé peuvent être traités par une passerelle Cloud NAT si les deux conditions suivantes sont remplies :

  • Pour les clusters de VPC natif, la passerelle Cloud 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.

Interaction avec Cloud Load Balancing

Les équilibreurs de charge externes Google Cloud et les 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 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.

Examples

Les exemples suivants illustrent les concepts de Cloud NAT.

Configuration NAT de base

Cloud NAT (cliquer pour agrandir)
Cloud NAT (cliquez pour agrandir)

Dans cet exemple :

  • La passerelle nat-gw-us-east est configurée pour s'appliquer à la plage d'adresses IP principale de subnet-1 dans la région us-east1. Une VM dont l'interface réseau ne possède pas d'adresse IP externe peut envoyer du trafic vers Internet en utilisant son adresse IP interne principale ou une plage d'adresses IP d'alias appartenant à la plage d'adresses IP principale de subnet-1, 10.240.0.0/16.

  • Une VM dont l'interface réseau ne possède pas d'adresse IP externe et dont l'adresse IP interne principale est située dans subnet-2 ne peut pas accéder à Internet, car aucune passerelle Cloud NAT n'est appliquée à aucune plage d'adresses IP de ce sous-réseau.

  • La passerelle nat-gw-eu est configurée pour s'appliquer à la plage d'adresses IP principale de subnet-3 dans la région europe-west1. Une VM dont l'interface réseau ne possède pas d'adresse IP externe peut envoyer du trafic vers Internet en utilisant son adresse IP interne principale ou une plage d'adresses IP d'alias appartenant à la plage d'adresses IP principale de subnet-3, 192.168.1.0/24.

Exemple avec GKE

Cloud NAT avec GKE (cliquez pour agrandir)
Cloud NAT avec GKE (cliquez pour agrandir)

Dans cet exemple, vous souhaitez appliquer la 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 du sous-réseau 1 comme candidats NAT. Il n'est pas possible d'activer la fonctionnalité NAT uniquement pour container1 ou container2.

Étapes suivantes