Guide de résolution des problèmes

Cette page fournit un guide de dépannage de base. Si vous ne parvenez pas à résoudre les problèmes rencontrés lors de l’utilisation de la fonctionnalité MSP (Metadata Security Protocol), contactez notre équipe de support technique.

Échecs de déploiement d'une nouvelle machine virtuelle ou d'ensembles de machines virtuelles

Fenêtres

Dans Windows, la plateforme installe automatiquement les composants nécessaires : GPA et eBPF pour Windows. Si l’installation échoue :

1. Vérifiez que vous utilisez une version < : lien vers la matrice de compatibilité ici.
2. Vérifier que le code d’échec est lié au MSP< : lien vers les erreurs possibles
3. Recommencez le déploiement. Les défaillances temporaires font partie du cloud computing.

Si le problème persiste, contactez le support.

Linux

Vérifiez que vous utilisez une image valide

• Le GPA doit être inclus dans votre image pour permettre le déploiement avec MSP activé.
• Votre version cloud-init doit être une version plus récente prenant en charge le MSP. Si ce n’est pas le cas, une condition de concurrence se produit entre lui et le GPA.

L’échec exact dépend de si/comment votre image est mal configurée ou si une défaillance de plateforme s’est produite :

MSP activé, mais non appliqué dans des machines virtuelles existantes ou des ensembles de machines virtuelles

Pour éviter les interruptions de service lors de l’activation du MSP sur une machine virtuelle existante ou sur des ensembles de machines virtuelles, les protections ne sont pas appliquées tant que la machine virtuelle n’indique pas avoir correctement établi sa configuration et acquis la clé de longue durée. Ce délai signifie que le modèle de machine virtuelle peut montrer que le MSP est activé. Toutefois, le service GPA peut toujours être défectueux et indiquer que les protections ne sont pas activées.

Confirmation que le problème existe toujours

Parfois, le délai est plus élevé que prévu. Pour commencer, vérifiez le rapport d’état du service GPA :

1. Obtenir status.json fichier :

Machine virtuelle Windows :
Les journaux générés par ProxyAgent depuis l'intérieur de la machine virtuelle sont plus détaillés ; le dossier contenant ces journaux est C:\WindowsAzure\ProxyAgent\Logs

Le service status.json ProxyAgent a capturé son état global dans C:\WindowsAzure\ProxyAgent\Logs\status.json

Machine virtuelle Linux : Journaux ProxyAgent à partir des machines virtuelles, car ils ont plus de détails, le dossier des journaux d’activité est /var/log/azure-proxy-agent/

Le service status.json azure-proxy-agent capture son état global dans /var/log/azure-proxy-agent/status.json

2. Vérifiez proxyAgentStatus dans le fichier json et assurez-vous qu'il affiche « SUCCESS ». Si ce n'est pas « SUCCESS », vérifiez ces autres états :

Service GPA manquant ou non fonctionnel

Machine virtuelle Windows

Control Resource Plane (CRP) installe implicitement ces services Windows à l’aide d’extensions invitées :

• Service De l’Agent proxy invité Windows (GPA) (GuestProxyAgent)
• pilotes de noyau ebpf-for-windows : eBPFCore, NetEbpfExt

Machine virtuelle Linux

Pour les machines virtuelles Linux, l’agent de proxy invité Linux (GPA) doit être inséré dans son image de base, ou l’utilisateur ajoute explicitement l’extension Microsoft.CPlat.ProxyAgent.ProxyAgentLinux de machine virtuelle GPA avant d’activer la fonctionnalité MSP.

Conditions préalables

• Noyau Linux 5.15 ou version ultérieure, qui a toutes nos fonctionnalités eBPF requises ;
• cgroup2 monté par défaut, le service GPA connecte l’événement cgroup/connect4 eBPF.

Lors de l’activation du MSP, CRP installe un service azure-proxy-agent sur la machine virtuelle.

# systemctl status azure-proxy-agent.service 
● azure-proxy-agent.service - Microsoft Azure GuestProxyAgent
     Loaded: loaded (/lib/systemd/system/azure-proxy-agent.service; enabled; vendor preset: enabled)
     Active: active (running) since Fri 2024-09-13 18:52:00 UTC; 1 week 5 days ago
   Main PID: 4040671 (azure-proxy-age)
      Tasks: 10 (limit: 19169)
     Memory: 491.2M
        CPU: 1d 8h 13min 2.321s
     CGroup: /system.slice/azure-proxy-agent.service
             └─4040671 /usr/sbin/azure-proxy-agent

Le service GPA est en cours d'exécution, mais ne peut pas être configuré.

Échec de l’installation d’eBPF

Machine virtuelle Windows

Les services eBPFCore et NetEbpfExt doivent être en RUNNING état,

c:\>sc query eBPFCore

SERVICE_NAME: eBPFCore
        TYPE               : 1  KERNEL_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

c:\>sc query NetEbpfExt

SERVICE_NAME: NetEbpfExt
        TYPE               : 1  KERNEL_DRIVER
        STATE              : 4  RUNNING
                                (STOPPABLE, NOT_PAUSABLE, IGNORES_SHUTDOWN)
        WIN32_EXIT_CODE    : 0  (0x0)
        SERVICE_EXIT_CODE  : 0  (0x0)
        CHECKPOINT         : 0x0
        WAIT_HINT          : 0x0

