Rozwiązywanie problemów: typowe problemy z łącznością agenta

Agent StateWarden został zaprojektowany z myślą o autonomicznej odporności na awarie. Jednak jego zdolność do zabezpieczania infrastruktury zależy w całości od nawiązania poprawnego, wzajemnie uwierzytelnionego (mTLS) połączenia sieciowego z warstwą sterowania Artemis i warstwą danych Driad.

Jeśli urządzenie jest widoczne w panelu jako „Offline" lub nie wykonuje zaplanowanych zadań, przyczyną są niemal zawsze ograniczenia sieciowe na poziomie hosta.

Oto wiążący przewodnik diagnostyki i rozwiązywania problemów z łącznością agenta.

1. Cykl życia agenta

Gdy usługa sw (StateWarden) uruchamia się na maszynie docelowej, wykonuje ścisłą sekwencję rozruchową:

1. Stan oczekiwania na sieć: agent wstrzymuje swoje wewnętrzne procesy robocze, dopóki warstwa sterowania Artemis nie stanie się osiągalna. Zapobiega to awariom agenta we wczesnych fazach rozruchu systemu, zanim stos sieciowy zostanie w pełni zainicjalizowany.
2. Uzgodnienie mTLS: gdy sieć jest dostępna, agent nawiązuje wzajemnie uwierzytelnione połączenie TLS z Artemis przy użyciu swojego unikalnego, lokalnie przechowywanego certyfikatu klienta.
3. Pętla operacyjna: po pomyślnym połączeniu agent utrzymuje trwałe połączenie z warstwą sterowania, przesyła telemetrię systemową (CPU, RAM, status) i oczekuje na zadania, takie jak kopie zapasowe i skany bezpieczeństwa.

2. Podstawowe kroki diagnostyczne

Jeśli agent nie może się połączyć, wykonaj poniższe kontrole bezpośrednio na dotkniętej maszynie hosta.

Kontrola 1: Rozpoznawanie nazw DNS

Agent musi być w stanie rozpoznać nazwy FQDN Twojej infrastruktury StateWarden.

• Działanie: wyslij zapytanie ping do interfejsu API warstwy sterowania (np. api.statewarden.com lub Twojej domeny niestandardowej).
• Rozwiązanie: jeśli nazwa hosta nie jest rozpoznawana, zweryfikuj ustawienia DNS maszyny. W silnie ograniczonych środowiskach korporacyjnych może być konieczne dodanie ręcznych wpisów w lokalnym pliku /etc/hosts lub C:\Windows\System32\drivers\etc\hosts.

Kontrola 2: Reguły zapory dla ruchu wychodzącego (port 443)

StateWarden działa wyłącznie przez standardowy protokół HTTPS (port 443). Nie wymagamy otwierania żadnych portów przychodzących na zaporach. Agent zawsze inicjuje połączenie.

• Działanie: upewnij się, że lokalna zapora maszyny hosta (Zapora Windows Defender, iptables, ufw) zezwala na wychodzący ruch TCP na porcie 443 do zakresów adresów IP StateWarden.
• Działanie: zweryfikuj, czy korporacyjne zapory brzegowe (Palo Alto, Fortinet) nie blokują tego ruchu.

Kontrola 3: Inspekcja głębokich pakietów (DPI) i serwery proxy

To najczęstsza przyczyna niepowodzeń mTLS w środowiskach korporacyjnych. StateWarden używa ścisłego wzajemnego uwierzytelniania TLS (Mutual TLS). Jeśli sieć korporacyjna wykorzystuje serwer proxy typu „Man-in-the-Middle" (MitM) do inspekcji SSL (który przechwytuje ruch, odszyfrowuje go i szyfruje ponownie certyfikatem korporacyjnym), połączenie zakończy się gwałtowną awarią.

• Objaw: logi agenta pokażą tls: unknown certificate authority lub bad certificate. Artemis odrzuci połączenie, ponieważ serwer proxy niszczy unikalny certyfikat klienta agenta w procesie przechwytywania.
• Rozwiązanie: musisz jawnie dodać domeny StateWarden (*.statewarden.com lub Twoje konkretne punkty końcowe) do listy wyjątków w urządzeniu inspekcji SSL, aby ominąć DPI i dopuścić surowy ruch tranzytowy.

3. Odczyt logów agenta

W razie wątpliwości zajrzyj do wewnętrznych logów agenta. StateWarden zapewnia bardzo szczegółowe logowanie na poziomie deweloperskim.

• Linux: journalctl -u statewarden -f
• Windows: otwórz Podgląd zdarzeń lub sprawdź surowe pliki logów, zazwyczaj znajdujące się w C:\ProgramData\StateWarden\logs\.

Typowe sygnatury w logach:

• failed to dial Artemis: connection refused -> adres IP jest rozpoznawany, ale zapora blokuje port 443.
• handshake failure: bad certificate -> certyfikat mTLS jest uszkodzony, unieważniony lub przeszkadza serwer proxy SSL.
• waiting for Artemis health check... -> agent nie ma w ogóle połączenia sieciowego lub zawodzi rozpoznawanie DNS.

4. Wymuszone ponowne parowanie

Jeśli lokalny sejf kryptograficzny agenta ulegnie uszkodzeniu (np. w wyniku katastrofalnej awarii dysku), agent zostanie trwale odcięty od Realmu.

Utraconego certyfikatu agenta nie można „odzyskać". Musisz wymusić ponowne sparowanie urządzenia.

1. W panelu usuń stary wpis urządzenia (spowoduje to unieważnienie jego starego certyfikatu).
2. Wygeneruj nowy kod parowania.
3. Na maszynie hosta całkowicie odinstaluj agenta (co wyczyści lokalny sejf) i zainstaluj go ponownie przy użyciu nowego kodu.

StateWarden: Resilience Engineered.