Résoudre les problèmes de configuration

Ce guide vous aide à résoudre les problèmes courants liés à Cloud NAT.

Problèmes courants

Les machines virtuelles peuvent accéder à Internet de façon inattendue, sans Cloud NAT.

Si vos instances de machine virtuelle (VM) ou vos instances de conteneur peuvent accéder à Internet sans Cloud NAT, mais que vous ne le souhaitez pas, vérifiez les points suivants :

• Déterminez si l'interface réseau de la VM dispose d'une adresse IP externe. Si une adresse IP externe est attribuée à l'interface réseau, Google Cloud exécute automatiquement une NAT de type "un à un" pour les paquets dont les sources correspondent à l'adresse IP interne principale de l'interface. Pour en savoir plus, consultez la section Spécifications de Cloud NAT.

  Pour vérifier si une VM possède une adresse IP externe, consultez la section Modifier ou attribuer une adresse IP externe à une instance existante.

• Assurez-vous que votre cluster Google Kubernetes Engine (GKE) est un cluster privé. Chaque VM de nœud dans un cluster non privé possède une adresse IP externe, de sorte que chaque nœud peut utiliser les routes de votre réseau cloud privé virtuel (VPC) dont le saut suivant est défini par défaut passerelle Internet sans utiliser Cloud NAT. Pour plus d'informations, y compris sur la façon dont les clusters non privés interagissent avec sur les passerelles Cloud NAT, consultez Interaction avec Compute Engine

• Répertoriez les routes dans votre cloud privé virtuel à la recherche d'un réseau capable de fournir une connectivité Internet via un prochain saut différent de la passerelle Internet par défaut. Par exemple :

  • Les routes statiques dont sauts sont des VM, des équilibreurs de charge réseau passthrough internes ou Cloud VPN peuvent fournir indirectement une connectivité Internet. Par exemple, les VM de saut suivant ou les VM de backend d'un équilibreur de charge réseau passthrough interne peuvent ont eux-mêmes des adresses IP externes, ou un tunnel Cloud VPN peut se connecter à un réseau qui offre un accès à Internet.

  • Les routes dynamiques tirées de réseaux sur site par Cloud Router dans votre VPC réseau peut se connecter à un réseau qui offre un accès à Internet.

• Gardez à l'esprit que les autres routes personnalisées de votre réseau VPC peuvent avoir des priorités supérieures à celles des routes dont les sauts suivants correspondent à des passerelles Internet par défaut. Pour plus d'informations sur la manière dont Google Cloud évalue les routes, consultez la section Applicabilité et ordre de routage.

Aucun journal n'est généré

• Vérifiez que la journalisation NAT est activée.

• Vérifiez que la vue des journaux ne filtre pas les journaux que vous recherchez. Pour obtenir des instructions, consultez la page Afficher des journaux.

• Assurez-vous que le trafic n'est pas bloqué par une règle de pare-feu. Les règles de pare-feu qui bloquent le trafic de sortie sont appliquées avant que le trafic n'ait été envoyé à la passerelle NAT. Vous pouvez utiliser la journalisation des règles de pare-feu pour vérifier si vos règles de sortie personnalisées bloquent le trafic sortant.

• Consultez la section Types de Cloud NAT. La destination de votre trafic peut ne pas être gérée par la NAT.

Certains journaux sont exclus

• Vérifiez que la journalisation NAT est activée et que votre filtre de journal n'exclut pas les journaux que vous souhaitez conserver. Vous pouvez effacer un filtre de journaux pour éviter toute exclusion.

• Cloud NAT ne journalise pas chaque événement. Pendant les périodes de trafic sortant important, la journalisation NAT est limitée de manière proportionnelle au type de machine de la VM. Les journaux de traduction ou d'erreur peuvent être omis et il est alors impossible de déterminer les éléments omis lors de la limitation.

Paquets supprimés avec le motif "ressources épuisées"

