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 VM 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 Cloudeffectue automatiquement une opération 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 Spécifications de Cloud NAT.

    Pour déterminer si une VM possède une adresse IP externe, consultez Modifier ou attribuer une adresse IP externe à une instance existante.

  • Vérifiez que votre cluster Google Kubernetes Engine (GKE) est un cluster privé. Chaque VM de nœud d'un cluster non privé possède une adresse IP externe. Chaque nœud peut donc utiliser des routes de votre réseau VPC (cloud privé virtuel) dont le saut suivant est la passerelle Internet par défaut sans avoir à faire appel à Cloud NAT. Pour en savoir plus, y compris sur la manière dont les clusters non privés interagissent avec les passerelles Cloud NAT, consultez Interaction avec Compute Engine.

  • Listez 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 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 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 savoir commentGoogle Cloud évalue les routes, consultez 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 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.

  • Examinez les types de Cloud NAT. La destination de votre trafic peut ne pas être gérée par le NAT.

Certains journaux sont exclus

  • Vérifiez que la journalisation NAT est activée et que votre filtre de journaux 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 où le trafic sortant est conséquent, la journalisation NAT est limitée proportionnellement 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 au niveau de VM qui utilisent Cloud NAT, cela peut être dû au fait que le nombre de tuples Adresse IP source/Port source NAT disponibles pour utilisation par la VM n'est pas suffisant au moment où se produit 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 Utiliser des métriques d'instance de VM.

Consultez 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 garantit que les ports ne sont pas gaspillés, mais une perte de paquets peut survenir 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 le nombre de 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 succès des connexions.

    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 la valeur de 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 par VM approprié.

Paquets supprimés avec le motif "conflit indépendant du point de terminaison"

Si vous constatez une perte de paquets au niveau de VM utilisant Public NAT et que le mappage indépendant du point de terminaison est activé, la perte de paquets peut être due à un conflit indépendant du point de terminaison. Si c'est le cas, le motif de dropped_sent_packets_count est ENDPOINT_INDEPENDENCE_CONFLICT. Pour plus d'informations sur les métriques, consultez Utiliser des métriques d'instance de VM.

