Cas d'utilisation courants de Connectivity Tests

Connectivity Tests évalue si le trafic peut circuler correctement entre les points de terminaison de votre réseau. Il évalue la joignabilité en analysant votre configuration réseau et, dans certains cas d'utilisation, en envoyant des paquets de vérification.

Cette page décrit les cas d'utilisation courants des tests de connectivité qui se répartissent en six catégories :

  • Effectuer des tests au sein des réseaux du cloud privé virtuel (VPC), y compris les réseaux qui utilisent le VPC partagé et l'appairage de réseaux VPC
  • Tester les services gérés par Google (bêta)
  • Effectuer des tests à partir d'un réseau VPC vers un réseau non-VPC, tel qu'un centre de données sur site
  • Effectuer un test depuis un réseau non-Google Cloud vers un réseau VPC
  • Effectuer un test depuis un réseau non-Google Cloud vers un autre réseau non-Google Cloud
  • Effectuer des tests sur des équilibreurs de charge Google Cloud

La page Détecter les configurations incorrectes ou incohérentes décrit comment gérer ces scénarios.

Le cas d'utilisation du test d'une instance de machine virtuelle (VM) vers une autre décrit un scénario de test de bout en bout comple, y compris les résultats des tests fournis dans Google Cloud Console.

Pour obtenir des instructions sur l'exécution de tests, consultez la page Exécuter Connectivity Tests.

Légende des diagrammes de trace

Les diagrammes de trace de cette page utilisent les symboles décrits dans la légende suivante.

Symbole Nom Signification
Légende du diagramme de trace des paquets : losange gris.
Losange gris
Check Point Un point de décision où Connectivity Tests vérifie une configuration et décide si un paquet de trace doit être transféré, distribué ou supprimé.
Légende du diagramme de trace des paquets : rectangle bleu.
Rectangle bleu
Saut Une étape dans le 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).
Légende du diagramme de trace des paquets : hexagone orange.
Hexagone orange
Point de terminaison Source ou destination d'un paquet de trace.

Effectuer des tests au sein des réseaux VPC

Un cas d'utilisation courant de Connectivity Tests consiste à tester deux instances de machine virtuelle (VM) Compute Engine sur le même réseau VPC ou sur des réseaux VPC appairés. Pour ce type de test, Connectivity Tests évalue la joignabilité à l'aide d'analyses de configuration et de validation dynamique.

Pour analyser la configuration, Connectivity Tests identifie et évalue un chemin 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.

Trace de VM source vers VM de destination.
Trace de VM source vers VM de destination

Les étapes suivantes décrivent les points de contrôle correspondant à chaque point du schéma de trace. À chaque point de contrôle, la vérification peut échouer. Les résultats de la requête indiquent la raison de chaque échec. Pour obtenir la liste complète des états et des messages de test, consultez la documentation de référence sur les états d'analyse de 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. Ils peuvent également utiliser l'adresse IP interne principale par défaut. Sinon, le transfert IP doit être activé sur cette VM.
  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.

Console

La capture d'écran suivante de Google Cloud Console 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.

Capture d'écran de Cloud Console pour une trace de VM à VM
Capture d'écran de Cloud Console pour une trace de VM à VM

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.

Développement de la fiche de règle du pare-feu d'entrée.
Développement de la fiche de règle de pare-feu d'entrée

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.

Trace VM à VM via un réseau VPC appairé accessible dans un projet différent.
Trace VM à VM via un réseau VPC appairé accessible dans un projet différent

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 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. Sachez que la personne exécutant le test n'est peut-être pas autorisée à afficher les détails de la stratégie. Pour en savoir plus sur cette situation, consultez la section Dépannage.
  • 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é.

Console

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.

Capture d'écran de Cloud Console pour une trace bloquée par une règle de stratégie de pare-feu hiérarchique.
Capture d'écran de Cloud Console pour une trace bloquée par une règle de stratégie de pare-feu hiérarchique

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 Cloud Console, car vous n'en avez pas l'autorisation.