Machine virtuelle Linux :

Échec du chargement du programme eBPF

GPA utilise certaines fonctionnalités eBPF qui nécessitent le noyau Linux 5.15 ou version ultérieure. Si le client tente d’activer la fonctionnalité MSP sur une version de distribution Linux non prise en charge, vous pouvez voir le message similaire à :

    "ebpfProgramStatus": {
      "status": "STOPPED",
      "message": "Failed to load program 'connect4' with error: the BPF_PROG_LOAD syscall failed. Verifier output: ; int connect4(struct bpf_sock_addr *ctx)\n0: (bf) r6 = r1\n; __u64 cookie = bpf_get_socket_cookie(ctx);\n1: (85) call bpf_get_socket_cookie#46\n2: (b7) r1 = 0\n; destination_entry entry = {0};\n3: (63) *(u32 *)(r10 -44) = r1\nlast_idx 3 first_idx 0\nregs=2 stack=0 before 2: (b7) r1 = 0\n4: (63) *(u32 *)(r10 -48) = r1\n5: (63) *(u32 *)(r10 -52) = r1\n; entry.destination_ip.ipv4 = ctx->user_ip4;\n6: (61) r1 = *(u32 *)(r6 +4)\n; entry.destination_ip.ipv4 = ctx->user_ip4;\n7: (63) *(u32 *)(r10 -56) = r1\n; entry.destination_port = ctx->user_port;\n8: (61) r1 = *(u32 *)(r6 +24)\n; entry.destination_port = ctx->user_port;\n9: (63) *(u32 *)(r10 -40) = r1\n; entry.protocol = ctx->protocol;\n10: (61) r1 = *(u32 *)(r6 +36)\n; entry.protocol = ctx->protocol;\n11: (63) *(u32 *)(r10 -36) = r1\n12: (bf) r2 = r10\n; \n13: (07) r2 += -56\n; destination_entry *policy = bpf_map_lookup_elem(&policy_map, &entry);\n14: (18) r1 = 0xffff8baa17403400\n16: (85) cal..."
    },

Essayez d'obtenir la version du noyau à l'aide de uname -r, si elle est inférieure à 5.15, désactivez la fonctionnalité MSP, mettez à jour votre image système vers la dernière version et activez la fonctionnalité MSP.

Échec de l’attachement du programme cgroup pour la redirection

ProxyAgent invité nécessite que cgroup2 soit monté par défaut pour raccorder l’événement cgroup/connect4 eBPF. Si le client tente d’activer la fonctionnalité MSP sur une version de distribution Linux non prise en charge, vous pouvez voir le message suivant :

• status.json

    "ebpfProgramStatus": {
      "status": "STOPPED",
      "message": "Failed to attach program 'connect4' with error: `bpf_link_create` failed"
    },

• Vérifiez si la machine virtuelle Linux actuelle prend en charge CGroup2 en utilisant grep cgroup /proc/filesystems.

grep cgroup /proc/filesystems

S’il nodev cgroup2 est répertorié, cela signifie que cgroup v2 est pris en charge par ce système d’exploitation ; s’il n’est pas répertorié, désactivez la fonctionnalité MSP, mettez à jour vers cette dernière version du système d’exploitation, puis activez la fonctionnalité MSP.

• Vérifiez si CGroup2 est monté par défaut à l’aide de mount | grep cgroup2

mount | grep cgroup2

S’il n’y a pas d’enregistrement affiché, demandez au propriétaire de la machine virtuelle de la configurer avec la commande ci-dessous, puis redémarrez la machine virtuelle.

sudo grubby --update-kernel=ALL --args="systemd.unified_cgroup_hierarchy=1"

Échec de l’acquisition de la clé, clé rejetée.

Le GPA n’a pas pu acquérir de clé, car la plateforme ne l’offre plus. Des actions telles que la migration d’un disque vers une nouvelle machine virtuelle ou la suppression du disque du système d’exploitation des machines virtuelles et leur remplacement peuvent entraîner cette défaillance.

Suivez les instructions de réinitialisation de clé/récupération de clé. La réinitialisation de la clé permet à la plateforme d’en offrir une nouvelle. Le GPA tente périodiquement de se rétablir. Une fois la réinitialisation terminée, le GPA acquiert automatiquement une nouvelle clé et revient à un état sain.

Récupération de clé / réinitialisation de clé

Si la clé de longue durée de votre machine virtuelle est perdue, elle ne communique plus avec le service de métadonnées d’instance (IMDS) ou Wireserver. Sans la clé, un nouveau ne peut pas être émis en toute sécurité sur la machine virtuelle automatiquement. En outre, si la clé est compromise d’une certaine manière, elle doit être réinitialisée pour garantir la maintenance de la sécurité.

Réinitialisation d’une clé

1. Reportez-vous à Réinitialisation de clé pour obtenir une documentation complète sur la KeyIncarnationId déposée de la section ProxyAgentSettings du modèle de machine virtuelle.
2. Sélectionnez une nouvelle valeur KeyIncarnationId et appliquez-la au modèle de machine virtuelle avec une opération PUT

Codes d’erreur généraux