Mesurer la joignabilité

Cette page explique comment les tests de connectivité mesurent la joignabilité. Il explique également comment fonctionnent l'analyse de configuration et l'analyse du plan de données en direct.

Qu'est-ce que la joignabilité ?

Une ressource est joignable à partir d'un autre point de terminaison si les configurations réseau telles que les pare-feu et les routes permettent au trafic de passer de l'un à l'autre. Par exemple, si la configuration réseau doit autoriser la VM1 à envoyer des paquets à la VM2, la VM2 est considérée comme joignable depuis la VM1.

Notez les aspects suivants sur la façon dont les tests de connectivité mesurent la joignabilité:

Les tests de connectivité mesurent la joignabilité d'une source spécifique vers une destination particulière. Le fait que la VM1 puisse joindre la VM2 ne signifie pas nécessairement que la VM3 peut joindre la VM2.
Les tests de connectivité mesurent la joignabilité unidirectionnelle. Le fait que la VM1 puisse ouvrir une connexion vers la VM2 ne signifie pas que la VM2 peut ouvrir une connexion avec la VM1. Les règles de pare-feu peuvent autoriser le trafic dans un sens, mais pas dans l'autre.
Les tests de connectivité mesurent la joignabilité pour un protocole et un port de destination spécifiques. Le fait que la VM1 puisse atteindre la VM2 sur tcp:443 ne signifie pas qu'elle peut l'atteindre sur tcp:80.
Les tests de connectivité ne testent que les configurations réseau VPC Google Cloud susceptibles d'affecter la distribution des paquets de la source à la destination. Ils ne vérifient pas si un serveur valide est en cours d'exécution sur la destination, si des règles de pare-feu du système d'exploitation peuvent bloquer le trafic ou si un logiciel de sécurité bloque un paquet contenant une charge utile de virus.

Le concept de joignabilité provient de la théorie des graphes. D'un point de vue conceptuel, l'intégralité du graphe de joignabilité d'un réseau regroupe tous les points de terminaison en tant que nœuds, associés à des arêtes directionnelles indiquant la joignabilité entre nœuds sources et nœuds de destination.

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 et les règles de pare-feu Google Cloud appliquées à un paquet de test simulé.

Fonctionnement des tests de connectivité

Les tests de connectivité comprennent deux composants principaux : une analyse de configuration et une analyse du plan de données en direct. 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 de test par rapport à un modèle de configuration idéal. Elle est complétée par la fonctionnalité d'analyse en direct du plan de données, qui envoie des paquets pour vérifier l'état du plan de données et fournir des informations de référence 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 aucun contrôle sur les réseaux VPC hébergeant des services gérés par Google, tels que les 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

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 :
- Un nom d'instance de VM
- Une adresse IP source
- Un service App Engine source
- Un environnement Cloud Functions (1re génération)
- Un service Cloud Run
- Un nom d'instance Cloud SQL
- Un nom de cluster pour un plan de contrôle GKE
Un point de terminaison de destination comprenant l'un des éléments suivants et un numéro de port :
- Un nom d'instance de VM
- Une adresse IP de destination
- Un nom d'instance Cloud SQL
- Un nom de cluster pour un plan de contrôle GKE
- Un point de terminaison Private Service Connect

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 réseau suivants sont compatibles avec la VM, l'adresse IP et les services gérés par Google:

TCP
UDP
ICMP
ESP
AH
SCTP
IPIP

Les protocoles réseau suivants sont compatibles avec les connecteurs d'accès au VPC sans serveur:

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 state 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, voir États d'analyse de configuration.

É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 l'analyse du plan de données en direct 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.