Étant donné que le projet hôte possède des configurations réseau, une trace sur les ressources dans le projet de service ne peut pas s'exécuter 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 les défaillances des tests répertoriées 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 Forward.

Le chemin de trace suivant montre cette défaillance pour les réseaux VPC appairés.

Trace VM à VM via un réseau VPC appairé inaccessible dans un projet différent
Trace VM à VM via un réseau VPC appairé inaccessible dans un projet différent

Tester des services gérés par Google

Vous pouvez obtenir une analyse de configuration des tests de connectivité sur les routes vers et depuis des services gérés par Google, tels que les maîtres du cluster Google Kubernetes Engine (GKE) ou les instances Cloud SQL. Même si vous ne disposez pas des autorisations nécessaires pour accéder au projet appartenant à Google où se trouvent ces ressources, les tests de connectivité peuvent tout de même analyser la configuration du réseau VPC du projet et fournir un résultat global de joignabilité. Les tests de connectivité ne fournissent pas de détails de configuration pour l'analyse dans le projet appartenant à Google.

Par défaut, les tests de connectivité tentent d'exécuter un test en utilisant l'adresse IP privée du point de terminaison du service géré par Google et la connexion d'appairage de réseaux VPC entre votre réseau et le réseau appartenant à Google. Si le point de terminaison ne dispose pas d'adresse IP privée, les tests de connectivité utilisent l'adresse IP publique. Les tests de connectivité vérifient que le paquet peut atteindre le point de terminaison, ce qui inclut l'analyse de la configuration au sein du réseau VPC appartenant à Google pour le point de terminaison. Si les tests de connectivité détectent des problèmes de configuration au sein de votre projet, leur analyse s'arrête avant d'atteindre le réseau appartenant à Google.

Le schéma suivant illustre le chemin de trace lors du test de connectivité à des services gérés par Google. Il utilise l'exemple d'un test entre un nœud et un maître GKE :

Nœud GKE source vers le maître GKE de destination.
Nœud GKE source vers le maître GKE de destination

Cloud SQL vers une VM

Cette section décrit un exemple de test entre une instance Cloud SQL et une VM.

Exemples d'entrées

Le tableau suivant présente des exemples de valeurs d'entrée pour un test à partir d'une instance Cloud SQL. Pour voir les résultats d'un test réussi, passez à la section suivante.

Paramètre d'entrée Valeur d'entrée
Protocole TCP
Instance Cloud SQL source instance-1
Projet source my-project
VM de destination vm-1
Port de destination 80

Test réussi

Dans cette section, vous trouverez un exemple de résultat d'un test réussi à partir d'une instance Cloud SQL.

Console

La capture d'écran suivante de Cloud Console montre une trace d'une instance Cloud SQL qui indique un résultat global Reachable.

Ce résultat montre que Connectivity Tests a validé la connectivité réseau de l'instance Cloud SQL source à la VM de destination. Cela inclut l'analyse de la configuration dans le projet appartenant à Google où l'instance Cloud SQL est exécutée. La trace ne fournit pas de détails sur les ressources du projet appartenant à Google, car vous ne disposez pas des autorisations nécessaires pour les afficher.

Capture d'écran de Cloud Console pour la trace de Cloud SQL vers la VM.
Capture d'écran de Cloud Console pour la trace de l'instance Cloud SQL vers la VM

Nœud GKE vers le maître de cluster GKE

Cette section décrit un exemple de test entre un nœud Google Kubernetes Engine (GKE) et un maître de cluster GKE.

Exemples d'entrées de test

Le tableau suivant présente des exemples de valeurs d'entrée pour un test vers un maître GKE. Pour voir les résultats d'un test réussi, passez à la section suivante.

Paramètre d'entrée Valeur d'entrée
Protocole TCP
Nœud GKE source gke-cluster-1-node-1
Projet source my-project
Maître de cluster GKE de destination projects/myproject/locations/us-central1/clusters/cluster-1
Port de destination 443

