Interactions avec les produits Cloud NAT

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

Interaction avec les routes

A NAT public passerelle ne peut utiliser que des routes dont les prochains sauts sont passerelle Internet par défaut. Chaque réseau de cloud privé virtuel (VPC) commence par route dont la destination est 0.0.0.0/0 et dont le saut suivant est la route par défaut de votre passerelle Internet. Pour obtenir des informations générales importantes, consultez le présentation des routes.

Les exemples suivants illustrent les situations pouvant entraîner NAT public ces passerelles deviennent inopérantes:

  • Si vous créez une route statique avec les prochains sauts définis sur tout autre type de prochain saut de la route statique, puis les paquets dont les adresses IP de destination correspondent à la destination de la route sont envoyées vers ce saut suivant au lieu de la passerelle Internet par défaut. Par exemple, si Vous utilisez des instances de machines virtuelles (VM) exécutant une passerelle NAT, un pare-feu ou un proxy vous créez des routes statiques pour diriger le trafic vers ces VM le prochain saut. Les VM du saut suivant nécessitent des adresses IP externes. Ainsi, trafic provenant des VM qui dépendent des VM du saut suivant ou des VM du saut suivant ne peuvent pas utiliser NAT public de passerelle VPN haute disponibilité.

  • Si vous créez une route statique personnalisée dont le saut suivant est un Cloud VPN à l'aide d'un tunnel, NAT public n'utilise pas cette route. Par exemple, un route statique avec la destination 0.0.0.0/0 et un Cloud VPN 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 à destination ou Cloud Router, qui gère un tunnel Cloud VPN un rattachement de VLAN, NAT public ne 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 serait dirigé vers le tunnel Cloud VPN ou rattachement de VLAN. Ce comportement est valable 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, la NAT privée utilise des routes et routes dynamiques:
    • Pour le trafic entre deux spokes VPC associés un hub Network Connectivity Center qui ne contient que des spokes VPC, La NAT privée utilise les routes de sous-réseau échangées par les spokes VPC associés. Pour plus d'informations sur les spokes VPC, consultez Présentation des spokes VPC
    • Si un hub Network Connectivity Center contient les deux spokes VPC et les spokes hybrides, comme les rattachements de VLAN pour Cloud Interconnect, Les tunnels Cloud VPN, ou VM d'appareil de routeur, Le NAT privé utilise les routes dynamiques appris par les spokes hybrides via BGP (Preview) et les routes de sous-réseau échangées par les spokes VPC associés. Pour en savoir plus sur les environnements consultez la section Spokes hybrides.
  • Pour le NAT hybride (version Preview), le NAT privé utilise des routes dynamiques apprises par Cloud Router via Cloud Interconnect ou Cloud VPN.

Interaction avec l'accès privé à Google

A NAT public la passerelle n'effectue jamais de NAT pour le trafic envoyé les adresses IP externes pour les API Google Google Cloud. À la place, Google Cloud active automatiquement l'accès privé à Google pour une plage d'adresses IP de sous-réseau lorsque vous configurez NAT public passerelle principale à appliquer à cette plage de sous-réseaux, qu'il s'agisse d'une plage principale 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.

A NAT public ne modifie pas la manière dont l'accès privé à Google fonctionne. Pour en savoir plus, consultez 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. A La passerelle Cloud NAT créée dans un réseau VPC ne peut pas fournir une NAT aux VM d'autres réseaux VPC connectés par à l'aide de 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

