Felsöka MSP

Den här artikeln innehåller några grundläggande felsökningsvägledning för att använda funktionen Metadata Security Protocol (MSP) med virtuella datorer (VM) eller VM-skalningsuppsättningar. Om du inte kan lösa problemet med hjälp av den här vägledningen kontaktar du supportteamet.

Distributionen misslyckades för en ny vm eller vm-skalningsuppsättning

Windows

I Windows installerar plattformen automatiskt nödvändiga komponenter: GPA (Guest Proxy Agent) och eBPF. Om installationen misslyckas:

1. Kontrollera att du använder en operativsystemversion som stöds.
2. Kontrollera att felkoden är MSP-relaterad.
3. Försök att distribuera igen. Tillfälliga fel är en del av molnbaserad databehandling.

Linux

Kontrollera att du använder en giltig avbildning:

• GPA måste ingå i din bild. Det är ett krav för att distribuera med MSP aktiverat.
• Din cloud-init-version måste vara en nyare, MSP-medveten version. Om så inte är fallet uppstår ett kapplöpningstillstånd mellan det och GPA.

Det exakta felet beror på om avbildningen är felkonfigurerad eller om ett plattformsfel har inträffat:

MSP är aktiverat men inte tillämpat

För att undvika tjänststörningar när du aktiverar MSP på en befintlig virtuell dator eller vm-skalningsuppsättning tillämpas inte skydd förrän den virtuella datorn anger att den har konfigurerat och hämtat den långvariga nyckeln. Den här fördröjningen innebär att VM-modellen kan visa att MSP är aktiverat. GPA kan dock ändå fortfarande vara ohälsosamt och indikera att skydden inte är aktiverade.

Bekräfta att problemet fortfarande finns

Ibland är fördröjningen längre än förväntat. Börja genom att kontrollera statusrapporten för GPA:

1. Hämta status.json filen:

   • För en virtuell Windows-dator loggar ProxyAgent-tjänsten inifrån de virtuella datorerna eftersom de har mer information. Loggmappen är C:\WindowsAzure\ProxyAgent\Logs. ProxyAgent fångar upp sin övergripande status i C:\WindowsAzure\ProxyAgent\Logs\status.json.

   • För en virtuell Linux-dator loggar ProxyAgent-tjänsten (azure-proxy-agent) inifrån de virtuella datorerna eftersom de har mer information. Loggmappen är /var/log/azure-proxy-agent/. ProxyAgent samlar in sin övergripande status i /var/log/azure-proxy-agent/status.json.

2. Kontrollera proxyAgentStatus i status.json filen och kontrollera att värdet är SUCCESS. Om det inte är SUCCESS kontrollerar du följande andra status:

   Läge	Förväntat värde
   keyLatchStatus	RUNNING
   ebpfProgramStatus	RUNNING
   proxyListenerStatus	RUNNING

Betygsgenomsnittet saknas eller körs inte

Virtuell Windows-dator

Control Resource Plane (CRP) installerar implicit dessa Windows-tjänster med hjälp av gästtillägg:

• GPA: GuestProxyAgent
• Kerneldrivrutiner för eBPF: eBPFCore, NetEbpfExt

Virtuell Linux-dator

För virtuella Linux-datorer måste GPA inkluderas i basavbildningen. Eller så kan du uttryckligen lägga till GPA VM-tillägget Microsoft.CPlat.ProxyAgent.ProxyAgentLinux innan du aktiverar MSP-funktionen.

Förutsättningar är:

• Linux kernel 5.15 eller senare, som har alla nödvändiga eBPF-funktioner.
• Funktionen cgroup v2 monterad som standard. GPA kopplar ihop eBPF-händelsen cgroup/connect4.

När du aktiverar MSP installerar CRP en tjänst (azure-proxy-agent) på den virtuella datorn.

# 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

GPA körs, men du kan inte konfigurera det

Fel vid eBPF-installation

För att eBPF-installationen ska lyckas eBPFCore och NetEbpfExt måste vara i ett RUNNING tillstånd.

Här är koden som visar RUNNING tillståndet för en virtuell Windows-dator:

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

Här är koden som visar RUNNING tillståndet för en virtuell Linux-dator:

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

Det gick inte att läsa in eBPF

GPA använder vissa eBPF-funktioner som kräver Linux-kernel 5.15 eller senare. Om du försöker aktivera MSP-funktionen på en Linux-distribution som inte stöds kan du se ett meddelande som liknar det här exemplet:

    "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..."
    },

Prova att hämta kärnversionen med hjälp av uname -r. Om versionen är tidigare än 5.15 avregistrerar du dig från MSP-funktionen, uppgraderar os-avbildningen till den senaste versionen och aktiverar sedan MSP.

Det gick inte att koppla cgroup för omdirigering

GuestProxyAgent kräver att cgroup v2 monteras som standard för att koppla upp cgroup/connect4 eBPF-händelser. Om du försöker aktivera MSP-funktionen i en Linux-distribution som inte stöds kan du se ett meddelande som i följande status.json exempel:

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

Prova följande metoder för att lösa problemet:

• Kontrollera om den aktuella virtuella Linux-datorn stöder cgroup v2 med hjälp av det här kommandot:

  grep cgroup /proc/filesystems
  

  Om nodev cgroup2 visas stöder det här operativsystemet cgroup v2. Om nodev cgroup2 inte visas väljer du bort MSP-funktionen, uppdaterar till den senaste operativsystemversionen och aktiverar sedan MSP.

• Kontrollera om cgroup v2 är monterat som standard. Använd följande kommando:

  mount | grep cgroup2
  

  Om ingen post visas ber du den virtuella datorns ägare att konfigurera den med hjälp av följande kommando och sedan starta om den virtuella datorn:

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

Det gick inte att hämta en nyckel eller avvisad nyckel

GPA kan inte hämta en nyckel om plattformen inte längre erbjuder den. Åtgärder som att migrera en disk till en ny virtuell dator eller ta bort den virtuella datorns OS-disk och ersätta den kan orsaka det här felet.

Följ anvisningarna för att återställa en nyckel i den här artikeln. Om du återställer nyckeln kan plattformen erbjuda en ny. GPA försöker med jämna mellanrum återhämta sig. När du har slutfört återställningen hämtar GPA automatiskt en ny nyckel och återgår till ett felfritt tillstånd.

Du måste återställa en nyckel

Om den virtuella datorns långvariga nyckel går förlorad kommunicerar den inte längre med Azure Instance Metadata Service eller WireServer. Utan nyckeln kan en ny inte utfärdas på ett säkert sätt till den virtuella datorn automatiskt. Om nyckeln komprometteras på något sätt måste den dessutom återställas för att upprätthålla säkerheten.

Så här återställer du en nyckel:

1. Se Återställa en låst nyckel för fullständig dokumentation om KeyIncarnationId fältet i ProxyAgentSettings avsnittet i VM-modellen.
2. Välj ett nytt KeyIncarnationId värde och tillämpa det på den virtuella datormodellen med hjälp av en PUT åtgärd.

Du har en felkod