Guia de solução de problemas

Esta página fornece um guia básico de solução de problemas. Se você não conseguir resolver os problemas encontrados ao usar o recurso MSP (Protocolo de Segurança de Metadados), entre em contato com nossa equipe de suporte.

Falhas na implantação de novas máquinas virtuais (VM) ou em conjuntos de dimensionamento de máquinas virtuais

Windows

No Windows, a plataforma instala automaticamente os componentes necessários – GPA e eBPF para Windows. Se a instalação falhar:

1. Verifique se você está usando uma versão do sistema operacional compatível< - veja a matriz de compatibilidade aqui.
2. Certifique-se de que o código de falha está relacionado ao MSP< - Link para possíveis erros
3. Repita a implantação. Falhas transitórias fazem parte da computação em nuvem.

Se o problema persistir, contacte o suporte.

Linux

Verifique se você está usando uma imagem válida

• O GPA deve estar incluído na imagem para implantar com o MSP habilitado.
• Sua versão do cloud-init deve ser mais recente e compatível com MSP. Caso contrário, ocorre uma condição de corrida entre ele e o GPA.

A falha exata depende de se/como sua imagem está configurada incorretamente ou se ocorreu uma falha na plataforma:

MSP habilitado, mas não aplicado em VM existentes ou conjuntos de escala de máquina virtual

Para evitar interrupções do serviço ao habilitar o MSP em uma VM ou Conjuntos de Dimensionamento de Máquinas Virtuais existentes, as proteções não são aplicadas até que a VM indique que foi configurada com êxito e adquira a chave de longa duração. Esse atraso significa que o modelo de VM pode mostrar que o MSP está habilitado. No entanto, o serviço GPA ainda pode não estar íntegro e indicar que as proteções não estão ativadas.

Confirmando que o problema ainda existe

Às vezes, o atraso é maior do que o previsto. Para começar, verifique o relatório de status do serviço GPA:

1. Obter o arquivo status.json.

VM do Windows:
Logs do ProxyAgent de dentro da VM, pois eles têm logs mais detalhados, a pasta de logs é C:\WindowsAzure\ProxyAgent\Logs

O serviço Status.json ProxyAgent capturou seu status geral em C:\WindowsAzure\ProxyAgent\Logs\status.json

VM Linux: logs do ProxyAgent de dentro das VMs, pois eles têm mais detalhes, a pasta de logs é /var/log/azure-proxy-agent/

O serviço status.json azure-proxy-agent captura seu status geral em /var/log/azure-proxy-agent/status.json

2. Verifique proxyAgentStatus no arquivo JSON e certifique-se de que esteja como "SUCCESS". Se não for "SUCCESS", verifique estes outros status:

O serviço GPA está ausente ou não está em execução

Windows VM

O CRP (Plano de Recursos de Controle) instala implicitamente esses serviços do Windows usando extensões de convidado:

• Serviço GPA (Agente proxy convidado do Windows) (GuestProxyAgent)
• Drivers de kernel ebpf-for-windows: eBPFCore, NetEbpfExt

Linux VM

Para VMs Linux, o Agente de Proxy de Convidado (GPA) do Linux deve estar incluído na imagem base ou o usuário deve adicionar explicitamente a Extensão de VM GPA Microsoft.CPlat.ProxyAgent.ProxyAgentLinux antes de habilitar o recurso MSP.

Pré-requisitos

• Linux Kernel 5.15 ou posterior, que tem todos os nossos recursos necessários do eBPF;
• O cgroup2 é montado por padrão, e o serviço GPA se conecta ao evento eBPF cgroup/connect4.

Ao habilitar o MSP, o CRP instala um serviço azure-proxy-agent na VM.

# 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

O serviço GPA está em execução, mas não é possível configurar

Falha na configuração do eBPF

Windows VM

Os serviços eBPFCore e NetEbpfExt devem estar no estado RUNNING,

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

VM Linux:

Falha ao carregar o programa eBPF

O GPA usa alguns recursos do eBPF que exigem o kernel 5.15 ou posterior do Linux. Se o cliente estiver tentando habilitar o recurso MSP em uma versão de distribuição sem suporte do Linux, você poderá ver a mensagem semelhante a:

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

Tente obter a versão do kernel usando uname -r. Se ela for menor que 5.15, desative o recurso MSP, atualize a imagem do seu sistema operacional para a versão mais recente e, então, habilite o recurso MSP.

Falha ao anexar o programa cgroup para redirecionamento

O Guest ProxyAgent requer o cgroup2 montado por padrão para anexar o evento eBPF cgroup/connect4. Se o cliente estiver tentando habilitar o recurso MSP em uma versão de distribuição sem suporte do Linux, você poderá ver a mensagem como:

• status.json

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

• Verifique se a VM atual do Linux dá suporte ao CGroup2 usando grep cgroup /proc/filesystems,

grep cgroup /proc/filesystems

Se nodev cgroup2 estiver listado, significa que o cgroup v2 tem suporte por esse sistema operacional; se não estiver listado, desative o recurso MSP, atualize para a versão mais recente deste sistema operacional e então habilite o recurso MSP.

• Verificar se o CGroup2 está montado por padrão usando mount | grep cgroup2

mount | grep cgroup2

Se não houver nenhum registro exibido, peça ao proprietário da VM para configurá-lo com o comando abaixo e, em seguida, reinicialize a VM.

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

Falha ao adquirir a chave / chave rejeitada

O GPA não foi capaz de adquirir uma chave, porque a plataforma não está mais oferecendo-a. Ações como migrar um disco para uma nova VM ou excluir o disco do sistema operacional de VMs e substituí-lo podem causar essa falha.

Siga as instruções de recuperação de chave/redefinição de chave. Redefinir a chave permite que a plataforma ofereça uma nova. O GPA tenta se recuperar periodicamente. Depois que a redefinição é concluída, o GPA adquire automaticamente uma nova chave e volta para um estado saudável.

Recuperação de chave/redefinição de chave

Se a chave de longa duração da VM for perdida, ela não se comunicará mais com o IMDS (Serviço de Metadados de Instância) ou o Wireserver. Sem a chave, um novo não pode ser emitido com segurança para a VM automaticamente. Além disso, se a chave estiver comprometida de alguma forma, ela deverá ser redefinida para garantir que a segurança seja mantida.

Redefinindo uma chave

1. Consulte a Redefinição de Chave para obter a documentação completa sobre o campo KeyIncarnationId da seção ProxyAgentSettings do modelo de VM.
2. Selecione um novo KeyIncarnationId valor e aplique-o ao modelo de VM com uma PUT operação