Test réussi

Cette section fournit un exemple de résultat d'un test réussi vers un maître GKE.

Console

La capture d'écran suivante de Cloud Console montre une trace d'un maître GKE de destination qui indique un résultat global Reachable.

Ce résultat montre que Connectivity Tests a validé la connectivité réseau du nœud GKE source vers le maître GKE de destination. Cela inclut l'analyse de la configuration des ressources du projet appartenant à Google dans lequel le maître est exécuté. La trace ne fournit pas de détails sur les ressources du projet appartenant à Google, car vous ne disposez pas des autorisations nécessaires pour les afficher.

Capture d'écran de Cloud Console pour la trace du nœud vers le maître GKE
Capture d'écran de Cloud Console pour la trace du nœud vers le maître GKE

Nœud GKE vers le maître GKE via une adresse IP publique

Le tableau suivant présente des exemples de valeurs d'entrée pour un test d'un maître GKE via une adresse IP publique. Pour voir les résultats d'un test réussi, passez à la section suivante.

Exemples d'entrées de test

Paramètre d'entrée Valeur d'entrée
Protocole TCP
Nœud GKE source gke-cluster-1-node-1
Projet source my-project
Adresse IP de destination 104.1.1.1
Port de destination 443

Test réussi

Cette section décrit un exemple de test réussi vers un maître GKE via une adresse IP publique.

Console

La capture d'écran suivante de Cloud Console montre une trace d'un maître GKE via l'adresse IP publique qui indique un résultat global Reachable.

Ce résultat montre que Connectivity Tests a validé la connectivité réseau du nœud GKE source au réseau sur lequel le maître GKE s'exécute, mais pas au maître GKE. Lors des tests via une adresse IP publique, Connectivity Tests n'analyse pas la configuration des ressources dans le projet appartenant à Google dans lequel l'instance maître est exécutée.

Capture d'écran de Cloud Console pour la trace de nœud à maître GKE via une adresse IP publique.
Capture d'écran de Cloud Console pour la trace de nœud à maître GKE via une adresse IP publique

Défaillances des tests pour les services gérés par Google

Lorsque vous testez des services gérés par Google, le test peut échouer et renvoyer un message d'erreur indiquant que le paquet a été supprimé à l'intérieur du service (par exemple, DROPPED_INSIDE_GKE_SERVICE ou DROPPED_INSIDE_CLOUD_SQL_SERVICE). Ce message peut indiquer un problème de configuration dans le projet appartenant à Google qui héberge le service dans les cas suivants :

  • Vous avez testé la connectivité entre un maître GKE et un nœud GKE dans le même cluster (dans les deux sens).
  • Vous avez testé la connectivité de votre réseau VPC vers une instance Cloud SQL connectée à votre réseau, où la source et la destination se trouvent dans la même région.

Si vous recevez le message d'erreur mentionné précédemment pour l'un des cas décrits ci-dessus, contactez l'assistance. Sinon, le message d'erreur peut indiquer une entrée non valide. Confirmez que vous effectuez un test depuis ou vers un point de terminaison existant et que vous souhaitez atteindre la ressource gérée dans le projet appartenant à Google. Par exemple, si vous effectuez le test depuis un nœud GKE vers un maître GKE, vérifiez que le nœud existe et qu'il est censé être connecté au maître.

Exemples d'entrées de test : VM vers une instance Cloud SQL située dans une région différente

Le tableau suivant présente des exemples de valeurs d'entrée pour un test d'une VM à une instance Cloud SQL, où la VM se trouve dans une région différente de celle de l'instance Cloud SQL. Pour voir les résultats du test ayant échoué, passez à la section suivante.

Paramètre d'entrée Valeur d'entrée
Protocole TCP
VM source instance-1
Cette VM se trouve dans une région différente de celle de l'instance Cloud SQL.
Projet source my-project
Instance Cloud SQL de destination vm-1
Port de destination 5432

