Tester la connectivité au sein des réseaux VPC

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.

Symbole	Nom	Signification
	Check Point	Point de décision où Tests de connectivité vérifie une configuration et décide si un paquet de trace doit être transféré, distribué ou supprimé.
	Saut	Étape du chemin de transfert d'un paquet de trace, représentant une ressource Google Cloud qui transfère un paquet au saut suivant dans un réseau VPC (par exemple, à destination d'un proxy Cloud Load Balancing ou d'un tunnel Cloud VPN).
	Point de terminaison	Source ou destination d'un paquet de trace.

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. Si nécessaire, les tests de connectivité effectuent une vérification de spoofing sur le paquet arrivant sur la deuxième VM.

7. 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.	Si la connectivité est bloquée par une règle de stratégie de pare-feu hiérarchique, la trace inclut le nom de la stratégie. La personne qui exécute le test peut ne pas être autorisée à afficher les détails de la stratégie. Pour en savoir plus sur cette situation, consultez la section Résoudre les problèmes liés à une stratégie de pare-feu hiérarchique. Si la connectivité est bloquée par une règle de pare-feu VPC, la trace affiche le nom de la règle de pare-feu d'entrée ou de sortie concernée.
Aucune route correspondante	Impossible de trouver une route vers le point de terminaison de destination.	Si les instances de VM source et de destination se trouvent dans des réseaux VPC différents et que ces réseaux ne sont pas appairés, l'analyse détermine que le Paquet a pu être supprimé. Si les VM se trouvent sur le même réseau, mais qu'une route correspondante est introuvable, le trafic est envoyé sur la route statique par défaut, avec un saut suivant vers la passerelle Internet. Dans ce cas, le trafic n'arrive jamais à la VM de destination et l'analyse détermine que le Paquet pourrait être supprimé. En l'absence de route vers une passerelle Internet, l'analyse détermine que le Paquet a pu être supprimé.
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.