Présentation des tests de connectivité

Les tests de connectivité se présentent comme un outil de diagnostic qui vous permet de vérifier la connectivité entre les points de terminaison de votre réseau. Ils analysent votre configuration et, dans certains cas, procèdent à la vérification de l'exécution.

Pour analyser les configurations réseau, les tests de connectivité simulent le chemin de transfert attendu d'un paquet via votre réseau cloud privé virtuel (VPC), vos tunnels Cloud VPN ou vos rattachements de VLAN. Les tests de connectivité permettent également de simuler le chemin de transfert entrant attendu vers les ressources de votre réseau VPC.

Dans certaines configurations de connectivité, les tests de connectivité effectuent également une vérification de l'exécution. Cette fonctionnalité envoie des paquets sur le plan de données pour valider la connectivité et fournit des diagnostics de base relatifs à la latence à et la perte de paquets. En cas de compatibilité de la route avec la fonctionnalité, chaque test que vous exécutez inclut un résultat de validation dynamique. Cette fonctionnalité est actuellement disponible en aperçu.

L'API pour les tests de connectivité est l'API Network Management. Pour plus d'informations, consultez la section Documentation sur l'API.

Pourquoi utiliser les tests de connectivité ?

Les tests de connectivité peuvent vous aider à résoudre les problèmes de connectivité réseau suivants :

  • Configurations incohérentes imprévues
  • Configurations obsolètes causées par des modifications de configuration de réseau ou des migrations
  • Erreurs de configuration de divers services et fonctions réseau

Lorsque vous testez des services gérés par Google (bêta), les tests de connectivité peuvent également vous aider à déterminer s'il y a un problème dans votre réseau VPC ou sur le réseau VPC appartenant à Google pour les ressources de service.

Analyse des configurations par les tests de connectivité

Lors de l'analyse des configurations réseau, les tests de connectivité utilisent une machine à états abstraits pour modéliser un mode de traitement des paquets par un réseau VPC. Google Cloud traite un paquet en plusieurs étapes logiques.

En raison de la diversité des services et fonctionnalités du réseau VPC compatibles avec l'analyse de configuration, un paquet de test passant une configuration de réseau VPC peut emprunter de nombreux chemins possibles.

Le schéma suivant présente un modèle indiquant comment l'analyse de configuration simule le trafic de trace entre deux instances de machines virtuelles (VM) Compute Engine : une à gauche et une sur la droite.

Selon les configurations de vos ressources et réseau Google Cloud, ce trafic peut transiter par un tunnel Cloud VPN, un équilibreur de charge Google Cloud ou un réseau VPC appairé avant d'atteindre l'instance de VM de destination.

Machine à états abstraits sur le réseau
Machine à états abstraits sur le réseau

Le nombre limité d'étapes entre des états discrets jusqu'à ce qu'un paquet ait été livré ou abandonné est modélisé en tant que machine d'état fini. Cette machine à états finis peut se trouver exactement dans un certain nombre d'états finis à la fois et avoir plusieurs états successeurs.

Par exemple, lorsque les tests de connectivité détectent des correspondances entre plusieurs routes selon les priorités définies, Google Cloud peut choisir l'une de ces routes sur la base d'une fonction de hachage non spécifiée dans le plan de données.

Dans le cas précédent, les tests de connectivité renvoient les traces de toutes les routes possibles, mais ne peuvent pas déterminer la méthode utilisée par Google Cloud pour renvoyer les routes. En effet, cette méthode est interne à Google Cloud et peut varier.

Services gérés par Google

Les services gérés par Google, tels que Cloud SQL et Google Kubernetes Engine (GKE), allouent des ressources pour les clients dans les projets et les réseaux VPC détenus et gérés par Google. Les clients ne sont pas autorisés à accéder à ces ressources.

L'analyse de configuration des tests de connectivité peuvent toujours exécuter un test et fournir un résultat global de joignabilité pour les services gérés par Google, mais ils ne fournissent pas de détails sur les ressources testées dans le projet appartenant à Google.