Test ayant échoué

Cette section décrit un exemple de test sur une instance Cloud SQL ayant échoué.

Console

La capture d'écran suivante de Cloud Console montre une trace vers une instance Cloud SQL de destination qui indique un résultat global Unreachable.

Capture d'écran de Cloud Console pour le test de la trace de la VM vers Cloud SQL ayant échoué.
Capture d'écran de Cloud Console pour le test de la trace de la VM vers Cloud SQL ayant échoué

Effectuer un test depuis un réseau VPC vers un réseau non-Google Cloud

Vous pouvez utiliser l'analyse de configuration des tests de connectivité pour tester la connectivité entre votre réseau VPC et un réseau autre que Google Cloud via Cloud VPN ou Cloud Interconnect. En règle générale, un réseau autre que Google Cloud est votre réseau sur site ou le réseau d'un autre fournisseur cloud.

L'analyse de configuration évalue le chemin d'accès réseau jusqu'à l'adresse IP externe du routeur ou de la passerelle VPN dans un réseau appairé.

L'exemple suivant montre une trace de VM1 dans un réseau VPC vers VM2 dans un réseau sur site, via un tunnel VPN classique utilisant un routage statique.

Trace de paquets via un tunnel Cloud VPN à l'aide de routes statiques
Trace de paquets via un tunnel Cloud VPN à l'aide de routes statiques

S'il existe une route statique ou dynamique correspondante pour l'adresse IP de destination dans un réseau homologue, l'analyse de configuration fait correspondre et vérifie la route en fonction de la priorité des routes.

Il existe une route statique par défaut pour toutes les destinations contenant le saut suivant comme passerelle Internet. Connectivity Tests peut faire correspondre cette route par défaut, sauf si vous l'avez supprimée ou modifiée.

Si la route statique par défaut n'existe pas et qu'il n'y a aucune autre route valide vers la destination, la trace renvoie un état final défini sur Drop.

Chemin de trace vers un réseau non Google Cloud à l'aide d'un routage statique
Chemin de trace vers un réseau autre que Google Cloud utilisant un routage statique


Chemin de trace vers un réseau non Google Cloud à l'aide d'un routage dynamique.
Chemin de trace vers un réseau autre que Google Cloud utilisant le routage dynamique

Effectuer un test depuis un réseau non-Google Cloud vers un réseau VPC

L'analyse de configuration vérifie que votre réseau VPC peut recevoir un paquet entrant provenant de votre réseau sur site après que ce paquet peut arriver sur votre réseau VPC. L'analyse vérifie également que la configuration du réseau VPC est susceptible d'autoriser la livraison de ce paquet à la destination prévue. L'analyse de configuration indique que le Paquet peut être transféré (dans la réponse de l'API, l'état final est Forward). La destination est considérée comme accessible.

Lorsque votre réseau VPC est appairé à votre réseau sur site via Cloud Router, le réseau VPC reçoit une ou plusieurs routes dynamiques depuis votre réseau sur site appairé. En parallèle, votre réseau VPC annonce ses propres routes vers votre réseau sur site appairé.

Étant donné que Connectivity Tests n'a pas accès à votre configuration réseau sur site, il ne peut pas vérifier la configuration des routes et des règles de pare-feu correctes sur votre routeur sur site. Ainsi, le trafic entre votre réseau sur site et votre réseau VPC est toujours considéré comme valide par l'analyse de la configuration des tests de connectivité.

Toutefois, les tests de connectivité peuvent évaluer si la configuration VPC autorise la livraison d'un paquet à une destination dans Google Cloud. Pour évaluer l'accessibilité, il évalue les ressources Google Cloud suivantes :

  • Règles de pare-feu d'entrée du réseau VPC.
  • La route annoncée pour les adresses IP de votre réseau VPC que Cloud Router annonce sur votre réseau sur site (appairé).

Exemples d'entrées de test