Vous pouvez réduire les risques de conflit indépendant du point 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 et un port sources NAT différents de ceux utilisés précédemment. La désactivation ou l'activation du mappage indépendant du point 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 Adresse IP source/Port source NAT à chaque VM cliente. Cela réduit la probabilité que deux ou plusieurs tuples Adresse IP cliente/Port source éphémère soient attribués au même tuple Adresse IP source/Port source NAT.

  • 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 sur la valeur maximale (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 le NAT source mis en place sur chaque nœud pour les paquets envoyés vers les destinations d'intérêt. Pour ce faire, vous disposez de deux options :

Paquets reçus supprimés

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

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

  • Une connexion TCP établie a expiré : le délai d'inactivité de la connexion TCP établie a expiré pour cause d'inactivité.
  • Un point de terminaison externe n'a pas réussi à établir une nouvelle connexion avant l'expiration du délai d'inactivité de la connexion TCP transitoire. Par exemple, une ressource Google Cloud établit une connexion avec TCP SYN, mais le point de terminaison externe ne répond pas par un SYN ACK.
  • Un point de terminaison externe, tel qu'un outil de vérification, tente de se connecter à une adresse IP et à un port NAT. Cloud NAT n'accepte pas les connexions entrantes non sollicitées. Aucune entrée pour de tels types de connexions ne sera présente dans la table des connexions. Tous les paquets reçus seront donc supprimés.
  • Si vous supprimez des adresses IP NAT de votre passerelle alors que des connexions NAT sont toujours actives, les mappages NAT deviennent invalides et ces connexions sont immédiatement retirées de la table de suivi des connexions. Tout trafic de retour est alors abandonné.

Avant de résoudre les problèmes de perte de paquets entrants, vérifiez si ces pertes ont un impact sur votre application. Pour le confirmer, vérifiez si votre application présente des erreurs chaque fois que des pics d'abandons de paquets entrants se produisent.

Si les pertes de paquets entrants ont un impact sur votre application, essayez les techniques suivantes pour résoudre le problème :

  • Utilisez des mécanismes de type keepalive (maintien en vie) dans votre application pour que les connexions de longue durée puissent rester ouvertes plus longtemps.
  • Augmentez la valeur du délai d'inactivité des connexions TCP transitoires afin que les points de terminaison externes qui reçoivent du trafic (initié 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é des connexions TCP établies si vous avez considérablement diminué la valeur par défaut.

Nécessité d'allouer plus d'adresses IP

Parfois, vos VM ne peuvent pas accéder à Internet, car vous ne disposez pas d'un nombre suffisant d'adresses IP NAT. Plusieurs facteurs peuvent être à l'origine de ce problème. Pour en savoir plus, consultez le tableau ci-dessous.

Origine du problème Problème constaté Solution
Vous avez attribué des adresses manuellement, mais en nombre insuffisant par rapport à votre utilisation actuelle des ports.
  • La console Google Cloud affiche l'erreur Vous devez allouer au moins X adresses IP supplémentaires 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 pour le nombre d'adresses IP NAT.

Pour surveiller les échecs imputables à 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 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 ni 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 de ports dynamique, 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 Adresses IP source/Port source NAT (compris entre les nombres minimal et maximal de ports (tous deux inclus)). L'utilisation d'un nombre bas pour le nombre minimal de ports réduit le gaspillage des tuples Adresses IP source/Port source NAT sur les VM ayant moins de connexions actives. Si vous constatez des délais d'inactivité de la connexion lors de l'allocation des ports, consultez Réduire les suppressions de paquets avec l'allocation de ports dynamique.

  3. Déterminez le nombre minimal de ports le plus bas possible permettant de 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 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 permettant de répondre à vos besoins. Une fois de plus, examinez compute.googleapis.com/nat/port_usage en tant qu'entrée de 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 des tuples Adresse IP source/Port source NAT.

  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 les nombres minimal et maximal de ports, consultez Modifier le nombre minimal ou maximal de ports lorsque l'allocation de ports dynamique est configurée.

  6. Examinez les délais d'inactivité 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 Adresse IP source/Port source NAT. Cela permet à Cloud NAT de pouvoir utiliser plus rapidement le même 5-tuple au lieu de devoir utiliser un 5-tuple unique, ce qui peut nécessiter l'allocation de tuples Adresse IP source/Port source NAT supplémentaires pour chaque VM émettrice. Pour connaître les étapes permettant de modifier les délais d'inactivité NAT, consultez Modifier les délais d'inactivité 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, d'un réseau VPC ou d'un routeur Cloud Router.

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 utilisées par les passerelles Cloud NAT sont-elles mondiales ou régionales ?

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 Adresses IP NAT.

Quand utiliser Cloud NAT et quand ne pas l'utiliser ?

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 opération 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 pour les paquets envoyés à partir des plages d'adresses IP d'alias de la même interface réseau. Pour en savoir plus, consultez Spécifications de Cloud NAT et Interaction avec Compute Engine.

Cloud NAT 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 de le recevoir sur le même réseau.

Lorsque la VM source envoie un paquet à la destination, Public NAT effectue la traduction NAT source (SNAT) avant de distribuer le paquet à la deuxième instance. Public NAT effectue une traduction NAT de destination (DNAT) pour les réponses émises par la seconde instance à destination de la première. Pour obtenir un exemple détaillé, consultez Configuration et workflow de base de Public NAT.

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 Spécifications de Cloud NAT. Toutefois, la périphérie du réseau de Google Cloudpeut répondre aux pings si l'adresse IP de destination est une adresse IP externe de passerelle Cloud NAT qui offre des mappages de ports actifs vers 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 requêtes ping.

Si vous devez vous connecter à une VM dépourvue d'adresse IP externe, consultez Choisir une option de connexion pour les VM internes uniquement. Ainsi, avec 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 fonctionnalité NAT à une VM, elle réserve les tuples Adresse source/Port source conformément à la procédure de réservation de port.

Pour en savoir plus, consultez 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 modifier cette valeur ultérieurement. Chaque passerelle Cloud NAT réserve les tuples Adresse source/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 qui suit.

Puis-je diminuer le nombre minimal de ports par VM après avoir créé 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, les 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, selon 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 auxquelles ces ports sont déjà attribués. Quand vous modifiez 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, quand vous avez basculé sur les plages principales, vous devez réduire la valeur du 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 Interaction avec l'accès privé à Google.

Étape suivante