Si vous constatez une perte de paquets à partir de VM qui utilisent Cloud NAT, cela peut être dû au fait que le nombre de tuples de port source et d'adresse IP source NAT disponibles n'est pas suffisant pour permettre à la VM de l'utiliser au moment de la perte de paquets (épuisement de port). Vous ne pouvez pas réutiliser un 5-tuple (adresse IP source NAT, port source et 3-tuple de destination) dans le délai d'inactivité TCP TIME_WAIT.

Si le nombre de tuples NAT disponibles n'est pas suffisant, le motif dropped_sent_packets_count est OUT_OF_RESOURCES. Pour plus d'informations sur les métriques, consultez la page Utiliser des métriques d'instance de VM.

Consultez la section Réduire votre utilisation des ports pour savoir comment réduire l'utilisation des ports.

Si vous utilisez l'allocation dynamique de ports, consultez la section suivante pour savoir comment réduire les suppressions de paquets lorsque l'allocation dynamique de ports est utilisée.

Paquets supprimés lorsque l'allocation dynamique de ports est configurée

L'allocation dynamique de ports détecte lorsqu'une VM est sur le point de manquer de ports et double le nombre de ports qui lui sont alloués. Cela permet de s'assurer que les ports ne sont pas perdus, mais peut entraîner une perte de paquets pendant que le nombre de ports alloués augmente.

Pour réduire le nombre de paquets supprimés, tenez compte des points suivants :

• Si vous pouvez augmenter progressivement les connexions, Cloud NAT dispose de plus de temps pour allouer davantage de ports.

• Si les VM établissent des connexions TCP, vous pouvez configurer les VM avec un débit plus important de tcp_syn_retries, ce qui laisse plus de temps au système pour établir la connexion et augmente les chances de réussite de la connexion.

  Par exemple, pour les VM Linux, vous pouvez afficher le paramètre actuel :

    sysctl net.ipv4.tcp_syn_retries
    

  Si nécessaire, vous pouvez augmenter ce paramètre :

    sudo sysctl -w net.ipv4.tcp_syn_retries=NUM
    

  Remarque :L'augmentation de la valeur de tcp_syn_retries peut entraîner une latence. car le système abandonne les paquets jusqu'à ce que la connexion réussisse après plusieurs tentatives.

• Si vous avez des charges de travail intensives et que vous devez allouer rapidement plus de ports, vous devrez peut-être ajuster le nombre minimal de ports par VM. Affichez l'utilisation des ports et déterminez le nombre minimal de ports approprié par VM.

Paquets supprimés avec un motif: conflit indépendant du point de terminaison

Remarque :Cette section ne s'applique pas au NAT privé.

Si vous constatez une perte de paquets pour des VM qui utilisent le NAT public et que vous avez Mappage indépendant du point de terminaison activé, la perte de paquets peut être due à indépendant des points de terminaison conflit. Si c'est le cas, le motif de dropped_sent_packets_count est ENDPOINT_INDEPENDENT_CONFLICT. Pour plus d'informations sur les métriques, consultez la page Utiliser des métriques d'instance de VM.

Vous pouvez réduire les risques de conflits indépendants des points de terminaison à l'aide des techniques suivantes :

• Désactivez le mappage indépendant du point de terminaison. Cela permet à la nouvelle connexion provenant d'une adresse IP et d'un port sources donnés d'utiliser une adresse IP NAT et un port sources différents de ceux utilisés précédemment. La désactivation ou l'activation du mappage indépendant des points de terminaison n'interrompt pas les connexions établies.

• Augmentez le nombre minimal de ports NAT par défaut par instance de VM afin que la procédure de réservation de port puisse attribuer plus de tuples de port source et d'adresses IP sources NAT sur chaque VM cliente. Cela réduit la probabilité qu'au moins deux tuples d'adresse IP cliente et de port source éphémères soient attribués au même tuple d'adresse IP source et de port source NAT à la fois.

• Vérifiez le nombre de ports sources éphémères utilisés :

  • Pour les VM Linux:

    netstat -an | egrep 'ESTABLISHED|TIME_WAIT|CLOSE_WAIT' | wc -l
    

  • Pour les VM Windows:

    netstat -tan | findstr "ESTABLISHED TIME_WAIT CLOSE_WAIT" | find /c /v ""
    