Le tableau suivant montre des exemples de valeurs d'entrée pour un équilibreur de charge Google Cloud test décrit dans la section précédente. Passez à la section suivante pour voir les résultats pour un test réussi.

Paramètre d'entrée Valeur d'entrée
Protocole TCP
Exemple d'adresse IP sur site 10.0.29.2
Il s'agit d'une adresse IP utilisée dans Google Cloud (case à cocher) Décochez cette case lorsque vous spécifiez une adresse source IP sur site.

Un test réussi à partir d'un réseau sur site

Cette section décrit un exemple de test réussi d'un réseau sur site vers un réseau VPC.

Console

Le résultat du test suivant évalue la connectivité via Cloud VPN depuis l'adresse IP sur site vers une instance de VM. Il évalue également la session du protocole BGP (Border Gateway Protocol), les routes et les règles de pare-feu VPC.

Exemple de résultat pour un test réussi depuis un environnement sur site vers Google Cloud
Exemple de résultat pour un test réussi depuis un environnement sur site vers Google Cloud

Effectuer un test entre deux réseaux non-Google Cloud

Vous pouvez utiliser l'analyse de la configuration Connectivity Tests pour évaluer la joignabilité entre deux réseaux non-Google Cloud connectés via Network Connectivity Center. Dans ce contexte, un réseau non-Google Cloud est généralement votre centre de données sur site ou une filiale.

Étant donné que Tests de connectivité n'a pas accès à votre configuration réseau sur site, il ne peut pas vérifier la configuration des routes et des règles de pare-feu sur votre routeur sur site. Ainsi, le trafic de votre réseau sur site à votre réseau VPC est toujours considéré comme valide par l'analyse de la configuration de Tests de connectivité, et seules les configurations de Google Cloud sont validées.

L'analyse de la configuration apprend les plages du réseau sur site à partir des routeurs cloud associés aux spokes du Network Connectivity Center. Vous pouvez identifier les problèmes de configuration au sein de votre réseau VPC qui peuvent affecter la connectivité entre les réseaux sur site.

Tous les types de spoke Network Connectivity Center utilisent des routeurs cloud pour échanger des routes via des sessions BGP. Exemple :

  • Spokes d'appareil de routeur : lorsque Cloud Router et les instances d'appareil de routeur se trouvent dans la même région, ils échangent les routes entre eux.
  • Cloud VPN et les rattachements de VLAN : les routeurs cloud échangent les routes BGP avec les routeurs du réseau sur site.

Pour en savoir plus sur le centre de connectivité réseau, consultez la section Présentation du centre de connectivité réseau.

Effectuer un test entre deux réseaux non-Google Cloud via le routeur

Dans l'exemple suivant, Connectivity Tests trace un paquet simulé d'un réseau sur site à un autre. Le paquet entre dans le réseau VPC à partir du spoke d'appliance de routeur connecté au premier réseau sur site. De là, il suit une route dynamique annoncée par le routeur cloud associé au spoke d'appliance de routeur connecté au deuxième réseau sur site. Le paquet atteint le réseau sur site à partir de la deuxième instance du dispositif de routeur.

Exemples d'entrées

Le tableau suivant présente des exemples de valeurs d'entrée pour un test à partir d'une adresse IP du réseau sur site. Pour voir les résultats d'un test réussi, passez à la section suivante.

Paramètre d'entrée Valeur d'entrée
Protocole TCP
Adresse IP du point de terminaison source 192.168.1.1
Il s'agit d'une adresse IP utilisée dans Google Cloud (case à cocher) Décochez cette case lorsque vous spécifiez une adresse source IP sur site.
Adresse IP du point de terminaison de destination 172.16.1.1
Il s'agit d'une adresse IP utilisée dans Google Cloud (case à cocher) Décochez cette case lorsque vous spécifiez une adresse de destination IP sur site.

Un test réussi depuis un réseau sur site vers un autre réseau sur site

