Un cas d'utilisation courant pour les tests de connectivité consiste à effectuer des tests entre deux instances de machine virtuelle (VM) Compute Engine dans les mêmes réseaux cloud privés virtuels (VPC) ou dans des réseaux VPC appairés.
Pour ce type de test, les tests de connectivité évaluent la joignabilité à l'aide d'analyses de configuration et de plan de données en direct. Pour analyser la configuration, les tests de connectivité identifient et évaluent un chemin de trace.
Les diagrammes de trace de cette page utilisent les symboles décrits dans la légende suivante.
Le schéma suivant illustre le chemin de trace classique entre deux instances de VM. L'objet Match routes peut représenter des routes qui dirigent le trafic dans un seul réseau VPC ou entre deux réseaux VPC appairés.
Les étapes suivantes décrivent les points de contrôle correspondant à chaque point du schéma de trace. La vérification peut échouer à n'importe quel point de contrôle. Les résultats de la requête indiquent la raison de chaque échec. Pour obtenir la liste complète des états des tests et des messages, consultez la section États d'analyse de la configuration.
Les tests de connectivité vérifient que la VM source peut envoyer des paquets de sortie avec l'adresse IP source spécifiée, ou qu'elle peut sinon appliquer par défaut le processus de vérification de spoofing.
-
Les tests de connectivité effectuent une vérification de spoofing lorsqu'un paquet simulé vers ou depuis une instance de machine virtuelle utilise une adresse IP qui n'appartient pas à cette instance. Les adresses IP appartenant à une VM incluent toutes les adresses IP internes de la VM et les adresses IP secondaires.
Si l'adresse semble provenir du trafic externe (ce qu'on appelle également une adresse étrangère), l'adresse IP fait échouer la vérification de spoofing.
Pour déterminer si les paquets de traces peuvent être envoyés à partir de la source, les tests de connectivité vérifient les règles de pare-feu de sortie appropriées. Dans le cadre de ce processus, la fonctionnalité des tests de connectivité commence par évaluer toutes les règles de stratégies de pare-feu hiérarchiques qui existent. Pour en savoir plus sur la façon dont les règles de stratégies de pare-feu hiérarchiques et les règles de pare-feu VPC affectent la connectivité, consultez la section Exemples de stratégies de pare-feu hiérarchiques.
Connectivity Tests trouve (fait correspondre) une route pour l'adresse IP de destination, selon l'ordre de routage. Si aucune autre route n'est disponible pour l'instance de VM de destination, Connectivity Tests utilise la route statique par défaut avec le saut suivant comme passerelle Internet. Tous les réseaux VPC utilisent cette route par défaut, sauf si vous l'avez supprimée.
Connectivity Tests vérifie que les règles de pare-feu d'entrée du réseau permettent au paquet d'arriver sur la VM de destination. Là encore, les tests de connectivité commencent par évaluer les règles de stratégies de pare-feu hiérarchiques qui existent.
Si nécessaire, les tests de connectivité effectuent une vérification de spoofing sur le paquet arrivant sur la deuxième VM.
Connectivity Tests vérifie que la VM de destination peut recevoir un paquet avec l'adresse IP de destination spécifiée. Si cette adresse est une adresse IP étrangère, le transfert IP doit être activé sur la VM de destination. Une adresse IP étrangère est une adresse qui n'appartient pas à la VM.
La capture d'écran suivante de la console Google Cloud montre les résultats d'un test de VM à VM.
L'analyse de configuration montre un résultat de Paquet a pu être distribué. Dans la réponse de l'API, ce libellé correspond à un état final de Deliver.
Ce résultat indique que l'analyse de configuration a validé la connectivité réseau de chaque ressource Google Cloud dans le chemin de la VM source vers la VM de destination. Dans ce cas, la route inclut deux règles de pare-feu VPC : une règle de pare-feu implicite (nommée default) et une règle créée pour ce réseau VPC.
De plus, les tests de connectivité ont vérifié de manière dynamique que la VM de destination est accessible à l'aide d'une vérification active. Le champ Résultat concernant la dernière transmission de paquets affiche les détails de ce résultat.
Vous pouvez développer chacune des fiches dans le chemin de trace pour afficher plus de détails.
L'exemple suivant montre une fiche étendue pour une règle de pare-feu d'entrée. Cette fiche contient des informations sur le réseau VPC, l'action configurée pour la règle de pare-feu (autoriser) et la priorité de la règle.
Lorsqu'une trace contient une route de réseau VPC avec le saut suivant en tant que réseau VPC appairé, le début de la trace n'est pas une instance de VM, mais un réseau VPC. Ce type de trace valide les règles de pare-feu et les routes au niveau du réseau, car l'adresse IP que vous testez provient d'une plage réseau plutôt que d'une instance de VM.
Les réseaux appairés peuvent exister dans le même projet ou dans différents projets. L'exemple de trace suivant montre les réseaux appairés dans différents projets.
Défaillances des tests pour les réseaux VPC
Le tableau suivant répertorie les défaillances courantes des tests au sein des réseaux VPC.
| Type d'échec | Description | Résultats de la trace |
|---|---|---|
| Bloqué par une règle de pare-feu | Le trafic sortant d'un point de terminaison source ou entrant dans un point de terminaison de destination est bloqué par une règle de stratégie de pare-feu hiérarchique ou une règle de pare-feu VPC. |
|
| Aucune route correspondante | Impossible de trouver une route vers le point de terminaison de destination. |
|
| Instance non en cours d'exécution | L'instance de VM de destination existe, mais n'est pas en cours d'exécution. | Cette analyse détermine que le Paquet a pu être supprimé. |
| Saut suivant non valide | Le saut suivant configuré pour une instance de VM n'existe plus et la route vers cette instance n'est pas valide. | Cette analyse détermine que le Paquet a pu être supprimé. |
La capture d'écran suivante illustre une trace qui a échoué, car la connectivité a été bloquée par une règle de stratégie de pare-feu hiérarchique d'entrée.
Défaillances des tests pour les réseaux VPC partagés
Dans les réseaux VPC partagés, le fait de ne pas disposer d'autorisations sur le projet hôte ou le projet de service peut entraîner les échecs des tests répertoriés dans le tableau suivant.
| Type d'échec | Comportement | Résultats de la trace |
|---|---|---|
| Autorisations uniquement pour le projet hôte | Vous ne pouvez pas exécuter la trace, car vous ne disposez pas des autorisations sur le projet de service dans lequel se trouve l'adresse IP de destination. | L'analyse de configuration montre un résultat Analyse de la configuration abandonnée. Dans la réponse de l'API, ce libellé correspond à un état final de Abort. |
| Autorisations uniquement pour le projet de service |
Vous ne pouvez pas exécuter la trace ou sélectionner le réseau de projet hôte dans la console Google Cloud, car vous n'en avez pas l'autorisation. Étant donné que le projet hôte possède des configurations réseau, une trace par rapport aux ressources dans le projet de service ne peut pas continuer sans accès aux règles de pare-feu VPC, aux routes réseau ou aux adresses IP dans le projet hôte. |
Le résultat global de joignabilité est Undetermined, car les tests de connectivité ne peuvent pas déterminer si le paquet peut être distribué vers la destination. |
Défaillances des tests pour les réseaux d'appairage de réseaux VPC
Avec l'appairage de réseaux VPC, le fait de ne pas avoir l'autorisation pour le projet Google Cloud du réseau peered à partir du réseau primary peut entraîner le résultat de test indiqué dans le tableau suivant.
| Type d'échec | Comportement | Résultats de la trace |
|---|---|---|
| Vous n'avez aucune autorisation sur la configuration du projet dans le réseau VPC appairé. | Connectivity Tests peut uniquement tracer les configurations dans le projet du réseau principal. | L'analyse de configuration montre un résultat de Paquet a pu être transféré.
Ce résultat indique qu'un paquet quitte le réseau et est envoyé à un réseau auquel vous n'avez pas accès. Dans ce cas, le paquet a été transféré vers une passerelle de réseau appairé. Dans la réponse de l'API, cet état correspond à un état final de Forward. |
Le chemin de trace suivant montre l'état de transfert pour les réseaux VPC appairés.
Étape suivante
- Scénarios de test courants
- Découvrez Connectivity Tests.
- Résolvez les problèmes liés à Connectivity Tests.