Rozwiązywanie problemów z programem MSP

Ten artykuł zawiera kilka podstawowych wskazówek dotyczących rozwiązywania problemów dotyczących używania funkcji protokołu METADATA Security Protocol (MSP) z maszynami wirtualnymi lub zestawami skalowania maszyn wirtualnych. Jeśli nie możesz rozwiązać problemu, korzystając z tych wskazówek, skontaktuj się z zespołem pomocy technicznej.

Wdrożenie nie powiodło się dla nowej maszyny wirtualnej lub zestawu skalowania maszyn wirtualnych

Windows

W systemie Windows platforma automatycznie instaluje niezbędne składniki: Guest Proxy Agent (GPA) i eBPF. Jeśli instalacja zakończy się niepowodzeniem:

1. Upewnij się, że używasz obsługiwanej wersji systemu operacyjnego.
2. Upewnij się, że kod błędu jest powiązany z programem MSP.
3. Ponów próbę wdrożenia. Błędy przejściowe są częścią przetwarzania w chmurze.

Linux

Upewnij się, że używasz prawidłowego obrazu:

• GpA musi być uwzględniony na obrazie. Jest to wymaganie dotyczące wdrażania z włączonym programem MSP.
• Wersja pakietu cloud-init musi być nowszą wersją z obsługą programu MSP. Jeśli tak nie jest, dochodzi do sytuacji wyścigu między nim a GPA.

Dokładna awaria zależy od tego, czy obraz został nieprawidłowo skonfigurowany, czy wystąpił błąd platformy:

Program MSP jest włączony, ale nie jest stosowany

Aby uniknąć przerw w działaniu usługi podczas włączania programu MSP na istniejącej maszynie wirtualnej lub zestawie skalowania maszyn wirtualnych, ochrona nie jest stosowana, dopóki maszyna wirtualna nie wskaże, że pomyślnie skonfigurowała i nabyła klucz długotrwały. To opóźnienie oznacza, że model maszyny wirtualnej może pokazać, że program MSP jest włączony. Jednak gpA może nadal być w złej kondycji i wskazywać, że zabezpieczenia nie są aktywowane.

Upewnij się, że problem nadal istnieje

Czasami opóźnienie jest dłuższe niż oczekiwano. Aby rozpocząć, sprawdź raport o stanie gpa:

1. status.json Pobierz plik:

   • W przypadku maszyny wirtualnej z systemem Windows dzienniki usługi ProxyAgent są rejestrowane z wewnątrz tych maszyn, ponieważ zawierają więcej szczegółów. Folder dziennika to C:\WindowsAzure\ProxyAgent\Logs. Serwer proxyAgent przechwytuje jego ogólny stan w pliku C:\WindowsAzure\ProxyAgent\Logs\status.json.

   • W przypadku maszyny wirtualnej z systemem Linux usługa ProxyAgent (azure-proxy-agent) rejestruje dzienniki z wnętrza maszyn wirtualnych, ponieważ zawierają one więcej szczegółów. Folder dziennika to /var/log/azure-proxy-agent/. Serwer proxyAgent przechwytuje jego ogólny stan w pliku /var/log/azure-proxy-agent/status.json.

2. Sprawdź proxyAgentStatus w pliku status.json i upewnij się, że wartość to SUCCESS. Jeśli to nie jest SUCCESS, sprawdź inne statusy:

   Stan	Oczekiwana wartość
   keyLatchStatus	RUNNING
   ebpfProgramStatus	RUNNING
   proxyListenerStatus	RUNNING

GPA jest nieobecny lub nie działa.

Maszyna wirtualna z systemem Windows

Płaszczyzna zasobów kontroli (CRP) niejawnie instaluje te usługi systemu Windows przy użyciu rozszerzeń gościa:

• GPA: GuestProxyAgent
• Sterowniki jądra dla eBPF: eBPFCore, NetEbpfExt

Maszyna wirtualna z systemem Linux

W przypadku maszyn wirtualnych z systemem Linux, GPA musi być uwzględnione w obrazie podstawowym. Możesz też jawnie dodać rozszerzenie maszyny wirtualnej GPA Microsoft.CPlat.ProxyAgent.ProxyAgentLinux przed włączeniem funkcji MSP.

Wymagania wstępne są następujące:

• Jądro systemu Linux w wersji 5.15 lub nowszej, które ma wszystkie wymagane funkcje eBPF.
• Funkcja cgroup w wersji 2 jest instalowana domyślnie. GPA integruje zdarzenie cgroup/connect4 eBPF.

Po włączeniu MSP, CRP instaluje jedną usługę (azure-proxy-agent) w maszynie wirtualnej.

# 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 działa, ale nie można jej skonfigurować

Niepowodzenie instalacji eBPF

Aby konfiguracja eBPF powiodła się, eBPFCore i NetEbpfExt muszą być w stanie RUNNING.

Oto kod pokazujący RUNNING stan maszyny wirtualnej z systemem Windows:

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

Oto kod pokazujący RUNNING stan maszyny wirtualnej z systemem Linux:

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

Nie można załadować eBPF

GpA używa niektórych funkcji eBPF, które wymagają jądra systemu Linux 5.15 lub nowszego. Jeśli próbujesz włączyć funkcję MSP w nieobsługiwanej dystrybucji systemu Linux, może zostać wyświetlony komunikat podobny do tego przykładu:

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

Spróbuj pobrać wersję jądra przy użyciu polecenia uname -r. Jeśli wersja jest starsza niż 5.15, zrezygnuj z funkcji MSP, uaktualnij obraz systemu operacyjnego do najnowszej wersji, a następnie włącz msp.

Nie można dołączyć grupy cgroup na potrzeby przekierowania

GuestProxyAgent wymaga, aby domyślnie była zamontowana grupa cgroup v2, aby połączyć zdarzenia cgroup/connect4 eBPF. Jeśli spróbujesz włączyć funkcję MSP w nieobsługiwanej dystrybucji systemu Linux, może zostać wyświetlony komunikat podobny do następującego status.json przykładu:

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

Aby rozwiązać ten problem, wypróbuj następujące metody:

• Sprawdź, czy bieżąca maszyna wirtualna z systemem Linux obsługuje narzędzie cgroup v2 przy użyciu tego polecenia:

  grep cgroup /proc/filesystems
  

  Jeśli nodev cgroup2 jest wyświetlany, ten system operacyjny obsługuje grupę cgroup w wersji 2. Jeśli nodev cgroup2 nie ma na liście, zrezygnuj z funkcji MSP, zaktualizuj do najnowszej wersji systemu operacyjnego, a następnie włącz program MSP.

• Sprawdź, czy grupa cgroup v2 jest domyślnie instalowana. Użyj następującego polecenia:

  mount | grep cgroup2
  

  Jeśli nie pojawi się żaden rekord, poproś właściciela maszyny wirtualnej o jego skonfigurowanie przy użyciu następującego polecenia, a następnie uruchom ponownie maszynę wirtualną:

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

Nie można uzyskać klucza lub odrzuconego klucza

GPA nie może uzyskać klucza, jeśli platforma nie oferuje go już. Akcje, takie jak migrowanie dysku do nowej maszyny wirtualnej lub usunięcie dysku systemu operacyjnego maszyny wirtualnej i zastąpienie go, mogą spowodować ten błąd.

Postępuj zgodnie z instrukcjami dotyczącymi resetowania klucza w tym artykule. Zresetowanie klucza pozwala platformie na zaoferowanie nowego. GPA okresowo próbuje się poprawić. Po zakończeniu resetowania GPA automatycznie uzyskuje nowy klucz i wraca do normalnego stanu.

Musisz zresetować klucz

Jeśli klucz trwały maszyny wirtualnej zostanie utracony, nie komunikuje się już z usługą Azure Instance Metadata Service ani z WireServer. Bez klucza nie można bezpiecznie automatycznie wydać nowego klucza dla maszyny wirtualnej. Ponadto, jeśli klucz zostanie naruszony w jakiś sposób, należy go zresetować, aby zachować bezpieczeństwo.

Aby zresetować klucz:

1. Odniesienie do Resetowanie zatrzaśniętego klucza w celu uzyskania pełnej dokumentacji KeyIncarnationId w sekcji ProxyAgentSettings modelu maszyny wirtualnej.
2. Wybierz nową KeyIncarnationId wartość i zastosuj ją do modelu maszyny wirtualnej przy użyciu PUT operacji.

Został wyświetlony kod błędu