Cette section décrit un exemple de test réussi d'un réseau sur site vers un autre via des spokes d'appareil de routeur.

Console

Le résultat de test suivant évalue la connectivité d'un réseau sur site via deux instances de dispositif de routeur à un autre réseau sur site. Il évalue également la session BGP, les routes et les règles de pare-feu VPC.

Exemple de résultat d'un test réussi d'un réseau sur site vers un réseau sur site.
Exemple de résultat d'un test réussi d'un réseau sur site vers un réseau sur site

Effectuer des tests entre deux réseaux non-Google Cloud via Cloud VPN et Cloud Interconnect

Dans l'exemple suivant, Connectivity Tests trace un paquet simulé d'un réseau sur site à un autre. Le paquet entre dans le réseau VPC via la passerelle VPN. Le paquet atteint l'autre réseau sur site via une connexion Interconnect.

Exemples d'entrées

Le tableau suivant présente des exemples de valeurs d'entrée pour un test à partir d'une adresse IP du réseau sur site. Pour voir les résultats d'un test réussi, passez à la section suivante.

Paramètre d'entrée Valeur d'entrée
Protocole TCP
Adresse IP du point de terminaison source 10.0.0.1
Il s'agit d'une adresse IP utilisée dans Google Cloud (case à cocher) Décochez cette case lorsque vous spécifiez une adresse source IP sur site.
Adresse IP du point de terminaison de destination 10.240.0.1
Il s'agit d'une adresse IP utilisée dans Google Cloud (case à cocher) Décochez cette case lorsque vous spécifiez une adresse de destination IP sur site.
Port de destination 80

Exemple de test d'un réseau sur site vers un autre réseau sur site

Cette section décrit un exemple de test d'un réseau sur site vers un autre réseau sur site, via des spokes de rattachement de VPN et de VLAN.

Console

Le résultat de test suivant évalue la connectivité d'un réseau sur site via des spokes de rattachement de VPN et de VLAN à un autre réseau sur site.

Exemple de résultat d'un test réussi d'un réseau sur site vers un réseau sur site.
Exemple de résultat pour un test réussi d'un réseau sur site vers un réseau sur site via des spokes de rattachement de VPN et de VLAN

Effectuer des tests sur des équilibreurs de charge Google Cloud

L'analyse de la configuration des tests de connectivité permet de tracer les paquets simulés sur tous les types d'équilibreurs de charge Google Cloud.

Le chemin de trace d'un équilibreur de charge HTTP(S) externe s'applique également à un équilibreur de charge proxy TCP et à un équilibreur de charge proxy SSL. Pour plus d'informations, consultez la page Présentation de Cloud Load Balancing.

Dans l'exemple suivant, Connectivity Tests trace un paquet simulé depuis un hôte externe vers une adresse IP virtuelle pour un équilibreur de charge HTTP(S) externe. La connexion TCP de l'hôte externe se termine au niveau du proxy pour l'équilibreur de charge HTTP(S) externe. L'équilibreur de charge HTTP(S) externe initie ensuite une nouvelle connexion TCP à une VM agissant en tant que backend d'équilibreur de charge.

Un chemin de trace typique vers un équilibreur de charge HTTP(S) externe avec une légende de diagramme.
Chemin de trace classique vers un équilibreur de charge HTTP(S) externe

Dans le chemin de trace suivant, l'analyse de configuration des tests de connectivité fournit trois traces, une pour chaque chemin possible vers les trois backends de l'équilibreur de charge. Les tests de connectivité effectuent cette opération, car ils valident uniquement les configurations, et non le plan de données en direct.

Trace de paquet vers un équilibreur de charge HTTP(S) externe
Trace de paquets vers un équilibreur de charge HTTP(S) externe (voir la légende)

Exemples d'entrées de test

Le tableau suivant présente des exemples de valeurs d'entrée pour un test vers l'équilibreur de charge HTTP(S) externe décrit dans la section précédente. Pour voir les résultats d'un test réussi, passez à la section suivante.

