Présentation de Cloud NAT

Cloud NAT (traduction d'adresses réseau) permet aux instances de machines virtuelles (VM) Google Cloud sans adresse IP externe et aux clusters privés Google Kubernetes Engine d'envoyer des paquets sortants vers Internet et de recevoir les paquets de réponses entrants correspondants.

Architecture

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

NAT traditionnel et Cloud NAT (cliquez pour agrandir)
NAT traditionnel et Cloud NAT (cliquez pour agrandir)

Cloud NAT met en œuvre la NAT sortante avec des routes statiques dans votre 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 des connexions entrantes non sollicitées à partir 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 pour 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 configurez une passerelle Cloud NAT à l'aide de l'attribution manuelle d'adresses IP NAT, vous pouvez partager en toute confiance un ensemble d'adresses IP sources courantes avec une 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, 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 adapter automatiquement le nombre d'adresses IP NAT utilisées, et accepte les VM appartenant aux groupes d'instances gérés, y compris ceux avec autoscaling activé.

  • Performances : Cloud NAT ne réduit pas la bande passante réseau par VM. Cloud NAT fonctionne directement avec le réseau défini par logiciel Andromeda de Google.

Spécifications

  • Cloud NAT peut être configuré pour fournir une NAT à Internet pour les paquets envoyés depuis :

    • Les adresses IP internes principales de l'interface réseau de la VM, si aucune adresse IP externe n'est affectée à l'interface réseau. Si une adresse IP externe est attribuée à l'interface réseau, Google Cloud exécute automatiquement la NAT de type "un à un" pour les paquets dont les sources correspondent à l'adresse IP interne principale, car l'interface réseau respecte les 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 attribuée à l'interface réseau de la VM. Même si l'adresse IP externe est affectée à l'interface réseau, vous pouvez configurer une passerelle Cloud NAT pour les paquets dont les sources proviennent 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.

  • Cloud NAT autorise les réponses sortantes et les réponses entrantes établies à ces connexions. Chaque passerelle Cloud NAT effectue une traduction d'adresse réseau source (SNAT) en sortie et une traduction d'adresse réseau de destination (DNAT) 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 les documents RFC applicables.

  • Chaque passerelle Cloud NAT est associée à un seul réseau VPC, une seule région et un seul routeur Cloud. La passerelle Cloud NAT et le routeur cloud 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 à travers la passerelle Cloud NAT ou le routeur cloud.

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 en savoir plus, consultez la section Interactions 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, tant qu'aucune adresse IP externe n'est affectée à cette interface réseau. 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 pour ce qui suit :

  • 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 et 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 dans 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 et dont les interfaces réseau utilisent un sous-réseau dans 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'adresse IP secondaires du sous-réseau des VM éligibles.

  • Plages d'adresses IP de sous-réseaux 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. Consultez la section Bande passante réseau dans la documentation de Compute Engine pour connaître les spécifications de bande passante, qui varient selon le type de machine.

VM avec plusieurs cartes d'interface réseau

Si vous configurez une VM avec plusieurs interfaces réseau, chaque interface doit se trouver sur 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.

  • L'interface d'une VM avec plusieurs cartes d'interface réseau peut avoir une adresse IP externe et ne peut donc pas bénéficier de Cloud NAT, alors qu'une autre de ses interfaces peut bénéficier de Cloud NAT si elle n'a pas d'adresse IP externe et si vous avez configuré une apsserelle Cloud NAT à appliquer à la plage d'adresses IP du sous-réseau.

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. Les VM pour lesquelles la NAT doit être fournie 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 peut être classé dans les catégories de NAT avec mappage indépendant du point de terminaison ou filtrage dépendant du point de terminaison selon le document RFC 5128, et dans la catégorie de NAT en cône à restriction de port selon le document RFC 3489.

Lorsqu'une passerelle Cloud NAT exécute la SNAT en sortie pour un paquet envoyé depuis une VM, elle peut réutiliser le même tuple d'adresse source et de port source une fois par destination unique (adresse IP de destination, port de destination et protocole). Une passerelle Cloud NAT n'effectue la DNAT que pour les paquets de réponse entrants dont l'adresse IP source et le port source correspondent à l'adresse IP de destination et au port de destination du paquet de requête sortant correspondant. 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.

NAT-T (NAT traversal)

Cloud NAT étant indépendant du point de terminaison, 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, document RFC 5389) permet la communication directe entre les VM protégées par la NAT après l'établissement d'un canal de communication.
  • TURN (Traversal Using Relays around NAT, document RFC 5766) permet la communication entre les VM protégées par la NAT via un serveur tiers disposant d'une adresse IP externe. Chaque VM se connecte à l'adresse IP externe du serveur, qui relaie ensuite la communication entre les deux VM. TURN est plus robuste, mais consomme plus de bande passante et de ressources.