Le schéma suivant illustre la manière dont l'analyse de configuration simule le trafic de trace d'une instance de VM dans un réseau VPC client vers une instance Cloud SQL sur le réseau VPC appartenant à Google. Dans cet exemple, les réseaux sont connectés via l'appairage de réseaux VPC.

Comme pour un test standard entre deux VM, la procédure logique consiste à vérifier le pare-feu de sortie et à faire correspondre la route. Lorsque vous exécutez un test, l'analyse de configuration des tests de connectivité fournit des détails sur ces étapes. Cependant, pour la dernière étape logique d'analyse de la configuration dans le réseau VPC appartenant à Google, l'analyse ne fournit qu'un résultat global de joignabilité. Les tests de connectivité ne fournissent pas de détails sur les ressources du projet appartenant à Google, car vous ne disposez pas des autorisations nécessaires pour les afficher.

Pour en savoir plus, reportez-vous aux exemples de test de la section Tester les services gérés par Google dans le document Cas d'utilisation courants.

Machine à états abstraits sur le réseau pour les services gérés par Google.
Machine à états abstraits sur le réseau pour les services gérés par Google

Configurations compatibles

L'analyse de la configuration des tests de connectivité permet de tester les configurations réseau décrites dans les sections suivantes.

Flux de trafic

  • Instances de VM vers et depuis Internet
  • Instance de VM vers instance de VM
  • De Google Cloud vers et depuis les réseaux sur site
  • Entre deux réseaux sur site connectés via Network Connectivity Center

Fonctionnalités de mise en réseau VPC

Vous pouvez tester la connectivité entre les ressources qui utilisent les fonctionnalités suivantes :

Solutions de mise en réseau hybride Google Cloud

Les solutions de mise en réseau hybride suivantes sont compatibles :

Network Connectivity Center

Network Connectivity Center est pris en charge.

Cloud NAT

Cloud NAT est compatible.

Cloud Load Balancing

  • La connectivité aux équilibreurs de charge Google Cloud suivants est assurée : équilibreurs de charge HTTP(S) externes, équilibreurs de charge réseau, équilibreurs de charge HTTP(S) internes, équilibreurs de charge TCP/UDP internes, équilibreurs de charge proxy TCP et équilibreurs de charge proxy SSL.
  • La connectivité vers les adresses IP de l'équilibreur de charge est compatible.
  • La connectivité des vérifications de l'état de Cloud Load Balancing vers les backends est compatible. Les backends peuvent être des groupes d'instances ou des groupes de points de terminaison de réseau (NEG).

Pour connaître les fonctionnalités de Cloud Load Balancing qui ne sont pas compatibles, consultez la section Configurations non compatibles.

Google Kubernetes Engine (GKE)

  • La connectivité vers et entre les nœuds GKE et le maître GKE est compatible.
    • Lors du test de l'adresse IP privée d'un maître de cluster GKE, l'analyse de configuration des tests de connectivité détermine si le paquet peut être distribué au maître. Cela inclut l'analyse de la configuration au sein du réseau VPC appartenant à Google. Il s'agit d'une fonctionnalité bêta.
    • Lors du test de l'adresse IP publique d'un maître de cluster GKE, l'analyse de configuration des tests de connectivité détermine si le paquet peut être envoyé au réseau VPC appartenant à Google sur lequel le maître s'exécute. Cela n'inclut pas l'analyse de la configuration au sein du réseau VPC appartenant à Google.
  • La connectivité vers le service GKE via Cloud Load Balancing est compatible.
  • La connectivité vers un pod GKE dans un cluster de VPC natif est compatible.

Pour connaître les fonctionnalités de GKE qui ne sont pas compatibles, consultez la section Configurations non compatibles.

Autres produits et services Google Cloud

