L'analyseur réseau vous permet de détecter les configurations qui ne fonctionnent pas comme prévu. Ces configurations non valides peuvent être dues à des erreurs de configuration ou à des régressions causées par d'autres modifications. Lorsque différentes équipes sont propriétaires des services affectés par une telle configuration non valide, il peut être difficile de résoudre ces problèmes. La découverte de ces défaillances telles qu'elles se produisent et l'identification des causes fondamentales peuvent aider à accélérer le dépannage et à communiquer efficacement entre les différentes équipes.
Erreurs de configuration dues aux pare-feu bloquants
Les erreurs de configuration du pare-feu qui bloquent les services Google Cloud peuvent se produire pendant ou après la configuration initiale.
Pendant la configuration initiale
Voici quelques-unes des erreurs de pare-feu courantes qui bloquent les services Google Cloud:
- Configuration de pare-feu manquante. Par exemple, le pare-feu de vérification d'état de l'équilibreur de charge n'a pas été configuré.
- Typos dans le processus de configuration manuelle qui entraînent des configurations incorrectes.
- Configuration incohérente causée par des tags de VM manquants. Par exemple, vous pouvez configurer la règle de pare-feu avec les tags de VM cibles attendus, mais certaines VM de backend n'ont pas été associées au tag spécifique.
Après la configuration initiale
Une modification inattendue de la configuration du pare-feu peut interrompre un service qui fonctionne correctement. Par exemple, vous pouvez créer involontairement une règle de refus de pare-feu de priorité plus élevée qui bloque la connectivité aux services GKE ou Cloud SQL.
Scénario: le pare-feu de vérification d'état n'est pas configuré pour l'équilibreur de charge
Dans cet exemple, Network Analyzer signale un insight dans la catégorie des insights d'équilibreur de charge de type le pare-feu de vérification d'état n'est pas configuré La page des détails de l'insight affiche la règle implicite d'entrée interdite dans le réseau sur lequel l'équilibreur de charge est configuré. La règle d'entrée interdite bloque la plage de vérification de l'état. Cela indique que les backends de l'équilibreur de charge ne disposent pas de règles de pare-feu configurées pour autoriser la plage de vérification de l'état.
Configurez la règle de pare-feu de vérification d'état pour autoriser explicitement la plage de vérification d'état à accéder aux backends de l'équilibreur de charge.
Scénario: connectivité du nœud GKE vers le plan de contrôle bloquée par une règle de pare-feu
Dans cet exemple, un insight appartient à la catégorie des insights de connectivité des nœuds GKE de type connectivité de Nœud GKE vers le plan de contrôle est généré.
La page des détails de l'insight indique qu'une règle de pare-feu refuse la connexion du nœud GKE au plan de contrôle d'un cluster. Ce problème est dû à une règle de refus. Supprimez cette règle ou définissez une règle d'autorisation plus élevée pour résoudre le problème.
Scénario: Connectivité du plan de contrôle GKE au nœud bloquée par une règle de pare-feu
Dans cet exemple, un insight appartenant à la catégorie d'insights de connectivité du plan de contrôle GKE de type connectivité du plan de contrôle GKE vers le nœud est généré.
Cette page de détails d'insight indique qu'une règle de pare-feu refuse la connexion entre le plan de contrôle GKE et ses nœuds dans un cluster.
Erreurs de configuration du routage
Les routes avec des sauts suivants non valides peuvent entraîner une perte de trafic partielle ou totale. Cette perte peut être due à des routes vers des VM de saut suivant qui ne sont pas en cours d'exécution ou qui ont été supprimées.
Les modifications de configuration pouvant entraîner une modification de routage inattendue incluent les scénarios suivants:
- L'ajout d'un sous-réseau avec des plages d'adresses IP qui chevauchent une route dynamique entraîne le blocage de la route dynamique, ce qui peut entraîner une perte de trafic.
- L'ajout d'une nouvelle route par défaut via un VPN peut entraîner des goulots d'étranglement qui affectent les performances du réseau.
Scénario: la VM du saut suivant est supprimée
Dans cet exemple, un insight de la catégorie des routes avec des sauts suivants non valides avec le type VM est supprimée s'affiche.
La page des détails de l'insight indique que la VM du saut suivant de cette route est supprimée. Par conséquent, cette route est signalée comme non valide.
Supprimez la route ou créez une instance de VM à utiliser comme saut suivant de la route. Une modification de configuration susceptible de provoquer cet insight s'affiche sur la page des détails de l'insight. Cliquez sur le lien pour accéder à la page Cloud Logging et afficher les détails de la configuration, tels que l'utilisateur qui a effectué la modification et l'heure de la modification.
Scénario: la route dynamique est bloquée
Dans cet exemple, un insight de la catégorie Insights sur les routes dynamiques bloquées catégorie de type entièrement bloquée par la route d'appairage de sous-réseau est généré.
Cette page de détails de l'insight indique qu'une route dynamique importée apprise du pair réseau avec saut suivant de route dynamique de réseau d'appairage est bloquée. La plage d'adresses IP de la route dynamique chevauche une nouvelle route de sous-réseau. Elle est donc bloquée. Le trafic qui atteint le réseau d'appairage vers cette plage d'adresses IP est transféré vers un sous-réseau du réseau VPC.
Scénario: la connectivité à l'instance Cloud SQL est bloquée par l'appairage de réseaux manquant
Dans cet exemple, un insight de la catégorie d'insights de connectivité Cloud SQL de type connectivité à l'instance Cloud SQL bloquée par le problème de routage est affiché.
La page d'insights indique que la connectivité à une instance Cloud SQL est bloquée, car l'appairage de réseaux est manquant.