Expiration de la NAT

Les passerelles Cloud NAT utilisent les délais d'expiration suivants :

Inactive Valeur par défaut de Cloud NAT Configurable
Délai d'inactivité du mappage UDP
RFC 4787 REQ-5
30 secondes Oui
Délai d'inactivité de la connexion TCP établie
RFC 5382 REQ-5
1 200 secondes (20 minutes) Oui
Délai d'inactivité de la connexion transitoire TCP
RFC 5382 REQ-5
30 secondes Oui
Délai d'inactivité du mappage ICMP
RFC 5508 REQ-2
30 secondes Oui
Délai avant de réutiliser un 5-tuple pour une nouvelle connexion TCP
(tuple d'adresse source et de port source avec l'adresse de destination, le port de destination et le protocole)
120 secondes (2 minutes) Non
Consultez la section Réutilisation du port source pour les connexions TCP pour en savoir plus.

Interaction avec les produits

Les sections suivantes répertorient les interactions importantes entre Cloud NAT et les autres produits Google Cloud.

Interaction avec les routes

Une passerelle Cloud NAT peut uniquement utiliser 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. Consultez la page Présentation des routes pour obtenir des informations générales importantes.

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 tout autre type de saut suivant pour la route statique personnalisée, les paquets avec des adresses IP de destination correspondant à la destination de la route sont envoyés au saut suivant au lieu de 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 de saut suivant requièrent elles-mêmes des adresses IP externes. Ainsi, ni le trafic provenant des VM qui dépendent des VM de saut suivant, ni les VM de saut suivant elles-mêmes ne peuvent utiliser Cloud NAT.

  • Si vous créez une route statique personnalisée dont le saut suivant correspond à un tunnel Cloud VPN, Cloud NAT ne l'utilise pas. Par exemple, une route statique personnalisée avec la destination 0.0.0.0/0 et le 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 peuvent pas utiliser cette route. Cela est valable même pour des destinations plus spécifiques, telles que 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 qui gère un tunnel Cloud VPN ou un rattachement 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 avec la destination 0.0.0.0/0, le trafic vers la destination 0.0.0.0/0 sera dirigé vers le tunnel Cloud VPN ou le rattachement Cloud Interconnect (VLAN). Cela est valable même pour des destinations plus spécifiques, telles que 0.0.0.0/1 et 128.0.0.0/1.

Interaction avec l'accès privé à Google

Cloud 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 un sous-réseau lorsque vous configurez une passerelle Cloud NAT à appliquer à la plage d'adresses IP principale du sous-réseau. Tant que la passerelle fournit la NAT pour l'adresse IP principale d'un sous-réseau, Cloud NAT est activé 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 sou-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 elles appartiennent à la même région que la passerelle.

Interaction avec 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 le 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 sources et les ports sources à chaque VM de nœud. Ces adresses 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. Parce que la plage d'adresses IP de pod la plus petite possible est de 256 adresses IP (masque de sous-réseau /24), la procédure de réservation de port de Cloud NAT réserve au moins 1 024 adresses sources et ports sources par nœud. Pour plus d'informations sur les plages d'adresses IP des pods et les clusters VPC natifs, consultez la section Plage d'adresses IP secondaire du sous-réseau utilisée par les pods.

Indépendant 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 non privés, y compris les clusters VPC natifs et basés sur les routes. Les nœuds d'un cluster non privé ayant 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 :

  • pour les clusters natifs VPC, la passerelle Cloud NAT est configurée pour s'appliquer à la plage d'adresses IP secondaire pour les pods du cluster, et ;
  • 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 plus d'informations, consultez la page Présentation de Cloud Load Balancing et la page Présentation des vérifications d'état.

Exemples

Les exemples suivants illustrent les concepts de Cloud NAT.

Configuration NAT de base

Cloud NAT (cliquez pour agrandir)
Cloud NAT (cliquer 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 l'exemple ci-dessus, 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 du sous-réseau 1 comme candidats NAT. Il n'est pas possible de fournir la NAT uniquement pour les conteneurs 1 et 2.

Étape suivante