Les autres produits ou services Google Cloud suivants sont compatibles :

  • Les instances Cloud SQL sont compatibles.
    • Lors du test de l'adresse IP privée d'une instance Cloud SQL, l'analyse de la configuration détermine si le paquet peut être remis à l'instance. Cela inclut l'analyse de la configuration au sein du réseau VPC appartenant à Google. Il s'agit d'une fonctionnalité bêta.
    • Lors du test de l'adresse IP publique d'une instance Cloud SQL, les tests de connectivité déterminent si le paquet peut être envoyé au réseau VPC appartenant à Google sur lequel l'instance s'exécute. Cela n'inclut pas l'analyse de la configuration au sein du réseau VPC appartenant à Google.

Configurations non compatibles

L'analyse de configuration des tests de connectivité ne permet pas de tester les configurations réseau suivantes :

  • Les règles Google Cloud Armor ne sont pas prises en compte ni appliquées lors du traçage de connectivité vers l'adresse IP externe d'un équilibrage de charge HTTP(S) externe.
  • Règles de réseau GKE. Les tests de connectivité ne prennent pas en compte les règles de réseau lors du traçage de connectivité vers des adresses IP dans les clusters GKE.
  • Un équilibreur de charge HTTP(S) externe qui utilise des buckets Cloud Storage n'est pas compatible.
  • Les instances Cloud SQL qui utilisent des adresses IP publiques ne sont pas compatibles.

Fonctionnement des tests de connectivité pour analyser le plan de données en direct

La fonctionnalité de validation dynamique teste la connectivité en envoyant plusieurs paquets de trace du point de terminaison source vers la destination. Les résultats de la validation dynamique indiquent le nombre de vérifications envoyées, le nombre de vérifications ayant atteint la destination et l'état de joignabilité. Cet état est déterminé en fonction du nombre de vérifications remises avec succès, comme décrit dans le tableau suivant.

État Nombre de vérifications ayant atteint leur destination
Accessible Au moins 95 %
Inaccessible Aucun
Partiellement accessible Plus de 0 et moins de 95 %

En plus d'afficher le nombre de paquets ayant bien été distribués, la validation dynamique affiche également les informations médianes et les informations de latence à sens unique dans le 95e centile.

La validation dynamique ne dépend pas de l'analyse de configuration. Au lieu de cela, la validation dynamique fournit une évaluation indépendante de l'état de la connectivité.

Si vous constatez des écarts évidents entre l'analyse de configuration et les résultats de la validation dynamique, consultez la page Dépannage.

Configurations compatibles

La validation dynamique est compatible avec les configurations réseau suivantes.

Flux de trafic

  • Instance de VM vers instance de VM
  • Protocoles IP : TCP, UDP

Fonctionnalités de mise en réseau VPC

Vous pouvez vérifier de manière dynamique la connectivité entre les ressources qui utilisent les fonctionnalités suivantes :

Configurations non compatibles

Dans la version bêta initiale, toutes les configurations qui ne sont pas explicitement répertoriées comme étant compatibles ne sont pas acceptées. En outre, les configurations pour lesquelles la connectivité est bloquée par des règles de pare-feu de sortie ne sont pas acceptées.

Pour un test donné, si la fonctionnalité de validation dynamique n'est pas exécutée, N/A ou - apparaissent dans le champ Résultat concernant la dernière transmission de paquets.

Remarques

Tenez compte des considérations suivantes lorsque vous décidez d'utiliser les tests de connectivité.

L'analyse de configuration effectuée par les tests de connectivité est entièrement basée sur des informations de configuration pour les ressources Google Cloud et peut ne pas représenter l'état ou le statut réel du plan de données d'un réseau VPC.

Bien que les tests de connectivité intègrent certaines informations de configuration dynamique, telles que l'état du tunnel Cloud VPN et les routes dynamiques sur Cloud Router, ils n'accèdent pas à la vérification d'état de l'infrastructure de production interne de Google et aux composants du plan de données.