• Configurez vos instances de VM pour qu'elles utilisent davantage de ports sources éphémères :

  • Pour les VM Linux:

    • Vous pouvez afficher la plage de ports configurée avec cette commande:

      cat /proc/sys/net/ipv4/ip_local_port_range
      

    • Vous pouvez définir ip_local_port_range sur le nombre maximal de ports sources éphémères (64 512) à l'aide de la commande suivante:

      echo 1024 65535 > /proc/sys/net/ipv4/ip_local_port_range
      

  • Pour les VM Windows:

    • Vous pouvez afficher les plages de ports configurées avec les commandes suivantes:

      netsh int ipv4 show dynamicport tcp
      netsh int ipv4 show dynamicport udp
      

    • Vous pouvez définir le nombre de ports TCP et UDP sources éphémères au maximum (64 512) à l'aide des commandes suivantes:

      netsh int ipv4 set dynamicport tcp start=1024 num=64512
      netsh int ipv4 set dynamicport udp start=1024 num=64512
      

    • Sur les nœuds Google Kubernetes Engine, vous pouvez automatiser cette configuration en utilisant un DaemonSet privilégié.

• Pour les clusters GKE, désactivez la NAT source mise en place sur chaque nœud pour les paquets envoyés vers les destinations d'intérêt. Pour effectuer cette opération, procédez de l'une des manières suivantes :

  • En déployant ip-masq-agent et en ajoutant les destinations d'intérêt à la liste nonMasqueradeCIDRs.

  • En désactivant la SNAT pour les destinations non masquées par défaut avec l'option --disable-default-snat lors de la création d'un cluster.

Paquets reçus supprimés

Une passerelle Cloud NAT possède une table de suivi des connexions pour stocker les données détails de connexion et mappages d'adresses IP et de ports (comment les adresses IP et les ports des VM) en adresses IP NAT et en ports. Une passerelle Cloud NAT supprime une couche d'entrée paquet de données si la table de suivi des connexions ne contient aucune entrée pour la connexion.

L'absence d'une entrée de connexion dans la table peut être due à l'un des problèmes suivants : raisons:

• Une connexion TCP établie a expiré car la connexion TCP établie Le délai d'inactivité a expiré pour cause d'inactivité.
• Un point de terminaison externe ne parvient pas à établir une nouvelle connexion avant le protocole TCP transitory Le délai d'inactivité de la connexion a expiré. Par exemple, une ressource Google Cloud établit une connexion avec TCP SYN, mais le point de terminaison externe ne répond pas avec un SYN ACK.
• Un point de terminaison externe, tel qu'un vérificateur, tente de se connecter à une adresse IP NAT et le port. Cloud NAT n'accepte pas les connexions entrantes non sollicitées. Les entrées pour ce type de connexion ne seront pas présentes dans la table des connexions. Ainsi, tous les paquets reçus seront supprimés.
• Si vous supprimez des adresses IP NAT de votre passerelle alors que les connexions NAT sont toujours actives, alors les mappages NAT ne sont plus valides, et ces connexions sont immédiatement du tableau de suivi des connexions : tout trafic de retour est supprimé.

Avant de traiter les pertes de paquets d'entrée, vérifiez si elles ont un impact réel votre application. Pour confirmer, recherchez des erreurs dans votre application chaque fois qu'il y a des pics de paquets d'entrée perdus.

Si les pertes de paquets d'entrée ont un impact sur votre application, essayez d'utiliser techniques pour résoudre le problème:

• Utilisez des mécanismes keepalive dans votre application, afin que les connexions de longue durée peuvent rester ouverts plus longtemps.
• Augmentez la valeur du délai d'inactivité de la connexion TCP transitoire, de sorte que points de terminaison externes qui reçoivent du trafic (initiés par les ressources Google Cloud) via une passerelle Cloud NAT disposent de plus de temps pour répondre et établir la connexion.
• Augmentez la valeur du délai d'inactivité de la connexion TCP établie si vous avez a fortement diminué la valeur par défaut.

