Suivez les conseils ci-dessous pour résoudre les problèmes courants liés aux tests de connectivité.
Pour en savoir plus sur les tests de connectivité, consultez cette présentation.
Pour interpréter les états d'une analyse de configuration d'un test de connectivité, consultez la section États d'analyse de la configuration.
Problèmes d'ordre général
L'obtention des résultats des tests prend trop de temps
Étant donné que Connectivity Tests interroge le dernier instantané d'une configuration de réseau de cloud privé virtuel (VPC), l'obtention des résultats peut prendre un certain temps. Pour plus d'informations, consultez les temps de réponse attendus suite à une requête.
Si vous constatez des latences longues ou instables lors de l'exécution des tests de connectivité, signalez le problème à l'Assistance et décrivez comment le reproduire.
L'analyse de configuration de mon test ne récupère pas la modification de configuration que j'ai effectuée
Après avoir modifié la configuration des ressources Google Cloud dans votre chemin de test, vous pouvez valider l'opération à l'aide de l'analyse de la configuration du test. Toutefois, entre 20 et 120 secondes s'écoulent pour que les tests de connectivité reçoivent une mise à jour de la configuration et l'intègrent à l'analyse. Veillez à patienter suffisamment entre une modification de la configuration et l'exécution de vos tests.
Certains types de configurations peuvent prendre plus de temps. Si votre modification de configuration n'est pas validée par Connectivity Tests après une période prolongée et qu'elle est reproductible, signalez le problème à l'Assistance et décrivez comment le reproduire.
Ce délai ne s'applique pas à la validation dynamique. Par conséquent, vous pouvez constater une différence temporaire entre les résultats affichés par la validation dynamique et l'analyse de la configuration. Par exemple, si vous créez une règle de pare-feu, la validation dynamique répond généralement immédiatement à la nouvelle règle. Toutefois, vous devrez peut-être attendre 20 secondes ou plus afin que l'analyse de configuration soit en mesure d'évaluer la règle de pare-feu, ainsi que les autres ressources du chemin de test.
Problèmes d'état de test
Je n'arrive pas à accéder aux détails d'une stratégie de pare-feu hiérarchique
La trace de votre test peut faire référence à une stratégie de pare-feu hiérarchique que vous n'êtes pas autorisé à afficher.
Toutefois, même si vous ne disposez pas des autorisations nécessaires pour afficher la stratégie, vous pouvez toujours voir les règles de stratégies qui s'appliquent à votre réseau VPC. Pour en savoir plus, consultez la section Stratégies de pare-feu en vigueur dans la présentation des stratégies de pare-feu hiérarchiques.
L'accès aux stratégies de pare-feu hiérarchiques est défini au niveau de l'organisation et du dossier. Pour en savoir plus sur les autorisations nécessaires pour afficher ces stratégies, consultez la section Rôles Identity and Access Management (IAM) dans la présentation des stratégies de pare-feu hiérarchiques.
Mon test affiche un état d'analyse de configuration final Deliver, mais la connectivité est interrompue
Dans certains cas, l'analyse de configuration indique qu'un point de terminaison source et de destination est accessible. Toutefois, vous constaterez peut-être qu'en pratique, la connectivité est interrompue entre les deux points de terminaison, ou que la validation dynamique affiche une perte de paquets de 100 %.
Pour comprendre cette situation, n'oubliez pas que les tests de connectivité utilisent deux types d'analyse : une analyse de configuration, qui détecte les problèmes dans les configurations actives dans votre projet, et la validation dynamique, qui envoie des vérifications sur le plan de données.
Un état d'analyse de configuration final de Deliver signifie que Connectivity Tests n'a détecté aucun problème de configuration.
Cependant, il peut toujours y avoir des problèmes de chemin de données qui peuvent causer des problèmes de connectivité. Pour résoudre le problème, envisagez les solutions suivantes :
- La VM source ou de destination rencontre des problèmes de système d'exploitation invité tels que la panique du noyau du système d'exploitation invité, une carte d'interface réseau (NIC) qui n'est pas initialisée ou des pilotes réseau incompatibles. Vérifiez l'état et la configuration de la carte d'interface réseau de la VM.
- Un problème généralisé affecte le plan de données du réseau. Consultez le tableau de bord des performances de votre projet, en portant une attention particulière à la perte de paquets pour la paire de zones appropriée. Consultez également le tableau de bord d'état de Google Cloud.
- Votre réseau rencontre des problèmes de programmation réseau sporadique, tels que des problèmes liés à la propagation de la configuration réseau à des entités Google Cloud spécifiques. Nous vous conseillons de relancer le test après un délai de cinq minutes. Si le problème persiste, arrêtez et démarrez la VM source ou de destination, comme décrit dans la section Arrêter et démarrer une instance, puis réexécutez le test.
Mon test a renvoyé un résultat global d'analyse de configuration Undetermined
Un résultat global de joignabilité de Undetermined signifie que l'analyse de la configuration n'a pas pu déterminer la connectivité.
Ce résultat peut s'afficher pour l'une des raisons suivantes :
- Une erreur d'autorisation s'est produite. Par exemple, l'utilisateur peut ne pas disposer d'autorisations en lecture pour toutes les ressources nommées dans le test.
- Une erreur interne s'est produite.
- L'analyseur a reçu un argument non valide ou non compatible, ou n'a pas pu identifier un point de terminaison connu.
- Vous essayez de valider une route qui s'étend au-delà de Google Cloud. Connectivity Tests n'a pas accès aux configurations réseau en dehors de Google Cloud.
Mon test a renvoyé un résultat global d'analyse de configuration Ambiguous
Un résultat d'analyse de configuration global Ambiguous signifie que les tests de connectivité renvoient plusieurs traces et qu'il existe un état final mixte.
Le tableau suivant répertorie les motifs les plus courants et les corrections possibles pour cet état.
| Motif | Exemple | Solution |
|---|---|---|
| L'emplacement source n'est pas unique. | Vous avez spécifié une adresse IP source interne sans spécifier le réseau VPC sur lequel elle se trouve (une adresse IP source interne est une adresse à laquelle vous ne pouvez pas accéder depuis Internet). Étant donné que cette adresse est accessible à partir de plusieurs réseaux VPC, Connectivity Tests peut démarrer une trace à partir de chaque emplacement. | Mettez à jour le test avec le réseau VPC où se trouve cette adresse IP. |
| La trace comporte plusieurs destinations possibles. | Vous avez spécifié la destination de trace en tant qu'IPV d'équilibreur de charge ayant plusieurs backends et tous les backends ne sont pas joignables. | Cherchez pourquoi cela se produit et corrigez les problèmes avant de relancer le test. |
Mon test a renvoyé un résultat global d'analyse de configuration Abort avec un message Invalid Argument
Voici quelques raisons courantes d'obtention du message Invalid Argument :
- L'adresse IP que vous avez fournie n'est pas acceptée. Il peut s'agir d'une adresse de rebouclage, d'une adresse IP multicast ou d'une adresse IPv6 sur une instance de VM dotée uniquement d'une adresse IPv4.
- L'instance de VM ou le réseau spécifié n'existent pas. Cette situation peut survenir lorsque l'instance de VM ou le réseau VPC a été supprimé lors de la création du test.
Lorsque vous utilisez l'API Network Management, le message Invalid Argument est généralement renvoyé pour l'une des raisons suivantes :
- Nom mal orthographié ou emplacement incorrect pour la VM ou l'URI du réseau.
- ID de projet spécifié de manière incorrecte. Cette erreur se produit si vous avez utilisé le nom du projet au lieu de l'ID du projet.
- Une incompatibilité entre l'adresse IP interne spécifiée et le réseau sélectionné. Même si Google Cloud Console pour Connectivity Tests effectue une validation stricte de l'instance Compute Engine, du réseau et du projet spécifiés, ce type de non-concordance peut toujours se produire.
Le résultat de l'analyse de configuration est Packet could not be delivered, mais la validation dynamique indique que tous les paquets ont été livrés.
Cette non-concordance peut se produire pour plusieurs raisons. Voici les causes possibles et les mesures correctives associées :
Les modifications récentes de la configuration du réseau VPC ont entraîné une incohérence entre l'analyse de la configuration et la vérification active. Relancez le test en vous assurant, si possible, que la configuration réseau ne change pas avant le test ou pendant le test.
Des problèmes de programmation réseau sporadique se sont produits. Arrêtez et démarrez la VM source ou de destination, comme décrit dans la section Arrêter et démarrer une instance, puis réexécutez le test.
Le résultat de l'analyse de la configuration est Packet could be delivered, mais la validation dynamique indique une perte partielle de paquets
Cette non-concordance peut se produire pour plusieurs raisons. Voici les causes possibles et les solutions associées :
La VM source ou de destination est limitée, tout en dépassant la capacité de bande passante d'entrée ou de sortie autorisée. Analysez le volume de trafic de la VM en accédant à la page Informations sur l'instance de VM et en examinant les détails de l'onglet Surveillance. Examinez la métrique Octets réseau et comparez-la aux limites de bande passante décrites pour le type de machine dans la section Bande passante réseau.
Un problème généralisé affecte le plan de données du réseau. Consultez le tableau de bord des performances de votre projet, en accordant une attention particulière à la paire de zones appropriée. Consultez également le tableau de bord d'état de Google Cloud.
Le résultat de l'analyse de la configuration est Packet could be delivered et la validation dynamique indique une distribution complète, mais mon application subit une perte
Cette non-concordance peut se produire pour plusieurs raisons. Voici les causes possibles et les solutions associées :
- Le trafic peut être bloqué par le système d'exploitation invité (par exemple, par des règles de pare-feu internes). Vérifiez que le trafic n'est pas bloqué, puis relancez le test.
- Les paquets de données d'application peuvent traverser un chemin d'accès réseau différent des vérifications de validation dynamique. Envisagez de rétablir la connexion réseau. Par exemple, essayez d'utiliser un autre port source.
- La validation dynamique détecte la perte de paquets unidirectionnelle. Dans votre cas, une perte de paquets peut se produire sur le chemin de retour. Envisagez d'exécuter un test dans la direction opposée.
Les résultats du test n'incluent pas de résultat de validation dynamique
Les configurations compatibles avec les tests de connectivité ne peuvent pas toutes être validées de manière dynamique. Assurez-vous que le test respecte les conditions requises pour la validation dynamique, comme spécifié dans la présentation.
L'API Network Management a renvoyé INTERNAL_ERROR
Cet événement ne devrait normalement pas se produire. Si tel est le cas, signalez le problème à l'Assistance et décrivez comment le reproduire.
Problèmes liés à Google Cloud Console
Google Cloud Console pour Connectivity Tests a planté
Google Cloud Console ne devrait normalement pas planter. Si tel est le cas, signalez le problème à l'Assistance et décrivez comment le reproduire.