L'état Packet could be delivered d'un test de connectivité ne garantit pas que le trafic peut passer par le plan de données. Le but du test est de valider les problèmes de configuration pouvant entraîner une baisse de trafic.

Pour les routes compatibles, les résultats de la validation dynamique complètent les résultats de l'analyse de configuration en testant si les paquets transmis atteignent la destination.

Les tests de connectivité ne reconnaissent pas les réseaux en dehors de Google Cloud

Les réseaux externes sont définis comme suit :

  • Réseaux sur site résidant dans votre centre de données ou autre installation dans laquelle vous exploitez vos périphériques matériels et applications logicielles
  • Autres fournisseurs de cloud sur lesquels vous exécutez des ressources
  • Hôte sur Internet qui envoie du trafic vers votre réseau VPC

Les tests de connectivité n'effectuent pas le suivi des connexions de pare-feu

Le suivi de connexion des pare-feu VPC stocke des informations sur les connexions nouvelles et établies et permet d'autoriser ou de limiter le trafic suivant en fonction de ces informations.

L'analyse de la configuration des tests de connectivité ne prend pas en charge le suivi des connexions de pare-feu, car la table de connexion de pare-feu, située dans le plan de données d'une instance de VM, est inaccessible. Cependant, l'analyse de configuration peut simuler le suivi des connexions en autorisant une connexion de retour qui serait normalement refusée par une règle de pare-feu d'entrée, à condition que la connexion sortante soit initiée par les tests de connectivité.

La validation dynamique n'est pas compatible avec le test du suivi de la connexion du pare-feu.

Les tests de connectivité ne peuvent pas tester les instances de VM configurées pour modifier le comportement de transfert

Les tests de connectivité ne peuvent pas tester les instances de VM configurées pour agir dans le plan de données en tant que routeurs, pare-feu, passerelles NAT, VPN, etc. Ce type de configuration rend difficile l'évaluation de l'environnement s'exécutant sur l'instance de VM. En outre, la validation dynamique n'est pas compatible avec ce scénario de test.

Les délais de résultat des tests de connectivité peuvent varier

L'obtention des résultats des tests de connectivité peut prendre de 30 secondes à 10 minutes. La durée d'un test est basée sur la taille de votre configuration de réseau VPC et le nombre de ressources Google Cloud que vous utilisez.

Le tableau suivant montre les temps de réponse attendus pour tous les utilisateurs exécutant un test par rapport à un exemple de configuration dans une requête. Cette configuration contient des instances de VM, un tunnel Cloud VPN et des équilibreurs de charge Google Cloud.

Temps de réponse par requête
Envergure du projet Nombre de ressources Google Cloud Latence de réponse
Petit projet Moins de 50 60 secondes pour 95 % des requêtes de tous les utilisateurs
Projet moyen Supérieur à 50, mais inférieur à 5 000 120 secondes pour 95 % des requêtes de tous les utilisateurs
Grand projet Supérieur à 5 000 600 secondes pour 95 % des requêtes de tous les utilisateurs

La validation dynamique n'est pas conçue pour la surveillance continue

La validation dynamique effectue une vérification unique de la connectivité réseau à des fins de diagnostic. Pour une surveillance continue de la connectivité et de la perte de paquets, utilisez Performance Dashboard.

La validation dynamique ne teste pas plusieurs traces

La validation dynamique n'est pas disponible dans les cas où la route n'est pas déterministe.

Qu'est-ce que la joignabilité ?

La joignabilité est la capacité d'atteindre une ressource Google Cloud ou de déterminer si un chemin existe d'une ressource Google Cloud à une autre. Ce terme provient de la théorie des graphes appliquée aux réseaux informatiques. Le graphique de joignabilité complet contient tous les points de terminaison du réseau, ainsi que la joignabilité entre chaque paire de points de terminaison du réseau.

