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 peut envoyer recevoir des paquets avec une adresse IP étrangère uniquement 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 à l'instance via une route statique avec l'instance de VM comme prochain saut.
Recommandations
Créez une instance Compute Engine avec le transfert IP activé, ou définissez le paramètre correspondant à 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 partout et bloquent le trafic entrant provenant partout. 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 avez besoin d'une règle de pare-feu de sortie à la source autorisant l'accès au point de terminaison de destination, et 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
Aucune route active ne correspond aux attributs du paquet (comme une adresse IP de destination adresse) dans le réseau de paquets et la région.
Recommandations
Vérifiez la liste des routes efficaces dans la console Google Cloud. Si vous venez de créer une route, notez que cela peut prendre un certain temps pour les tests de connectivité de recevoir une mise à jour de la configuration et de l'intégrer en 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 sections Routes et Utiliser des routes.
Le paquet est envoyé à un réseau incorrect
Le paquet est envoyé à un réseau non prévu. 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 de routes et applicabilité, consultez 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 prochain saut doit être une
de l'équilibreur de charge réseau passthrough interne (règles de transfert utilisées par d'autres équilibreurs de charge,
le transfert de protocole ou que les points de terminaison Private Service Connect ne sont pas
compatibles). 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 plus consultez la section Remarques concernant les instances de saut suivant. et Considérations relatives aux prochains sauts de l'équilibreur de charge réseau passthrough interne.
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 avec le prochain saut Instance Compute Engine dépourvue de carte d'interface réseau sur le réseau de la route.
Cause probable
L'instance Compute Engine utilisée comme prochain saut de route doit disposer d'une carte d'interface réseau au réseau de la route (et non à un réseau VPC appairé).
Recommandations
Vérifier que l'instance Compute Engine du saut suivant possède une carte d'interface réseau réseau de la route. Pour en savoir plus, consultez Remarques concernant les instances de saut suivant.
L'adresse du 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 avec l'adresse IP du prochain saut
(next-hop-address) ne correspond pas à l'adresse IP principale du
Instance Compute Engine.
Cause probable
L'adresse IP du prochain saut de la route (next-hop-address) doit être une adresse IP interne principale
Adresse IPv4 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 du 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 avec le prochain saut
la règle de transfert (next-hop-ilb) n'est pas une règle de transfert du
équilibreur de charge réseau passthrough interne.
Cause probable
La règle de transfert du prochain saut de la route doit être une règle de transfert du é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 comme sauts suivants.
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, qui ne sont pas accessibles via Internet. Cependant, le paquet quitte le instance Compute Engine source, et établit une correspondance avec une route avec le prochain saut de votre passerelle Internet.
Recommandations
Si vous souhaitez accéder à la destination via Internet, vérifiez que l'instance Compute Engine source dispose d'une connexion Internet, par exemple, s'il dispose d'une adresse IP externe ou utilise Cloud NAT, et utiliser 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 façons suivantes :
- Si votre point de terminaison de destination se trouve dans un réseau sur site, utilisez Network Connectivity Center ou une solution de connectivité hybride, comme Cloud VPN ou Cloud Interconnect.
- Si votre point de terminaison de destination se trouve dans Google Cloud :
- de configurer un appairage de réseaux VPC entre entre les réseaux VPC.
- Configurez Cloud VPN entre les réseaux VPC.
- Configurer 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 n'a pas de route via cette ou utilise la route par défaut qui passe par Internet de passerelle VPN haute disponibilité. 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 l'itinéraire et l'applicabilité, consultez 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.
Appairage de réseaux VPC transitifs n'est pas pris en charge. Vous pouvez utiliser le VPN ou l'appairage pour ces deux réseaux VPC.
Accès privé à Google non autorisé
Une instance Compute Engine disposant uniquement d'une adresse IP interne tente d'accéder l'adresse IP externe des API et services Google, alors que l'accès privé à Google n'est pas activée 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 provenant du point de terminaison source vers l'adresse IP externe du serveur API et services sont acheminés via le tunnel Cloud VPN, mais un tel 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 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 pris en charge par la règle de transfert, ou le paquet est envoyé à 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.
Lors de la connexion à 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 d'équilibreurs de charge d'application internes et d'équilibreurs de charge réseau proxy internes régionaux pour accéder aux clients dans la même 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 la page 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.
Pare-feu bloquant la vérification de l'état du backend de l'équilibreur de charge
Les pare-feu bloquent les vérifications de l'état au niveau des backends, entraînant ainsi pour le trafic provenant 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 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. Pour Exemple : envoi de trafic sur le port TCP 3310 vers une instance MySQL Cloud SQL avec le port 3306 ouvert.
- Envoi de trafic de sortie à 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é supprimé, car la version de l'environnement standard App Engine, la fonction Cloud Run, ou la révision Cloud Run n'a 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 il n'y a le connecteur d'accès au VPC sans serveur configuré pour la version de l'environnement standard App Engine, la fonction Cloud Run ou l'API Cloud Run du client.
Recommandations
Si vous essayez d'accéder au point de terminaison de destination en utilisant son adresse IP privée, assurez-vous d'avoir configuré un 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 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é.
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 un projet approuvé pour 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 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 en utilisant Backends Private Service Connect