Paramètre d'entrée Valeur d'entrée
Protocole de destination TCP
Port de destination 80
Exemple d'adresse IP source externe (non illustré) 62.35.1.1
Adresse IP externe de l'équilibreur de charge 203.0.113.99
Projet de destination myproject

Un test réussi pour un équilibreur de charge

Cette section décrit un exemple de test réussi pour l'équilibreur de charge HTTP(S) externe décrit précédemment.

Dans le plan de données réel, l'algorithme de l'équilibrage de charge choisit une instance de VM pour chaque connexion backend. Étant donné qu'il existe trois backends d'équilibrage de charge dans cet exemple, le menu Sélection de trace de l'écran Résultats vous permet de sélectionner la trace que vous voulez consulter.

Console

Le résultat de test réussi suivant confirme que toutes les ressources Google Cloud suivantes pour l'équilibreur de charge HTTP(S) externe sont correctement configurées.

  • Règle de transfert
  • Backends de l'équilibreur de charge, y compris la possibilité pour l'équilibreur de charge d'envoyer avec succès des vérifications d'état à ces backends
  • Connexion proxy
  • Règles de pare-feu VPC

Ce résultat montre qu'un paquet simulé provenant d'une adresse IP externe est parvenu à atteindre les instances de VM backend.

Pour un exemple détaillé d'une trace vers les trois backends, consultez la page Détecter les configurations incorrectes ou incohérentes.

Exemple de résultat pour un test réussi vers un équilibreur de charge HTTP(S) externe
Exemple de résultat pour un test réussi vers un équilibreur de charge HTTP(S) externe

Si vous ne disposez pas des autorisations permettant de consulter les ressources Google Cloud dans le chemin d'accès réseau pour l'équilibreur de charge HTTP(S) externe, vous pouvez toujours voir les résultats dans Cloud Console, y compris les résultats réussis. Cependant, la fiche de chaque ressource testée indique "Aucune autorisation permettant d'afficher la ressource dans PROJECT_NAME".

Un test montrant une règle de pare-feu manquante pour une vérification d'état

Une trace de l'équilibreur de charge vérifie un grand nombre des configurations des ressources Google Cloud décrites précédemment. Toutefois, si les ressources de l'équilibreur de charge suivantes sont mal configurées, l'analyse indique que le Paquet a pu être supprimé (l'état final de la trace est Drop).

Console

Le résultat de test suivant montre que les règles de pare-feu d'entrée du réseau VPC ne permettent pas la vérification de l'état des backends de l'équilibreur de charge, rendant ainsi les backends indisponibles pour l'équilibreur de charge.

Exemple de résultat pour une règle de pare-feu manquante.
Exemple de résultat pour une règle de pare-feu manquante

Outre les règles de pare-feu VPC non valides, les problèmes suivants sont des problèmes de configuration courants que le module Connectivity Tests détecte pour les équilibreurs de charge Google Cloud.

Pour corriger ces problèmes, utilisez les solutions décrites dans le tableau suivant.

Problème de configuration Solution
Les paramètres d'entrée ne correspondent pas au protocole ou au port que vous avez défini dans la règle de transfert de l'équilibreur de charge. Avant d'exécuter un test, modifiez le paramètre d'entrée pour qu'il corresponde au protocole ou au port que vous avez défini dans la règle de transfert.
Aucun backend n'est configuré pour la règle de transfert de l'équilibreur de charge. Avant d'exécuter un test, configurez les backends de l'équilibreur de charge.
L'équilibreur de charge dispose de configurations non valides ou incohérentes. Avant d'exécuter un test, corrigez les configurations non valides ou incohérentes.
Le trafic ne peut pas atteindre un équilibreur de charge TCP/UDP interne associé à une région incompatible, car l'équilibreur de charge TCP/UDP interne est un service régional. Avant d'exécuter un test, configurez les composants de l'équilibreur de charge afin qu'ils se trouvent dans la même région.

Étape suivante