[comment]: # translation:outdated [comment]: # ({ad64ebf5-ad64ebf5}) # 3 Rozwiązywanie problemów [comment]: # ({/ad64ebf5-ad64ebf5}) [comment]: # ({12be222f-385ec312}) #### Ogólne zalecenia - Zacznij od ustalenia, który komponent działa jako klient TLS, a który jako serwer TLS w danym przypadku problemowym.
Serwer Zabbix, proxy i agenty, w zależności od interakcji między nimi, mogą działać zarówno jako serwery TLS, jak i klienci TLS.
Na przykład serwer Zabbix łączący się z agent w celu wykonania sprawdzenia pasywnego działa jako klient TLS. Agent pełni rolę serwera TLS.
Agent Zabbix, żądający listy aktywnych sprawdzeń od proxy, działa jako klient TLS. Proxy pełni rolę serwera TLS.
Narzędzia `zabbix_get` i `zabbix_sender` zawsze działają jako klienci TLS. - Zabbix używa wzajemnego uwierzytelniania.
Każda strona weryfikuje swojego partnera i może odrzucić połączenie.
Na przykład serwer Zabbix łączący się z agent może natychmiast zamknąć połączenie, jeśli certyfikat agent jest nieprawidłowy. I odwrotnie — agent Zabbix akceptujący połączenie od serwera może zamknąć połączenie, jeśli serwer nie jest zaufany przez agent. - Sprawdź pliki dziennika po obu stronach — po stronie klienta TLS i serwera TLS.
Strona, która odrzuca połączenie, może zapisać dokładny powód jego odrzucenia. Druga strona często zgłasza raczej ogólny błąd (np. „Połączenie zamknięte przez partnera”, „połączenie zostało nieprawidłowo zakończone”). - Czasami błędnie skonfigurowane szyfrowanie skutkuje mylącymi komunikatami o błędach, które w żaden sposób nie wskazują rzeczywistej przyczyny.
W poniższych podsekcjach staramy się przedstawić (daleki od wyczerpującego) zbiór komunikatów i możliwych przyczyn, które mogą pomóc w rozwiązywaniu problemów.
Należy pamiętać, że różne biblioteki kryptograficzne (OpenSSL, GnuTLS) często generują różne komunikaty o błędach w tych samych sytuacjach problemowych.
Czasami komunikaty o błędach zależą nawet od konkretnej kombinacji bibliotek kryptograficznych po obu stronach. [comment]: # ({/12be222f-385ec312})