Remarque: Augmenter la valeur du délai d'inactivité de la connexion transitoire TCP et du paramètre TCP Le délai d'inactivité de connexion établi a un impact sur la façon dont une instance Cloud NAT réutilise . La passerelle conserve un port mappé à la connexion pour une durée plus longue, même si la connexion échoue ou ne reçoit pendant un certain temps.

Vous devez allouer plus d'adresses IP

Parfois, vos VM ne peuvent pas accéder à Internet, car vous ne disposez pas d'adresses IP NAT suffisantes. Plusieurs facteurs peuvent être à l'origine de ce problème. Pour en savoir plus, reportez-vous au tableau suivant.

Origine du problème	Symptôme	Solution
Vous avez attribué manuellement des adresses, mais en nombre insuffisant par rapport à votre utilisation actuelle des ports.	Google Cloud Console affiche l'erreur Vous devez allouer au moins X adresses IP de plus pour permettre à toutes les instances d'accéder à Internet. La valeur de la métrique nat_allocation_failed est true.	Effectuez l'une des opérations suivantes : Réduisez votre utilisation des ports, comme décrit dans la section Réduire votre utilisation des ports. Ajoutez manuellement d'autres adresses IP, comme décrit dans la section Modifier les adresses IP externes associées à la NAT.
Vous avez dépassé une limite stricte d'adresses IP NAT.	La valeur de la métrique nat_allocation_failed est true.	Réduisez votre utilisation des ports, comme décrit dans la section Réduire votre utilisation des ports.

Pour surveiller les échecs causés par un nombre insuffisant d'adresses IP, créez une alerte pour la métrique nat_allocation_failed. Cette métrique est définie sur true si Google Cloud ne peut pas allouer suffisamment d'adresses IP à des VM sur votre passerelle NAT. Pour en savoir plus sur les règles d'alerte, consultez la page Définir des règles d'alerte.

Réduire votre utilisation des ports

Vous pouvez réduire le nombre de ports utilisés par chaque VM dans les situations où l'allocation d'autres adresses IP NAT n'est pas possible ou souhaitable.

Important :Si vous avez besoin d'un mappage indépendant des points de terminaison, les recommandations de ce ne s'appliquent pas. Vous devez augmenter le nombre d'adresses IP NAT disponibles et les tuples de port configurés sur la passerelle NAT, ou qui utilisent plusieurs passerelles NAT.

Avertissement :Les connexions établies peuvent être interrompues si vous activez ou désactivez dynamique, ou si vous réduisez le nombre minimal de ports par VM. Pour en savoir plus, consultez la section Changer de méthode d'allocation de ports. et Réduisez le nombre de ports par VM.

Pour réduire l'utilisation des ports, procédez comme suit :

1. Désactivez le mappage indépendant du point de terminaison.

2. Activez l'allocation de ports dynamique. Pour utiliser l'allocation dynamique de ports, vous définissez un nombre minimal de ports par VM et un nombre maximal de ports par VM. Cloud NAT alloue automatiquement un certain nombre de tuples d'adresses IP NAT sources et de ports sources, compris dans cette limite entre le nombre minimal et maximal de ports (inclus). L'utilisation d'un nombre faible pour le nombre minimal de ports réduit le gaspillage des tuples d'adresses IP sources et de ports sources sur les VM ayant moins de connexions actives. Si vous rencontrez des délais avant expiration de la connexion lors de l'allocation des ports, consultez la section Réduire les suppressions de paquets avec l'allocation dynamique de ports.

3. Déterminez le nombre minimal de ports le plus bas possible pour répondre à vos besoins. Il existe plusieurs méthodes pour y parvenir, et la plupart reposent sur l'examen du nombre de ports utilisés (compute.googleapis.com/nat/port_usage) en tant qu'entrée dans le processus décisionnel. Pour savoir comment trouver ces informations, consultez la section Afficher l'utilisation des ports. Voici deux exemples de méthodes permettant de déterminer un nombre minimal de ports :

   • Considérez la valeur moyenne de compute.googleapis.com/nat/port_usage sur une période représentative pour un nombre représentatif de VM.
   • Considérez la valeur la plus fréquente de compute.googleapis.com/nat/port_usage sur une période représentative pour un nombre représentatif de VM.

