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 découvrir comment créer et exécuter des tests dans différents scénarios, consultez Créez et exécutez 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 nombreuses voies 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 de machines virtuelles (VM) Compute Engine : une à gauche et une sur la 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 de VM 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 un route basée sur des règles est configurée, le test de connectivité achemine le paquet vers le prochain saut, 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 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 éléments 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 dans le 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.
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
- Entre deux spokes VPC 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 (les protocoles IPv4 et IPv6 sont tous les deux compatibles, le cas échéant):
- Réseaux VPC
- Appairage de réseaux VPC
- VPC partagé
- Accès privé à Google
- Plages d'adresses IP d'alias
- Adresses IP privées en dehors de la plage d'adresses RFC 1918
- Une instance de VM Compute Engine avec plusieurs interfaces réseau
- Routes personnalisées importées à partir de réseaux VPC appairés
- Routage transitif de VPC
- Règles de pare-feu VPC
- Stratégies de pare-feu de réseau régionales
- les stratégies de pare-feu hiérarchiques ; Stratégies de pare-feu réseau mondiales
- Tags Resource Manager pour les pare-feu s'il est associé à l'instance Compute Engine avec une interface réseau unique.
- Routes basées sur des règles
- Private Service Connect
- Instances à double pile avec des adresses IPv4 et IPv6 y compris des instances avec plusieurs interfaces réseau
Solutions de mise en réseau hybride Google Cloud
Les solutions de mise en réseau hybride suivantes sont compatibles avec les adresses IPv4 et IPv6 :
- Cloud VPN
- Cloud Interconnect
- Cloud Router, y compris les routes dynamiques utilisant BGP et les routes statiques.
Network Connectivity Center
Les spokes VPC et les spokes hybrides pour Network Connectivity Center sont compatibles.
Cloud NAT
Les NAT public et Private NAT sont pris en charge.
Cloud Load Balancing
- Les types d'équilibreurs de charge Google Cloud suivants sont compatibles: équilibreurs de charge d'application externes, équilibreurs de charge réseau passthrough externes, équilibreurs de charge réseau proxy externes, les équilibreurs de charge d'application internes, les équilibreurs de charge réseau passthrough internes et les équilibreurs de charge réseau proxy internes.
- Il est possible de tester la connectivité aux adresses IP de l'équilibreur de charge.
- Vérifier la connectivité des vérifications d'état de Cloud Load Balancing pour est compatible.
- 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.
Google Kubernetes Engine (GKE)
- La connectivité vers et entre les nœuds GKE et le plan de contrôle GKE est compatible.
- Lors du test de l'adresse IP privée d'un plan de contrôle GKE, l'analyse de la configuration des tests de connectivité détermine si le paquet peut être distribué au plan de contrôle. Cela inclut l'analyse de la configuration au sein du réseau VPC appartenant à Google.
- Lors du test de l'adresse IP publique d'un plan de contrôle GKE, l'analyse de la configuration des tests de connectivité détermine si le paquet peut être envoyé au réseau VPC appartenant à Google où le plan de contrôle 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, y compris avec la connexion Private Service Connect, la connexion à l'appairage de réseaux VPC et les instances dupliquées externes.
- 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.
- 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.
- Les fonctions Cloud Run (1re génération) sont compatibles.
- Les révisions Cloud Run sont compatibles.
- L'environnement standard App Engine est compatible.
Configurations non compatibles
L'analyse de configuration des tests de connectivité ne permet pas de tester les configurations réseau suivantes :
- des règles de stratégie de pare-feu avec objets de géolocalisation données CTI sur les menaces ou objets FQDN ne sont pas acceptés.
- Tags Resource Manager pour les pare-feu ne sont pas acceptées si elles sont associées à des instances Compute Engine avec plusieurs interfaces réseau.
- NEG sans serveur et les backends ne sont pas compatibles.
- Les backends NEG Internet ciblant des noms de domaine complets ne sont pas acceptés. Toutefois, les backends NEG Internet et le ciblage par adresses IP sont acceptés.
- Équilibreurs de charge Cloud Service Mesh (avec le paramètre
INTERNAL_SELF_MANAGEDrègles de transfert) ne sont pas acceptées. - Les stratégies Google Cloud Armor ne sont ni prises en compte, ni utilisées lors du traçage de connectivité vers une adresse IP externe d'équilibreur de charge d'application.
- Interfaces Private Service Connect ne sont pas acceptés.
- Passerelles VPN haute disponibilité connectées aux VM Compute Engine ne sont pas acceptés.
- Règles de réseau GKE et masquage d'adresse IP ne sont ni prises en compte, ni utilisées lors du traçage de la connectivité vers des adresses IP au sein des clusters et nœuds GKE.
- Instances dupliquées de serveurs externes Cloud SQL définies par des noms DNS ne sont pas prises en charge. Toutefois, les instances répliquées de serveurs externes définies par des adresses IP sont compatibles.
- Les fonctions Cloud Run (2e génération) ne sont pas compatibles. Cependant, vous pouvez tester la connectivité à partir d'une fonction Cloud Run (2e génération) en créant un Test de connectivité pour le Cloud Run sous-jacent du client. Une révision Cloud Run est créée chaque fois qu'un La fonction Cloud Run est déployée.
- L'environnement flexible App Engine n'est pas compatible.
- Les jobs Cloud Run ne sont pas compatibles. Pour en savoir plus, consultez Services et tâches: deux façons d'exécuter votre code
- Sortie VPC directe Cloud Run n'est pas pris en charge.
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 trace du point de terminaison source vers la destination. 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, la validation dynamique affiche également les informations médianes et les informations de latence à sens unique dans le 95e centile.
L'analyse du plan de données en direct ne dépend pas de l'analyse de la configuration. Au lieu de cela, l'analyse du plan de données en direct fournit une évaluation indépendante de l'état de la connectivité.
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 les configurations réseau suivantes.
Flux de trafic
- Entre deux instances de VM
- Entre une instance de VM et une instance Cloud SQL
- Entre une instance de VM et un point de terminaison de plan de contrôle GKE
- Entre une instance de VM et un emplacement périphérique du réseau Google
- 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 :
- Appairage de réseaux VPC
- VPC partagé
- Plages d'adresses IP d'alias
- Adresses IP externes
- Adresses IP internes, adresses IP privées en dehors de la plage d'adresses RFC 1918
- Routes personnalisées
- Équilibreurs de charge vers votre destination. Les backends compatibles des équilibreurs de charge groupes d'instances Groupes de points de terminaison du réseau (NEG) zonaux et Backends Private Service Connect
- Règles de pare-feu d'entrée, y compris les règles de stratégies de pare-feu hiérarchiques et les règles de pare-feu VPC d'entrée.
- Instances à double pile avec des adresses IPv4 et IPv6, y compris les instances avec plusieurs interfaces réseau
- Points de terminaison Private Service Connect pour les services publiés et les API Google
Configurations non compatibles
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é d'analyse de plan de données en direct n'est pas exécutée, N/A ou - apparaissent dans le champ Résultat concernant la dernière transmission de paquets.
Remarques et contraintes
Tenez compte des considérations suivantes lorsque vous décidez d'utiliser les tests de connectivité.
- L'analyse de la configuration effectuée par les tests de connectivité est basée sur les informations de configuration des ressources Google Cloud peut ne pas représenter l'état réel du plan de données pour une sur le réseau VPC du client.
- Bien que les tests de connectivité acquièrent une configuration dynamique telles que l'état du tunnel Cloud VPN et les routes dynamiques sur Cloud Router, il n'accède pas à l'état de fonctionnement du routeur, l'infrastructure de production interne de Google et les composants du plan de données ;
- État
Packet could be deliveredpour un test de connectivité ne garantit pas que le trafic peut circuler via 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 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é.
L'analyse de plan 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 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. De plus, l'analyse du plan de données en direct 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.
| 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.
L'analyse de plan de données en direct ne teste pas plusieurs traces.
L'analyse de plan de données en direct n'est pas disponible dans les cas où la route n'est pas déterministe.
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.
Étape suivante
Utiliser des tests de connectivité pour différents cas d'utilisation de connectivité
Identifier et résoudre les problèmes liés au protocole ICMP (tutoriel)