A NAT public peut effectuer une NAT pour les nœuds et les pods d'une cluster privé, qui est un type de cluster de VPC natif. La NAT public passerelle 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 à l'ensemble d'un cluster privé consiste à configurer a NAT public à 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'un NAT public est configurée pour fournir la NAT à un réseau il 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 à chacun une plage d'adresses IP d'alias contenant plusieurs adresses IP (masque de réseau plus petit que /32).

  • Si l'allocation de ports statique est configuré, le service Public NAT procédure de réservation de port 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épendant de NAT public , Google Kubernetes Engine exécute le réseau traduction d'adresse (NAT ou SNAT source) à l'aide d'un logiciel s'exécutant sur chaque nœud lorsque les pods envoient des paquets vers Internet, à moins que vous n'ayez modifié le masquage d'adresse IP du cluster configuration. Si vous avez besoin un contrôle précis sur le trafic de sortie des pods, vous pouvez utiliser un réseau règle.

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, NAT public la passerelle configurés 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 d'un NAT public avec GKE:

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

Dans cet exemple, vous souhaitez que vos conteneurs soient traduits via la NAT. Pour activer le NAT pour tous les conteneurs et le nœud GKE, vous devez choisir Plages d'adresses IP de Subnet 1 en tant que 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 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 Fonctionnalité NAT pour les nœuds et les pods d'un cluster privé et d'un cluster non privé. La La passerelle NAT privée applique automatiquement à toutes les plages d'adresses IP du sous-réseau privé utilisé par votre cluster.

Interactions directes de sortie VPC

NAT public peuvent effectuer une NAT pour les services Cloud Run ou des jobs configurés avec 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 permettre à toutes les plages d'adresses IP de tous les sous-réseaux de la région d'utiliser le paramètre NAT public spécifiez la passerelle --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 NAT public spécifiez-les à l'aide du paramètre --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 du VPC direct peuvent utiliser NAT public de passerelle VPN haute disponibilité.
  • En cas d'allocation de ports statique, définissez la valeur de --min-ports-per-vm l'indicateur à quatre fois le nombre de ports requis par un seul Instance Cloud Run.
  • Dans le cas d'une attribution manuelle d'adresses IP NAT, attribuez un nombre approprié à vos adresses IP NAT public pour tenir compte du nombre d'instances Google Cloud et du nombre les instances Cloud Run déployées dans votre sur le réseau VPC du client.

en plus de la configuration de la passerelle, pour envoyer le trafic sortant d'une instance Cloud Run service ou tâche, 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 avec l'option --vpc-egress définie sur private-ranges-only, le service ou la tâche envoie le trafic uniquement vers les adresses IP internes. Vous n'avez pas besoin NAT public pour acheminer le trafic vers des destinations internes.

Pour empêcher les services Cloud Run ou les jobs définir l'option --vpc-egress sur private-ranges-only pour utiliser NAT public procédez comme suit:

  • Configurez les NAT public avec l'option --nat-custom-subnet-ip-ranges.
  • Définissez la valeur de l'option --nat-custom-subnet-ip-ranges sur les noms de sous-réseau où Vous avez déployé des services ou des jobs 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 NAT publiques :

  • Les métriques Cloud NAT des 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, révision ou job Cloud Run.

Vous ne pouvez pas utiliser de passerelles NAT privées avec une sortie VPC directe les points de terminaison.

Interactions des tests de connectivité

Vous pouvez utiliser des tests de connectivité pour vérifier la connectivité entre les réseaux 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 la trace d'analyse de la configuration. le volet de la page Détails du test de connectivité.

Interaction avec Cloud Load Balancing

Équilibreurs de charge d'application internes régionaux Google Cloud et d'équilibreurs de charge d'application externes régionaux communiquer avec plusieurs backends de groupes de points de terminaison du réseau Internet (NEG) régionaux. En configurant des passerelles Cloud NAT pour NEG Internet régional, vous pouvez allouer votre propre ensemble de plages d'adresses IP externes d'où doit provenir le trafic Google Cloud. Les rapports "Vérification de l'état" le trafic du plan de données provient 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 des VM à l'aide de chemins de routage spéciaux. VM de backend ne nécessitent pas d'adresses IP externes. De même, une passerelle Cloud NAT ne gère pas pour les équilibreurs de charge et les vérifications de l'é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