Les tests de connectivité sont un outil de diagnostic qui vous permet de vérifier la connectivité entre les points de terminaison du réseau. Il analyse votre configuration et, dans certains cas, effectue une analyse du plan de données en direct entre les points de terminaison. Un point de terminaison est une source ou une destination de trafic réseau, telle qu'une VM, un cluster Google Kubernetes Engine (GKE), une règle de transfert de l'équilibreur de charge ou une adresse IP sur Internet.
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 analyse du plan de données en direct. 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 d'analyse du plan de données en direct.
Pour savoir comment créer et exécuter des tests pour différents scénarios, consultez Créer et exécuter des tests de connectivité.
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, 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 et utilisé 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.
L'analyse peut prendre de nombreux chemins possibles.
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 Compute Engine : une à gauche et une à droite.
L'analyse dépend de votre infrastructure réseau
Selon les configurations de vos ressources et réseau Google Cloud , ce trafic peut transiter par un tunnel Cloud VPN, un réseau VPC, un équilibreur de charge Google Cloud ou un réseau VPC appairé avant d'atteindre l'instance Compute Engine de destination.
L'analyse suit l'un des nombreux états finis.
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. Si une route basée sur des règles est configurée, le test de connectivité achemine le paquet vers le saut suivant, qui est un équilibreur de charge interne.
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 Google Cloud utilisée pour renvoyer les routes. En effet, cette méthode est interne à Google Cloudet 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é peut toujours exécuter un test et fournir un résultat global de joignabilité pour les services gérés par Google, mais elle ne fournit 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 Compute Engine 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 instances Compute Engine, 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, consultez les exemples de test de la page Tester la connectivité vers et depuis 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.
Points de terminaison sources
L'analyse de configuration des tests de connectivité est compatible avec les points de terminaison sources suivants :
- Instance Compute Engine
- Révision Cloud Run
- Cloud Run Functions (1re génération)
- Environnement standard App Engine
- Instance Cloud SQL
- Plan de contrôle GKE
- Adresse IP Internet
- Adresse IP d'un réseau sur site
- Adresse IP d'une instance Compute Engine
- Adresse IP d'une instance Cloud SQL
- Adresse IP d'un plan de contrôle GKE
- Adresse IP non attribuée dans un réseau de cloud privé virtuel
Points de terminaison de destination
L'analyse de configuration des tests de connectivité est compatible avec les points de terminaison de destination suivants :
- Instance Compute Engine
- Instance Cloud SQL
- Plan de contrôle GKE
- Équilibreur de charge d'application externe et interne
- Équilibreur de charge réseau proxy externe et interne
- Équilibreur de charge réseau passthrough externe et interne
- Point de terminaison Private Service Connect
- Memorystore for Redis Cluster
- Instance Memorystore pour Redis
- Adresse IP Internet
- Adresse IP d'un réseau sur site
- Adresse IP d'une règle de transfert
- Adresse IP d'une instance Compute Engine
- Adresse IP d'une instance Cloud SQL
- Adresse IP d'un plan de contrôle GKE
- Adresse IP d'un cluster Memorystore pour Redis
- Adresse IP d'une instance Memorystore pour Redis
Fonctionnalités de mise en réseauGoogle Cloud
Vous pouvez tester la connectivité entre les ressources qui utilisent les fonctionnalités suivantes (IPv4 et IPv6 sont compatibles, le cas échéant) :
- Réseaux VPC
- Appairage de réseaux VPC
- VPC partagé
- Accès privé à Google
- Cloud Load Balancing
- Plages d'adresses IP d'alias
- Adresses IPv4 publiques utilisées en mode privé
- Instances Compute Engine avec plusieurs interfaces réseau
- Routage VPC
- Règles de pare-feu VPC
- Stratégies de pare-feu de réseau régionales
- Stratégies de pare-feu hiérarchiques et stratégies de pare-feu réseau mondiales
- Tags Resource Manager pour les pare-feu, y compris lorsqu'ils sont associés à des instances Compute Engine avec plusieurs interfaces réseau
- Routes basées sur des règles
- Private Service Connect
- Instances avec des adresses IPv6, y compris les instances avec plusieurs interfaces réseau
- Spokes VPC et spokes hybrides pour Network Connectivity Center
- Public NAT et Private NAT
- Cloud VPN
- Cloud Interconnect
- Cloud Router, y compris les routes dynamiques utilisant BGP et les routes statiques.
Points à prendre en compte pour Cloud Load Balancing
Pour Cloud Load Balancing, l'analyse de configuration des tests de connectivité est compatible avec les fonctionnalités suivantes :
- Tester la connectivité aux adresses IP de l'équilibreur de charge
- Vérifier la connectivité des vérifications de l'état de Cloud Load Balancing aux backends
- Les équilibreurs de charge TCP/UDP internes peuvent être utilisés comme sauts suivants.
Pour connaître les fonctionnalités de Cloud Load Balancing qui ne sont pas compatibles, consultez la section Configurations non compatibles.
Pour savoir comment Tests de connectivité analyse les backends d'un équilibreur de charge, consultez Nombre de traces dans un test vers un équilibreur de charge.
Points à prendre en compte pour Google Kubernetes Engine
Pour GKE, l'analyse de la configuration des tests de connectivité est compatible avec les fonctionnalités suivantes :
- Connectivité vers et entre les nœuds GKE et le plan de contrôle GKE
- Connectivité au service GKE via Cloud Load Balancing
La connectivité vers un pod GKE dans un cluster de VPC natif est compatible. Toutefois, certaines fonctionnalités de mise en réseau GKE, comme les règles de réseau GKE, ne sont pas compatibles.
Pour connaître les fonctionnalités de GKE qui ne sont pas compatibles, consultez la section Configurations non compatibles.
Points à prendre en compte pour les points de terminaison sans serveur
Les adresses IP sources des points de terminaison sans serveur sont généralement non déterministes. Pour chaque série de tests, les tests de connectivité sélectionnent une adresse IP aléatoire parmi le pool d'adresses disponibles pour le point de terminaison sans serveur. Pour obtenir des informations générales sur la façon dont les adresses IP sont attribuées aux points de terminaison sans serveur, consultez les pages suivantes :
- Pour la connectivité externe, consultez Adresses IP.
- Pour la connectivité via un connecteur d'accès au VPC sans serveur, consultez Envoyer du trafic sans serveur vers un réseau de cloud privé virtuel.
- Pour la connectivité via la sortie VPC directe, consultez Allocation d'adresses IP. Ce type de connectivité n'est disponible que pour Cloud Run.
Dans certains cas, la sortie VPC directe et les connecteurs d'accès au VPC sans serveur sont configurés pour acheminer le trafic des points de terminaison sans serveur via une connectivité externe au lieu du réseau de cloud privé virtuel, en fonction des paramètres de sortie.
Pour connaître les fonctionnalités sans serveur qui ne sont pas compatibles, consultez la section Configurations non compatibles.
Configurations non compatibles
L'analyse de configuration des tests de connectivité ne permet pas de tester les configurations réseau suivantes :
- Les règles de stratégie de pare-feu avec des objets de géolocalisation, des données de renseignements sur les menaces ou des objets de nom de domaine complet ne sont pas acceptées. Si de tels pare-feu peuvent potentiellement affecter un flux de trafic spécifique, les tests de connectivité renvoient un avertissement correspondant.
- Les backends NEG Internet ciblant des noms de domaine complets ne sont pas acceptés. Toutefois, les backends NEG Internet ciblant des adresses IP sont acceptés.
- Les équilibreurs de charge Cloud Service Mesh avec les règles de transfert
INTERNAL_SELF_MANAGEDne sont pas compatibles. - 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 équilibreur de charge d'application.
- Les passerelles VPN haute disponibilité connectées à des instances Compute Engine ne sont pas compatibles.
- Les règles de réseau GKE et les configurations de mascarade d'adresse IP ne sont pas prises en compte ni appliquées lors du traçage de connectivité vers des adresses IP dans les clusters et nœuds GKE.
- Les instances répliquées de serveur externe Cloud SQL définies par des noms DNS ne sont pas acceptées. Toutefois, les répliques de serveur externes définies par des adresses IP sont acceptées.
- Les fonctions Cloud Run (2e génération) ne sont pas compatibles. Toutefois, vous pouvez tester la connectivité d'une fonction Cloud Run (2e génération) en créant un test de connectivité pour la révision Cloud Run sous-jacente. Une révision Cloud Run est créée chaque fois qu'une fonction Cloud Run est déployée.
- L'environnement flexible App Engine n'est pas compatible.
- Les jobs Cloud Run ne sont pas acceptés. Pour en savoir plus, consultez Services, jobs, and worker pools: three ways to run your code (Services, jobs et pools de nœuds de calcul : trois façons d'exécuter votre code).
Fonctionnement des tests de connectivité pour analyser le plan de données en direct
La fonctionnalité d'analyse du plan de données en direct teste la connectivité en envoyant plusieurs paquets de vérification du point de terminaison source vers la destination. Si la destination n'est pas une ressource Google Cloud , la connectivité est testée entre le point de terminaison source et l'emplacement périphérique du réseau.
Les résultats de l'analyse du plan de données en direct 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, l'analyse du plan de données en direct affiche également les informations médianes et les informations de latence à sens unique dans le 95e centile. Lorsque la destination est une adresse IP Internet, l'analyse du plan de données en direct envoie des vérifications et affiche les résultats pour chaque routeur de périphérie du réseau Google par lequel le trafic peut être acheminé.
Limites
L'analyse du plan de données en direct peut ne pas couvrir tous les chemins réseau possibles :
- Si le point de terminaison de destination est un équilibreur de charge Google Cloud avec plusieurs backends, chaque sonde d'analyse du plan de données en direct est envoyée à un backend aléatoire. Certains backends peuvent être testés par de nombreuses sondes, tandis que d'autres peuvent ne pas être testés du tout.
- En cas de routage ECMP (Equal-Cost Multi-Path), chaque sonde d'analyse du plan de données en direct est transférée par une route aléatoire. Certains chemins de routage peuvent être testés par de nombreuses sondes, tandis que d'autres peuvent ne pas l'être du tout.
- Le nombre de vérifications d'analyse du plan de données en direct ne dépend pas du nombre de chemins réseau existants. Il est possible qu'il n'y ait pas assez de vérifications d'analyse du plan de données en direct pour tester chaque chemin possible.
Si vous constatez des écarts évidents entre les résultats de l'analyse de la configuration et ceux de l'analyse du plan de données en direct, consultez la page Résoudre les problèmes liés aux tests de connectivité.
Configurations compatibles
L'analyse du plan de données en direct est compatible avec un sous-ensemble des configurations testées par l'analyse de configuration des tests de connectivité.
Points de terminaison sources
L'analyse du plan de données en direct est compatible avec les points de terminaison sources suivants :
- Instance Compute Engine
- Point de terminaison sans serveur configuré avec un connecteur d'accès au VPC sans serveur et associé à l'une des ressources suivantes :
- Instance Cloud SQL
- Plan de contrôle GKE
Points de terminaison de destination
L'analyse du plan de données en direct est compatible avec les points de terminaison de destination suivants :
- Instance Compute Engine
- Équilibreur de charge réseau passthrough interne
- Private Service Connect avec un équilibreur de charge réseau passthrough interne du producteur
- Adresse IP Internet, testée au niveau de l'emplacement de périphérie réseau
- Rattachement de VLAN pour Cloud Interconnect
- Point de terminaison privé associé à l'une des ressources suivantes :
- Instance Cloud SQL
- Memorystore for Redis Cluster
- Instance Memorystore pour Redis
- Plan de contrôle GKE
Protocoles
L'analyse du plan de données en direct est compatible avec les protocoles TCP et UDP.
Fonctionnalités de mise en réseauGoogle Cloud
L'analyse du plan de données en direct est compatible avec les fonctionnalités suivantes :
- Réseaux VPC
- Appairage de réseaux VPC
- VPC partagé
- Spokes VPC et spokes hybrides dans Network Connectivity Center
- Plages d'adresses IP d'alias
- Adresses IP externes
- Adresses IP internes, y compris les adresses IPv4 publiques utilisées en mode privé
- Instances Compute Engine avec plusieurs interfaces réseau
- Routage VPC
- Public NAT et Private NAT, à l'exception de NAT64
- Règles de pare-feu VPC
- Stratégies de pare-feu hiérarchiques, stratégies de pare-feu réseau mondiales, et stratégies de pare-feu réseau régionales
- Tags sécurisés pour les pare-feu, y compris lorsqu'ils sont associés à des instances Compute Engine avec plusieurs interfaces réseau
- Routes basées sur des règles
- Instances avec des adresses IPv6, y compris les instances avec plusieurs interfaces réseau
Configurations non compatibles
L'analyse du plan de données en direct n'est pas compatible avec les configurations réseau suivantes et n'est pas exécutée pour celles-ci :
- Ressources nonGoogle Cloud en tant que points de terminaison sources :
- Adresses IP Internet
- Trafic entrant vers Google Cloud via Cloud Interconnect, Cloud VPN et les spokes hybrides Network Connectivity Center
- Adresses IP non attribuées dans un réseau VPC en tant que points de terminaison sources
- Les points de terminaison source et de destination sont la même instance Compute Engine
- Instances Compute Engine non en cours d'exécution
- API et services Google
- Équilibreur de charge d'application externe et interne
- Équilibreur de charge réseau proxy externe et interne
- Équilibreur de charge réseau passthrough externe
- Cloud VPN
- NAT64
Remarques et contraintes
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 deliveredd'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 l'analyse du plan de données en direct complètent les résultats de l'analyse de la configuration en vérifiant si les paquets transmis arrivent à 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 Compute Engine, 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é.
L'analyse du plan de données en direct 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 Compute Engine configurées pour modifier le comportement de transfert
Les tests de connectivité ne peuvent pas tester les instances Compute Engine configurées pour agir dans le plan de données en tant que routeurs, pare-feu, passerelles NAT ou VPN. Ce type de configuration rend difficile l'évaluation de l'environnement s'exécutant sur l'instance Compute Engine. De plus, l'analyse du plan de données en direct n'est pas compatible avec ce type de 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 dépend de la taille de la configuration de votre réseau VPC et du 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 Compute Engine, un tunnel Cloud VPN et des équilibreurs de charge Google Cloud.
| 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 |
L'analyse du plan de données en direct n'est pas conçue pour la surveillance continue
L'analyse du plan de données en direct 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.
Compatibilité avec VPC Service Controls
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.