Les tests de connectivité peuvent abandonner un paquet de test pour l'une des raisons suivantes.
Pour obtenir la liste complète des raisons possibles, consultez la section États d'analyse de la configuration.
Adresse IP étrangère non autorisée
Le paquet est abandonné, car une instance Compute Engine ne peut envoyer ni recevoir de paquets avec une adresse IP étrangère que si le transfert IP est activé.
Cause probable
Le transfert IP n'est pas activé sur l'instance de VM, mais l'adresse IP source ou de destination du paquet qui la traverse ne correspond pas aux adresses IP de l'instance. Cela peut se produire, par exemple, lorsque le paquet est transmis à l'instance à l'aide d'une route statique dont l'instance de VM est le saut suivant.
Recommandations
Créez une instance Compute Engine avec le transfert d'adresses IP activé ou définissez l'attribut correspondant pour l'instance existante. Pour en savoir plus, consultez la section Activer le transfert IP pour les instances.
Abandonné en raison d'une règle de pare-feu
Le paquet peut être supprimé en raison d'une règle de pare-feu, sauf si le paquet est autorisé en raison du suivi de connexion.
Cause probable
Les tests de connectivité peuvent refuser un paquet de test, car il correspond à une règle de pare-feu ou à une règle de stratégie de pare-feu bloquante. Cependant, le plan de données réel peut autoriser le paquet en raison du suivi de connexion sur le pare-feu. Le suivi des connexions permet aux paquets d'une connexion existante d'être renvoyés malgré la règle de pare-feu.
Chaque réseau VPC possède deux règles de pare-feu implicites qui autorisent le trafic de sortie vers n'importe quel emplacement et bloquent le trafic entrant depuis n'importe quel emplacement. Vous pouvez également avoir une règle de pare-feu de refus de sortie de priorité plus élevée.
Pour que la connectivité aboutisse, vous devez disposer d'une règle de pare-feu de sortie à la source qui autorise l'accès au point de terminaison de destination et d'une règle de pare-feu d'entrée à la destination qui autorise cette connexion.
Les règles de pare-feu VPC sont dites avec état. Si le point de terminaison de destination spécifié est normalement le côté à l'origine de la communication, le trafic de réponse est automatiquement autorisé avec le suivi des connexions, et il n'est pas nécessaire de définir une règle de pare-feu d'entrée.
Recommandations
Supprimez la règle de refus ou créez une règle d'autorisation en fonction des détails des résultats des tests de connectivité. Pour en savoir plus, consultez les pages Stratégies de pare-feu et Utiliser des règles de pare-feu VPC.
Abandonné en raison de l'absence de route correspondante
Le paquet est supprimé en raison de l'absence de routes correspondantes.
Cause probable
Aucune route active ne correspond aux attributs du paquet (comme une adresse IP de destination) dans le réseau et la région du paquet.
Recommandations
Vérifiez la liste des routes effectives dans la console Google Cloud. Si vous venez de créer un itinéraire, notez que cela peut prendre un certain temps pour que les tests de connectivité reçoivent une mise à jour de la configuration et l'intègrent à l'analyse.
Si vous essayez d'accéder au point de terminaison de destination à l'aide de son adresse IP interne, assurez-vous que les réseaux source et de destination sont connectés (par exemple, à l'aide de l'appairage de réseaux VPC, du Network Connectivity Center ou d'une solution de connectivité hybride telle que Cloud VPN).
Notez que l'appairage de réseaux VPC transitif n'est pas accepté. Envisagez de connecter les réseaux source et de destination directement ou à l'aide d'une solution de connectivité hybride.
Si vous essayez d'accéder au point de terminaison de destination via Internet, assurez-vous que vous disposez d'une route pour l'adresse IP de destination avec la passerelle Internet de saut suivant.
Si le paquet passe par le groupe de points de terminaison du réseau de connectivité hybride, tenez compte des exigences supplémentaires concernant l'applicabilité des routes. Il est possible que certaines routes affichées dans le tableau de la vue des routes ne soient pas disponibles pour le trafic provenant de NEG hybrides.
Pour en savoir plus, consultez les pages Routes et Utiliser des routes.
Le paquet est envoyé à un réseau incorrect
Le paquet est envoyé à un réseau non souhaité. Par exemple, vous exécutez un test à partir d'une instance Compute Engine sur le réseau network-1 vers l'instance Compute Engine sur le réseau network-2, mais le paquet est envoyé au réseau network-3.
Cause probable
Le réseau network-1 comporte une route avec une plage de destination qui inclut l'adresse IP de l'instance de destination avec le saut suivant dans un autre réseau (network-3 dans l'exemple ci-dessus).
Recommandations
Vérifiez la liste des routes effectives et la liste des routes applicables à l'instance source dans la console Google Cloud. Pour en savoir plus sur la création et l'applicabilité des routes, consultez les pages Routes et Utiliser des routes.
L'adresse IP du prochain saut de la route n'est pas résolue
Le paquet est envoyé à une destination à l'aide d'une route non valide, et l'adresse IP du prochain saut n'est attribuée à aucune ressource.
Cause probable
S'il s'agit d'une route avec next-hop-address, l'adresse de saut suivant doit être une adresse IPv4 interne principale ou une adresse IPv6 de l'instance Compute Engine dans le réseau VPC de la route. Les adresses des réseaux appairés ne sont pas prises en charge.
S'il s'agit d'une route avec next-hop-ilb, l'adresse du saut suivant doit être une adresse de l'équilibreur de charge réseau passthrough interne (les règles de transfert utilisées par d'autres équilibreurs de charge, le transfert de protocole ou les points de terminaison Private Service Connect ne sont pas acceptés). L'adresse IP doit être attribuée à une ressource sur le réseau VPC de la route ou sur un réseau qui y est connecté via l'appairage de réseaux VPC.
Recommandations
Vérifiez que l'adresse IP du saut suivant appartient à une ressource compatible. Pour en savoir plus, consultez les sections Considérations concernant les instances de saut suivant et Considérations concernant les sauts suivants des équilibreurs de charge réseau passthrough internes.
L'instance du prochain saut de la route comporte une carte d'interface réseau sur le mauvais réseau
Le paquet est envoyé à une destination à l'aide d'une route non valide, et l'instance Compute Engine du saut suivant ne dispose pas de contrôleur d'interface réseau (NIC) dans le réseau de la route.
Cause probable
L'instance Compute Engine utilisée comme saut suivant de route doit disposer d'une carte d'interface réseau sur le réseau de la route (et non dans un réseau VPC appairé).
Recommandations
Vérifiez que l'instance Compute Engine du prochain saut dispose d'une carte d'interface réseau sur le réseau de la route. Pour en savoir plus, consultez la section Considérations liées aux instances de prochain saut.
L'adresse de saut suivant de la route n'est pas une adresse IP principale de la VM
Le paquet est envoyé à une destination à l'aide d'une route non valide, dont l'adresse IP du prochain saut (next-hop-address) n'est pas une adresse IP principale de l'instance Compute Engine.
Cause probable
L'adresse IP du saut suivant de la route (next-hop-address) doit être une adresse IPv4 interne principale de l'instance Compute Engine.
Les plages d'adresses IP d'alias ne sont pas acceptées.
Recommandations
Vérifiez que l'adresse IP du prochain saut est une adresse IPv4 interne principale de l'instance Compute Engine. Pour en savoir plus, consultez la section Considérations liées aux instances de prochain saut.
Le type de règle de transfert du saut suivant de la route n'est pas valide
Le paquet est envoyé à une destination à l'aide d'une route non valide, et la règle de transfert du prochain saut (next-hop-ilb) n'est pas une règle de transfert de l'équilibreur de charge réseau passthrough interne.
Cause probable
La règle de transfert du saut suivant de la route doit être une règle de transfert de l'équilibreur de charge réseau passthrough interne. Pour en savoir plus, consultez la section Considérations liées aux équilibreurs de charge réseau passthrough internes utilisés en tant que prochain saut.
Recommandations
Créez une route ciblant une règle de transfert compatible au lieu de la route non valide.
Trafic privé vers Internet
Un paquet avec une adresse de destination interne a été envoyé à une passerelle Internet.
Cause probable
L'adresse IP de destination du paquet est une adresse IP privée, qui n'est pas accessible via Internet. Toutefois, le paquet quitte l'instance Compute Engine source et correspond à une route avec la passerelle Internet du saut suivant.
Recommandations
Si vous souhaitez accéder à la destination via Internet, assurez-vous que l'instance Compute Engine source dispose d'une connectivité Internet (par exemple, qu'elle dispose d'une adresse IP externe ou qu'elle utilise Cloud NAT) et utilisez l'adresse IP externe du point de terminaison de destination lors du test.
Si vous souhaitez accéder à la destination via son adresse IP interne, vous devez établir la connectivité (créer des routes) entre les réseaux source et de destination. Pour ce faire, procédez de l'une des façons suivantes:
- Si votre point de terminaison de destination se trouve dans un réseau sur site, utilisez une solution Network Connectivity Center ou une solution de connectivité hybride, telle que Cloud VPN ou Cloud Interconnect.
- Si votre point de terminaison de destination se trouve dans Google Cloud :
- Configurez l'appairage de réseaux VPC entre les réseaux VPC.
- Configurez Cloud VPN entre les réseaux VPC.
- Configurez la connectivité réseau à l'aide de spokes VPC Network Connectivity Center.
Si vous disposez déjà d'une connexion au réseau de destination :
- Le réseau de points de terminaison source n'a pas de route via cette connexion ou utilise la route par défaut qui passe par la passerelle Internet. Vérifiez la liste des routes effectives et la liste des routes applicables à l'instance source dans la console Google Cloud. Pour en savoir plus sur la création et l'applicabilité des routes, consultez les pages Routes et Utiliser des routes.
Si vous testez la connectivité à un réseau sur site à partir d'un réseau appairé, consultez cet exemple pour l'annonce personnalisée, le mode de routage réseau et l'échange de routes personnalisées.
L'appairage de réseaux VPC transitif n'est pas accepté. Vous pouvez utiliser le VPN ou l'appairage pour ces deux réseaux VPC.
L'accès privé à Google n'est pas autorisé
Une instance Compute Engine possédant uniquement une adresse IP interne tente d'atteindre l'adresse IP externe des API et services Google, mais l'accès privé à Google n'est pas activé dans le sous-réseau de l'instance.
Recommandations
Vous pouvez autoriser l'instance de VM Compute Engine à atteindre l'adresse IP externe des API et services Google de l'une des manières suivantes:
- Activez l'accès privé à Google pour le sous-réseau de l'instance.
- Attribuez une adresse IP externe à la carte réseau Compute Engine.
- Activez Cloud NAT pour le sous-réseau de l'instance de VM.
L'accès privé à Google via un tunnel VPN n'est pas pris en charge
Un point de terminaison source avec une adresse IP interne tente d'atteindre l'adresse IP externe des API et services Google via le tunnel VPN vers un autre réseau, mais l'accès privé à Google doit être activé dans le réseau du point de terminaison source.
Cause probable
Le paquet du point de terminaison source vers l'adresse IP externe des API et services Google est acheminé via le tunnel Cloud VPN, mais une telle configuration n'est pas prise en charge.
Recommandations
Si le point de terminaison source est un point de terminaison Google Cloud (comme une instance de VM Compute Engine), envisagez d'activer l'accès privé à Google dans son sous-réseau source.
Si le point de terminaison source est un point de terminaison sur site, consultez la section Accès privé à Google pour les hôtes sur site pour obtenir des instructions détaillées.
Incohérences au niveau des règles de transfert
Le protocole et les ports de la règle de transfert ne correspondent pas à l'en-tête du paquet.
Cause probable
Le paquet est envoyé à l'aide d'un protocole non compatible avec la règle de transfert ou à un port de destination qui ne correspond pas aux ports compatibles avec la règle de transfert.
Recommandations
Confirmez le protocole et les ports de la règle de transfert de destination.
La région de la règle de transfert ne correspond pas
L'accès mondial n'est pas activé pour la règle de transfert, et sa région ne correspond pas à celle du paquet.
Cause probable
En outre, selon l'équilibreur de charge et son niveau, une règle de transfert peut être globale ou régionale. Pour plus d'informations, consultez la table des types d'équilibreur de charge.
Si la règle de transfert est régionale, le client (par exemple, la VM ou le connecteur VPC) doit se trouver dans la même région que l'équilibreur de charge.
Recommandations
Si vous vous connectez à l'équilibreur de charge à partir d'un point de terminaison Google Cloud tel qu'une instance de VM Compute Engine, assurez-vous qu'il se trouve dans la même région que la règle de transfert.
Lorsque vous vous connectez à partir d'un réseau sur site, assurez-vous que le client accède à l'équilibreur de charge via des tunnels Cloud VPN ou des rattachements de VLAN situés dans la même région que l'équilibreur de charge. Pour en savoir plus, consultez la page Équilibreurs de charge d'application internes et réseaux connectés.
Vous pouvez activer l'accès mondial sur les équilibreurs de charge d'application internes et les équilibreurs de charge réseau proxy internes régionaux pour accéder aux clients de n'importe quelle région. Par défaut, les clients de ces équilibreurs de charge doivent se trouver dans la même région que l'équilibreur de charge. Pour en savoir plus, consultez les pages Activer l'accès mondial pour les équilibreurs de charge d'application internes et Activer l'accès mondial pour les équilibreurs de charge réseau proxy internes régionaux.
Pare-feu bloquant la vérification de l'état backend de l'équilibreur de charge
Les pare-feu bloquent les vérifications de l'état au niveau des backends, entraînant l'indisponibilité des backends pour le trafic de l'équilibreur de charge.
Cause probable
Pour que les vérifications d'état fonctionnent, vous devez créer des règles de pare-feu d'entrée autorisant le trafic provenant des vérificateurs Google Cloud à atteindre vos backends. Sinon, les backends sont considérés comme non opérationnels.
Recommandations
Créez des règles de pare-feu d'entrée autorisant le trafic entrant conformément au tableau Plages d'adresses IP de vérification et règles de pare-feu. Pour en savoir plus, consultez la section Règles de pare-feu requises.
Aucune adresse externe disponible
Une instance de VM disposant uniquement d'une adresse IP interne a tenté d'accéder aux hôtes externes via une route dont le saut suivant correspond à la passerelle Internet par défaut. Ce message est généré lorsque Cloud NAT n'est pas activé dans le sous-réseau ou lorsqu'aucune autre route par défaut n'utilise un type de saut suivant différent (tel qu'une VM de proxy).
Cause probable
Une instance disposant uniquement d'une adresse IP interne a tenté d'accéder à un hôte externe, mais sans adresse IP externe, ou Cloud NAT n'a pas été activé dans le sous-réseau.
Recommandations
Si vous souhaitez accéder à des points de terminaison externes, vous pouvez attribuer une adresse IP externe à votre instance. Vous pouvez également activer Cloud NAT sur son sous-réseau, sauf si la connexion passe par une instance de proxy donnant accès à Internet.
Règle de transfert sans instance
Aucun backend n'a été configuré pour la règle de transfert
Cause probable
Aucun backend n'a été configuré pour la règle de transfert que vous essayez d'atteindre.
Recommandations
Vérifiez la configuration de l'équilibreur de charge et assurez-vous que les backends sont configurés dans le service de backend de l'équilibreur de charge.
Le type de trafic est bloqué
Le type de trafic est bloqué, et vous ne pouvez pas configurer de règle de pare-feu pour l'activer. Pour en savoir plus, consultez la section Trafic toujours bloqué.
Cause probable
Ce type de trafic est bloqué par défaut et ne peut pas être activé en créant des règles de pare-feu. Les scénarios courants sont les suivants :
- Envoyez du trafic de sortie vers une destination externe avec le port TCP 25 (SMTP). Pour en savoir plus, consultez la section Trafic toujours bloqué.
- Envoyez du trafic vers un port non compatible sur une instance Cloud SQL. Par exemple, pour envoyer du trafic vers le port TCP 3310 vers une instance Cloud SQL MySQL avec le port 3306 ouvert.
- Envoi de trafic sortant à partir d'une version d'environnement standard App Engine, d'une fonction Cloud Run ou d'une révision Cloud Run qui utilise un protocole autre que TCP ou UDP.
Recommandations
Pour le trafic SMTP de sortie (trafic de sortie vers une destination externe avec le port TCP 25), consultez la section Envoyer des e-mails depuis une instance.
Pour le protocole DHCP, y compris les paquets UDP IPv4 vers le port de destination 68 (réponses DHCP) et les paquets UDP IPv6 vers le port de destination 546 (réponses DHCP), le trafic DHCP n'est autorisé qu'à partir du serveur de métadonnées (169.254.169.254).
Pour la connectivité Cloud SQL, assurez-vous que le port utilisé est correct.
Le connecteur d'accès au VPC sans serveur n'est pas configuré.
Le paquet a été abandonné, car la version de l'environnement standard App Engine, la fonction Cloud Run ou la révision Cloud Run ne comporte pas de connecteur d'accès au VPC sans serveur configuré.
Cause probable
L'adresse IP de destination est une adresse IP privée, qui n'est pas accessible via Internet. Le paquet quitte la source, mais aucun connecteur d'accès au VPC sans serveur n'est configuré pour la version de l'environnement standard App Engine, la fonction Cloud Run ou la révision Cloud Run.
Recommandations
Si vous essayez d'accéder au point de terminaison de destination à l'aide de son adresse IP privée, assurez-vous d'avoir configuré un connecteur d'accès au VPC sans serveur pour la version de l'environnement standard App Engine, la fonction Cloud Run ou la révision Cloud Run.
Le connecteur d'accès au VPC sans serveur ne s'exécute pas
Le paquet a été supprimé, car le connecteur d'accès au VPC sans serveur n'est pas en cours d'exécution.
Cause probable
Le paquet a été abandonné, car toutes les instances du connecteur d'accès au VPC sans serveur sont arrêtées.
Recommandations
Pour obtenir la liste des étapes de dépannage, consultez la page Dépannage.
La connexion Private Service Connect n'est pas acceptée
Le paquet a été supprimé, car la connexion Private Service Connect n'a pas été acceptée.
Cause probable
Le point de terminaison Private Service Connect se trouve dans un projet qui n'est pas autorisé à se connecter au service. Pour en savoir plus, consultez Afficher les détails du point de terminaison.
Recommandations
Assurez-vous que le point de terminaison Private Service Connect se trouve dans un projet autorisé à se connecter au service géré.
Le point de terminaison Private Service Connect est accessible à partir d'un réseau appairé
Le paquet est envoyé au point de terminaison Private Service Connect du réseau appairé, mais une telle configuration n'est pas prise en charge.
Recommandations
Envisagez d'utiliser l'un des modèles de connectivité décrits sur la page Modèles de déploiement Private Service Connect. Vous pouvez également accéder aux API Google et aux services publiés à l'aide de backends Private Service Connect.