4. Déterminez le nombre maximal de ports le plus bas possible pour répondre à vos besoins. Une fois de plus, examinez compute.googleapis.com/nat/port_usage en tant qu'entrée dans votre processus décisionnel. Considérez la valeur maximale de compute.googleapis.com/nat/port_usage sur une période représentative pour un nombre représentatif de VM comme point de départ pour le nombre maximal de ports. Gardez à l'esprit que la définition d'un nombre maximal trop élevé peut empêcher les autres VM de recevoir les tuples d'adresses IP NAT sources et de ports sources.

5. Trouver les valeurs appropriées pour le nombre minimal et maximal de ports implique de réaliser des tests itératifs. Pour connaître les étapes permettant de modifier le nombre minimal et maximal de ports, consultez la section Modifier le nombre minimal ou maximal de ports lorsque l'allocation de ports dynamique est configurée.

6. Examinez les délais avant expiration NAT, leur signification et leurs valeurs par défaut. Si vous devez créer rapidement une série de connexions TCP au même 3-tuple de destination, envisagez de réduire le temps d'attente TCP afin que Cloud NAT puisse réutiliser plus rapidement les tuples d'adresses IP NAT sources et de ports sources. Cela permet à Cloud NAT d'utiliser plus rapidement le même 5-tuple au lieu d'utiliser un 5-tuple unique, ce qui peut nécessiter l'allocation de tuples d'adresses IP sources et de ports sources supplémentaires pour chaque VM émettrice. Pour savoir comment modifier les délais avant expiration NAT, consultez Modifier les délais avant expiration de la NAT

Questions fréquentes

Restriction régionale pour Cloud NAT

Puis-je utiliser la même passerelle Cloud NAT dans plusieurs régions ?

Non. Une passerelle Cloud NAT ne peut pas être associée à plus d'une région, un réseau VPC ou un routeur cloud.

Si vous devez fournir une connectivité pour d'autres régions ou réseaux VPC, créez des passerelles Cloud NAT supplémentaires.

Les adresses IP NAT externes sont-elles utilisées par les passerelles Cloud NAT à l'échelle mondiale ou régionale ?

Les passerelles Cloud NAT utilisent des adresses IP externes régionales comme adresses IP NAT. Même si elles sont régionales, elles peuvent être routées publiquement. Pour plus d'informations sur les différentes façons dont les adresses IP NAT peuvent être allouées ou attribuées, consultez la section Adresses IP NAT.

Cas dans lesquels Cloud NAT est utilisable et non utilisable

Cloud NAT s'applique-t-il aux instances, y compris aux VM de nœuds GKE, qui possèdent des adresses IP externes ?

Généralement, non. Si l'interface réseau d'une VM possède une adresse IP externe, Google Cloud effectue toujours une NAT de type "un à un" pour les paquets envoyés à partir de l'adresse IP interne principale de l'interface réseau, sans utiliser Cloud NAT. Toutefois, Cloud NAT peut toujours fournir des services NAT aux paquets envoyés à partir des plages d'adresses IP d'alias de la même interface réseau. Pour en savoir plus, consultez la page Cloud NAT spécifications et Compute Engine d'interaction.

La fonctionnalité Public NAT permet-elle à une VM source dont l'interface réseau n'a pas d'adresse IP externe d'envoyer du trafic vers une VM ou un équilibreur de charge de destination disposant d'une adresse IP externe, même lorsque la source et la destination se trouvent sur le même réseau VPC ?

Oui. Le chemin d'accès réseau implique d'envoyer le trafic hors du réseau VPC via une passerelle Internet par défaut, puis à le recevoir sur le même réseau.

Lorsque la VM source envoie un paquet à la destination, la fonctionnalité effectue la NAT source (SNAT) avant de transmettre le paquet à la deuxième instance. La NAT publique exécute la NAT de destination (DNAT) pour les réponses de la seconde à la première instance. Pour obtenir un exemple détaillé, consultez Configuration et workflow de base de la fonctionnalité NAT public.

Puis-je utiliser Private NAT pour la communication entre les VM d'un même réseau VPC ?

