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é dispose d'une adresse IP externe. Chaque nœud peut donc utiliser des routes dans votre réseau VPC (Virtual Private Cloud) dont le prochain saut est la passerelle Internet par défaut sans s'appuyer sur Cloud NAT. Pour en savoir plus, y compris sur la façon dont les clusters non privés interagissent avec les passerelles Cloud NAT, consultez la section Interaction avec Compute Engine.

  • Répertoriez les routes de votre réseau de cloud privé virtuel pour rechercher celles qui pourraient fournir une connectivité Internet via un saut suivant différent de la passerelle Internet par défaut. Par exemple :

    • Les routes statiques dont les sauts suivants correspondent à des VM, des équilibreurs de charge réseau passthrough internes ou des tunnels Cloud VPN peuvent indirectement fournir une connectivité Internet. Par exemple, les VM de saut suivant ou VM de backend pour un équilibreur de charge réseau passthrough interne peuvent avoir des adresses IP externes, ou un tunnel Cloud VPN peut se connecter à un réseau qui offre un accès Internet.

    • Les routes dynamiques apprises des réseaux sur site par les routeurs Cloud Router de votre réseau VPC peuvent se connecter à un réseau offrant 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 les configurer avec une valeur plus élevée pour tcp_syn_retries, ce qui donne au système plus de temps 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

  • 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

Si vous constatez une perte de paquets à partir de VM utilisant le NAT public et que le mappage indépendant des points de terminaison est activé, la perte de paquets peut être due à un conflit indépendant des points de terminaison. 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 :

Paquets reçus supprimés

Une passerelle Cloud NAT gère une table de suivi des connexions pour stocker les informations de connexion actives, ainsi que les mappages d'adresses IP et de ports (comment les adresses IP et les ports de la VM sont traduits en adresses IP et ports NAT). Une passerelle Cloud NAT supprime un paquet de données d'entrée si la table de suivi des connexions ne contient aucune entrée pour la connexion.

L'absence de l'entrée de connexion dans le tableau peut être due à l'une des raisons suivantes:

  • Une connexion TCP établie a expiré, car le délai d'inactivité de la connexion TCP établie a expiré en raison d'une inactivité.
  • Un point de terminaison externe ne parvient pas à établir une nouvelle connexion avant l'expiration du délai d'inactivité de la connexion TCP transitoire. Par exemple, une ressource Google Cloud lance 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 sondeur, tente de se connecter à une adresse IP et à un port NAT. Cloud NAT n'accepte pas les connexions entrantes non sollicitées. Les entrées de ce type de connexions ne figurent pas dans le tableau des connexions. Par conséquent, 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, les mappages NAT deviennent non valides et ces connexions sont immédiatement supprimées du tableau de suivi des connexions. Tout trafic de retour est alors abandonné.

Avant de résoudre les pertes de paquets d'entrée, vérifiez si elles ont un impact sur 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 les techniques suivantes pour résoudre le problème:

  • Utilisez des mécanismes de keepalive dans votre application afin que les connexions de longue durée puissent rester ouvertes plus longtemps.
  • Augmentez la valeur du délai d'inactivité de la connexion transitoire TCP afin que les points de terminaison externes qui reçoivent du trafic (initié par des 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 considérablement réduit la valeur par défaut.

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 :
Vous avez dépassé une limite stricte d'adresses IP NAT.

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.

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 connaître la procédure à suivre pour modifier les délais avant expiration NAT, consultez la section Modifier les délais avant expiration 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 les sections Spécifications de Cloud NAT et Interaction avec Compute Engine.

Le NAT public permet-il à une VM source, dont l'interface réseau ne possède pas d'adresse IP externe, d'envoyer du trafic vers une VM de destination ou un équilibreur de charge disposant d'une adresse IP externe, même si 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, le NAT public effectue la traduction NAT source (SNAT) avant de distribuer le paquet à la deuxième instance. Le NAT public effectue une traduction NAT de destination pour les réponses émises par la seconde instance à destination de la première. Pour obtenir un exemple détaillé, consultez la section Configuration et workflow de base du 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 réseau VPC.

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, la périphérie réseau de Google Cloud peut répondre aux pings si l'adresse IP de destination est une adresse IP externe de passerelle Cloud NAT qui dispose de mappages de port actifs pour au moins une instance de VM. Pour afficher les adresses IP attribuées à une passerelle Cloud NAT, utilisez la 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 dépourvue d'adresse IP externe, consultez la section Choisir une option de connexion pour les VM internes uniquement. Par exemple, dans le cadre de l'exemple de configuration Compute Engine de Cloud NAT, 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