L'analyse de joignabilité est un terme plus générique qui décrit le corps d'une analyse pouvant être effectuée pour déterminer la joignabilité du réseau. L'un des cas d'utilisation d'une analyse de joignabilité est un test de connectivité. Dans ce cas, le terme connectivité désigne l'état des connexions réseau.

Pour chaque étape du chemin de transfert réseau, une analyse de joignabilité teste la configuration réseau sous-jacente et fournit les résultats correspondants. Par exemple, les tests de connectivité analysent les routes appliquées au paquet de test simulé, ainsi que les règles de pare-feu VPC.

Fonctionnement des tests de connectivité

Les tests de connectivité comprennent deux composants principaux : une analyse de configuration et une vérification dynamique. Cette section décrit le fonctionnement de ces deux types d'analyses.

Fonctionnement de l'analyse de configuration

Cette section décrit le fonctionnement des tests de connectivité et de ses composants.

Les tests de connectivité effectuent une analyse de joignabilité qui évalue les ressources Google Cloud de votre chemin d'accès à un modèle de configuration idéal. Cette fonctionnalité est renforcée par la fonctionnalité de validation dynamique, qui envoie des paquets pour vérifier l'état du plan de données et fournir des informations de base pour les configurations compatibles. Pour en savoir plus sur le fonctionnement de la validation dynamique, consultez la section Fonctionnement de l'analyse du plan de données en direct.

En tant qu'administrateur réseau, vous contrôlez de nombreuses configurations pouvant affecter le résultat de l'analyse, bien que certaines exceptions s'appliquent. Par exemple, vous n'avez pas de contrôle sur les réseaux VPC qui hébergent des services gérés par Google, tels que des instances Cloud SQL. En outre, en raison de restrictions d'autorisation, il est possible que vous n'ayez pas le contrôle sur les règles de stratégies de pare-feu hiérarchiques qui affectent votre réseau.

Lorsque vous exécutez un test de connectivité, vous définissez un ensemble spécifique de paramètres d'entrée et recevez des résultats formatés sous la forme d'une trace réseau ou d'une requête. Un test de connectivité génère plusieurs traces si un test comporte plusieurs chemins possibles dans le réseau, par exemple lorsque le point de terminaison de destination est un équilibreur de charge Google Cloud avec plusieurs backends.

  • Une correspondance signifie que les tests de connectivité détectent une configuration Google Cloud qui permet au paquet simulé de poursuivre le chemin de test.
  • Aucune correspondance signifie qu'aucune correspondance n'est détectée par les tests de connectivité. Il n'existe donc pas de configuration.
  • Une correspondance refusée signifie que les tests de connectivité détectent une configuration Google Cloud dans laquelle le paquet de tests simulé doit être supprimé.

Composants des tests de connectivité

Un test de connectivité est le composant de premier niveau qui contient tous les autres sous-composants de test requis pour l'analyse de configuration. Ces composants comprennent les éléments suivants :

  • Points de terminaison source et destination
  • Détails sur la joignabilité pour le test et ses traces, dont un résultat de joignabilité global déterminé par l'analyse de configuration
  • Une ou plusieurs traces contenant chacune une ou plusieurs étapes
  • Un état pour chaque étape

Chaque test porte un nom unique et chaque étape comporte un état et des métadonnées Info qui lui sont associées. Par exemple, si une étape vérifie une route, les métadonnées RouteInfo sont incluses dans cette étape.

Le schéma suivant montre le test de connectivité d'une instance de VM Compute Engine vers une autre. Pour obtenir une description des composants de test, consultez les sections suivantes.

Machine à états pour une trace de VM à VM
Machine à états pour une trace de VM à VM

Points de terminaison source et destination

L'analyse de configuration des tests de connectivité est compatible avec un en-tête de paquet à cinq tuples sans port source. En effet, le port source n'est pas utilisé pour valider les ressources dans les configurations réseau Google Cloud. Il n'est donc pas nécessaire de le spécifier lors de l'exécution des tests.