Non, Private NAT n'effectue pas de NAT sur le trafic entre les VM d'un même sur le réseau VPC du client.

Les connexions entrantes non sollicitées ne sont pas acceptées

Cloud NAT autorise-t-il les connexions entrantes (par exemple, SSH) vers des instances sans adresse IP externe ?

Non, Cloud NAT n'accepte pas les connexions entrantes non sollicitées. Pour en savoir plus, consultez la section Spécifications de Cloud NAT. Toutefois, le réseau périphérique de Google Cloud peut répondre aux pings si l'adresse IP de destination est une adresse IP externe de passerelle Cloud NAT dispose de mappages de ports actifs vers au moins une instance de VM. Afficher les adresses IP attribuée à une passerelle Cloud NAT, utilisez Commande gcloud compute routers get-nat-ip-info Les adresses IP externes marquées comme IN_USE peuvent répondre aux pings.

Si vous devez vous connecter à une VM qui ne possède pas d'adresse IP externe, consultez Choisissez une option de connexion pour les VM à usage interne uniquement. Par exemple, dans le cadre de l'exemple Cloud NAT Compute Engine configuration, vous vous connectez à une VM sans adresse IP externe à l'aide d'Identity-Aware Proxy.

Cloud NAT et ports

Pourquoi une VM possède-t-elle un nombre fixe de ports (64 par défaut) ?

Lorsqu'une passerelle Cloud NAT fournit une NAT à une VM, elle réserve les tuples d'adresse source et de port source conformément à la procédure de réservation de port.

Pour en savoir plus, consultez la section Exemples de réservations de port.

Puis-je modifier le nombre minimal de ports réservés pour une VM ?

Oui. Vous pouvez augmenter ou diminuer le nombre minimal de ports par VM lorsque vous créez une passerelle Cloud NAT ou en la modifiant ultérieurement. Chaque passerelle Cloud NAT réserve les tuples d'adresse source et de port source conformément à la procédure de réservation de port.

Pour en savoir plus sur la réduction du nombre minimal de ports, consultez la question suivante.

Puis-je diminuer le nombre minimal de ports par VM après la création de la passerelle Cloud NAT ?

Oui. Toutefois, si vous diminuez le nombre minimal de ports, la procédure de réservation de port peut conduire à une réduction du nombre de ports réservés par VM. Dans ce cas, les connexions TCP existantes peuvent être réinitialisées et doivent alors être rétablies.

Lorsque vous passez du mappage NAT des plages principale et secondaire à la plage principale uniquement, des ports supplémentaires alloués à chaque instance sont-ils immédiatement libérés ?

Non. Tous les ports supplémentaires utilisés par les plages secondaires sont conservés par les instances jusqu'à ce que le paramètre Nombre minimal de ports par VM soit réduit. Lorsque Cloud NAT est configuré pour mapper des plages secondaires (alias) pour les sous-réseaux, Cloud NAT attribue au minimum 1 024 ports par instance, en fonction de la procédure de réservation de port.

En basculant vers les plages principales uniquement, Cloud NAT conserve ces ports supplémentaires alloués pour les instances qui possèdent déjà ces ports. Une fois que vous avez modifié les plages pour lesquelles Cloud NAT est appliqué à la plage principale uniquement, le nombre réel de ports attribués à ces instances n'est modifié que lorsque le paramètre nombre minimal de ports par VM est également réduit.

Pour réduire le nombre de ports alloués à ces instances, après avoir basculé sur les plages principales, vous devez réduire le paramètre Nombre minimal de ports par VM. Une fois cette valeur réduite, Cloud NAT réduit automatiquement le nombre de ports alloués par instance, ce qui réduit la consommation de ports.

Cloud NAT et autres services Google

Cloud NAT permet-il d'accéder aux API et services Google ?

Lorsque vous activez Cloud NAT pour la plage d'adresses IP principale d'un sous-réseau, Google Cloud active automatiquement l'accès privé à Google. Pour plus d'informations, consultez la section Interaction avec l'accès privé à Google.

Étape suivante

• Obtenir de l'aide