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 di loro, possono tutti funzionare sia come server TLS sia come client TLS.
  Per esempio, Zabbix server che si connette all'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 dal 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.
  Per esempio, Zabbix server che si connette all'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 esempio "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 di messaggi e possibili cause (ben lontana dall'essere esaustiva) che potrebbe aiutare nella risoluzione dei problemi.
  Si noti che diversi toolkit crittografici (OpenSSL, GnuTLS) spesso producono messaggi di errore diversi nelle stesse situazioni problematiche.
  Talvolta i messaggi di errore dipendono perfino dalla particolare combinazione di toolkit crittografici su entrambi i lati.