L'en-tête du paquet contient les composants suivants :

  • Un protocole réseau
  • Un point de terminaison source comprenant l'un des éléments suivants :
    • Une adresse IP source
    • Un nom d'instance de VM
    • Un nom de cluster pour un maître GKE (bêta)
    • Un nom d'instance Cloud SQL (bêta)
  • Un point de terminaison de destination composé de l'un des éléments suivants et d'un numéro de port :
    • Une adresse IP de destination
    • Un nom d'instance de VM
    • Un nom de cluster pour un maître GKE (bêta)
    • Un nom d'instance Cloud SQL (bêta)

Pour identifier de manière unique un emplacement réseau, vous pouvez également spécifier un type de réseau Google Cloud ou non-Google Cloud, ou une combinaison d'un type de réseau et d'une adresse IP ou d'un nom d'instance de VM.

Les protocoles de destination suivants sont acceptés pour toute ressource Google Cloud compatible :

  • TCP
  • UDP
  • ICMP
  • ESP
  • AH
  • SCTP
  • IPIP

Les ports de destination pour les protocoles TCP ou UDP sont acceptés. Si vous ne spécifiez pas de port, le paramètre par défaut est le port 80.

Traces, étapes et états

L'analyse de configuration contient une ou plusieurs traces. Chaque trace représente un chemin de transfert de paquets simulé unique dans un test.

  • Chaque trace contient plusieurs étapes ordonnées.
  • Chaque étape contient un état lié à la configuration de Google Cloud que les tests de connectivité vérifient pour cette étape.
  • Les états sont classés en états non finaux et finaux.
États non finaux

Les états non finaux représentent une vérification de la configuration de chaque ressource Google Cloud dans le chemin de test, telle qu'une instance de VM, un point de terminaison, une règle de pare-feu, une route ou un équilibreur de charge Google Cloud.

Les états non finaux sont au nombre de quatre :

  • Initial
  • Vérification de la configuration
  • Transfert
  • Transition

Pour plus d'informations, consultez la section États de test.

État final

Chaque trace doit se terminer par un état final, qui est la dernière étape de la trace.

Les états finaux sont au nombre de quatre :

  • Drop
  • Abort
  • Forward
  • Deliver

Chaque état est associé à un motif. Pour plus d'informations, reportez-vous aux détails de chaque état final.

Résultat global de joignabilité

L'analyse de configuration fournit également un résultat de joignabilité global pouvant accepter l'une des quatre valeurs suivantes : Reachable, Unreachable, Ambiguous ou Undetermined.

La connaissance du résultat global de joignabilité peut être utile pour configurer la surveillance ou l'automatisation.

Pour en savoir plus, consultez la section Résultat global de joignabilité.

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.

Métadonnées

Chaque état peut être associé à des métadonnées sous la forme d'un champ Info. Par exemple, InstanceInfo contient les détails d'une instance de VM, y compris le nom et l'adresse IP.

L'analyse de configuration fournit des métadonnées pour le test lui-même et des métadonnées pour chaque étape d'un test.

Fonctionnement de l'analyse du plan de données en direct

Le mécanisme de vérification de la validation dynamique n'implique pas le système d'exploitation invité et est entièrement transparent pour l'utilisateur. Les vérifications sont injectées pour le compte du point de terminaison source sur le réseau et sont ignorées juste avant d'être transmises au point de terminaison de destination. Les vérifications sont exclues de la facturation réseau standard, des métriques de télémétrie et des journaux de flux.

Compatibilité avec VPC Service Controls (bêta)

VPC Service Controls fournit une sécurité supplémentaire pour les tests de connectivité afin de réduire le risque d'exfiltration de données. À l'aide de VPC Service Controls, vous pouvez ajouter des projets aux périmètres de service afin de protéger les ressources et les services des requêtes provenant de l'extérieur du périmètre.

Pour en savoir plus sur les périmètres de service, consultez la page Informations sur les périmètres de service et configuration de la documentation de VPC Service Controls.

Étape suivante