3 Risoluzione dei problemi

Raccomandazioni generali

• Iniziare comprendendo quale componente agisce come client TLS e quale come server TLS nel caso problematico.
  Zabbix server, proxy e agent, a seconda dell'interazione tra loro, possono tutti funzionare sia come server TLS sia come client TLS.
  Ad esempio, Zabbix server che si connette a un agent per un controllo passivo agisce come client TLS. L'agent svolge il ruolo di server TLS.
  Zabbix agent, che richiede un elenco di controlli attivi da un proxy, agisce come client TLS. Il proxy svolge il ruolo di server TLS.
  Le utility zabbix_get e zabbix_sender agiscono sempre come client TLS.
• Zabbix utilizza l'autenticazione reciproca.
  Ciascuna parte verifica il proprio peer e può rifiutare la connessione.
  Ad esempio, Zabbix server che si connette a un agent può chiudere immediatamente la connessione se il certificato dell'agent non è valido. E viceversa: Zabbix agent che accetta una connessione dal server può chiudere la connessione se il server non è considerato attendibile dall'agent.
• Esaminare i file di log su entrambi i lati: nel client TLS e nel server TLS.
  Il lato che rifiuta la connessione può registrare un motivo preciso del rifiuto. L'altro lato spesso riporta un errore piuttosto generico (ad es. "Connection closed by peer", "connection was non-properly terminated").
• Talvolta una configurazione errata della crittografia produce messaggi di errore fuorvianti che non indicano in alcun modo la causa reale.
  Nelle sottosezioni seguenti cerchiamo di fornire una raccolta (tutt'altro che esaustiva) di messaggi e possibili cause che potrebbero aiutare nella risoluzione dei problemi.
  Si noti che diversi toolkit crittografici (OpenSSL, GnuTLS) producono spesso messaggi di errore diversi nelle stesse situazioni problematiche.
  Talvolta i messaggi di errore dipendono persino dalla particolare combinazione di toolkit crittografici su entrambi i lati.