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 supprimé, car une instance Compute Engine ne peut envoyer ou recevoir des paquets avec une adresse IP étrangère que lorsque 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 distribué à l'instance via une route statique avec l'instance de VM comme saut suivant.
Recommandations
Créez une instance Compute Engine avec le transfert IP activé, ou définissez l'attribut correspondant pour l'instance existante. Pour en savoir plus, consultez la page 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 s'il est autorisé en raison du suivi de connexion.
Cause probable
Les tests de connectivité peuvent refuser un paquet de test s'il correspond à une règle de pare-feu bloquante ou à une règle de stratégie de pare-feu. 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é l'application de la règle de pare-feu.
Chaque réseau VPC comporte deux règles de pare-feu implicites qui autorisent le trafic de sortie vers tous les emplacements et bloquent le trafic entrant provenant de n'importe quelle source. Vous pouvez également disposer d'une règle de pare-feu refusant le trafic sortant de priorité plus élevée.
Pour que la connectivité aboutisse, vous devez disposer d'une règle de pare-feu de sortie à la source autorisant l'accès au point de terminaison de destination, et d'une règle de pare-feu d'entrée à la destination pour autoriser 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.
Supprimé en raison de l'absence de route correspondante
Le paquet est supprimé, car aucune route correspondante ne correspond.
Cause probable
Il n'existe aucune route active correspondant aux attributs des paquets (comme une adresse IP de destination) dans le réseau et la région des paquets.
Recommandations
Vérifiez la liste des routes efficaces dans la console Google Cloud. Si vous venez de créer une route, notez que les tests de connectivité peuvent mettre un certain temps à recevoir une mise à jour de la configuration et à l'intégrer dans 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, de Network Connectivity Center ou d'une solution de connectivité hybride telle que Cloud VPN).
Notez que l'appairage de VPC transitif n'est pas disponible. 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 de disposer d'une route pour l'adresse IP de destination avec la passerelle Internet du 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 pour l'applicabilité des routes. Certaines routes que vous voyez dans la table des vues de routes peuvent ne pas être disponibles pour le trafic provenant de NEG hybrides.
Pour en savoir plus, consultez les sections Routes et Utiliser des routes.
Le paquet est envoyé à un réseau incorrect
Le paquet est envoyé à un réseau indésirable. Par exemple, vous exécutez un test depuis une instance Compute Engine du réseau network-1 vers l'instance Compute Engine du réseau network-2, mais le paquet est envoyé au réseau network-3.
Cause probable
Le réseau network-1 dispose d'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 de routes et l'applicability 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, l'adresse IP du saut suivant n'étant attribuée à aucune ressource.
Cause probable
S'il s'agit d'une route avec next-hop-address, l'adresse du 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 dans les réseaux appairés ne sont pas acceptées.
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ées). L'adresse IP doit être attribuée à une ressource du réseau VPC de la route ou d'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 relatives aux instances de saut suivant et Considérations relatives aux sauts suivants de l'équilibreur de charge réseau passthrough interne.
L'instance du prochain saut de la route a une carte d'interface réseau sur le mauvais réseau
Le paquet est envoyé à une destination à l'aide d'une route non valide, l'instance Compute Engine du saut suivant ne disposant pas d'une carte d'interface réseau dans le réseau associé à la route.
Cause probable
L'instance Compute Engine utilisée comme prochain saut de route doit disposer d'une carte d'interface réseau sur le réseau de la route (et non sur un réseau VPC appairé).
Recommandations
Vérifiez que l'instance Compute Engine du saut suivant possède une carte d'interface réseau dans le réseau de la route. Pour en savoir plus, consultez la section Considérations relatives aux instances de saut suivant.
L'adresse du prochain saut de la route n'est pas une adresse IP principale de VM
Le paquet est envoyé à une destination à l'aide d'une route non valide, l'adresse IP du saut suivant (next-hop-address) n'étant pas une adresse IP principale de l'instance Compute Engine.
Cause probable
L'adresse IP du prochain saut 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 saut suivant est une adresse IPv4 interne principale de l'instance Compute Engine. Pour en savoir plus, consultez la section Considérations relatives aux instances de saut suivant.
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, la règle de transfert du saut suivant (next-hop-ilb) n'étant 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 relatives aux prochains sauts de l'équilibreur de charge réseau passthrough interne.
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 des paquets est une adresse IP privée à laquelle il n'est pas possible d'accéder via Internet. Cependant, 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 connexion Internet (par exemple, elle dispose d'une adresse IP externe ou utilise Cloud NAT) et utilisez l'adresse IP externe du point de terminaison de destination dans le 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 manières 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 du point de terminaison source ne dispose d'aucune 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 des routes et l'applicability des routes, consultez les sections 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 pris en charge. 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 qui ne dispose que d'une adresse IP interne tente d'atteindre l'adresse IP externe des API et des 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 à accéder à l'adresse IP externe des API et des services Google de l'une des manières suivantes:
- Activez l'accès privé à Google pour le sous-réseau de l'instance.
- attribuer une adresse IP externe à la carte d'interface 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 disposant d'une adresse IP interne tente d'atteindre l'adresse IP externe des API et des 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 des services Google est acheminé via le tunnel Cloud VPN, mais une telle configuration n'est pas compatible.
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, reportez-vous à la page Accès privé à Google pour les hôtes sur site pour obtenir des instructions détaillées.
Non-concordance 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 qui n'est pas compatible avec la règle de transfert, ou vers 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é sur 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 qui se trouvent 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 global 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.
Vérification de l'état du backend de l'équilibreur de charge bloquant le pare-feu
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 autorisant les entrées qui permettent au trafic provenant des vérificateurs Google Cloud d'atteindre vos backends. Sinon, les backends sont considérés comme non opérationnels.
Recommandations
Créez des règles de pare-feu autorisant les entrées en fonction du 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, l'envoi de trafic sur le port TCP 3310 vers une instance MySQL Cloud SQL avec le port 3306 ouvert).
- Envoyer du trafic de sortie depuis une version de l'environnement standard App Engine, une fonction Cloud ou 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é supprimé, car aucun connecteur d'accès au VPC sans serveur n'est configuré dans la version de l'environnement standard App Engine, la fonction Cloud ou la révision Cloud Run.
Cause probable
L'adresse IP de destination est une adresse IP privée, qui ne peut pas être 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 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 ou la révision Cloud Run.
Le connecteur d'accès au VPC sans serveur n'est pas en cours d'exécution
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é supprimé, 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 section 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 la section Afficher les détails des points 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 depuis un réseau appairé
Le paquet est envoyé au point de terminaison Private Service Connect dans le réseau appairé, mais une telle configuration n'est pas acceptée.
Recommandations
Pensez à utiliser l'un des modèles de connectivité décrits sur la page Modèles de déploiement de Private Service Connect. Vous pouvez également accéder aux API Google et aux services publiés à l'aide des backends Private Service Connect.