3 Dépannage

Recommandations générales

• Commencez par déterminer quel composant agit en tant que client TLS et lequel agit en tant que serveur TLS dans le cas problématique.
  Le serveur Zabbix, les proxies et les agents, selon l'interaction entre eux, peuvent tous fonctionner comme serveurs TLS et clients TLS.
  Par exemple, le serveur Zabbix qui se connecte à un agent pour un contrôle passif agit comme un client TLS. L'agent joue le rôle de serveur TLS.
  Un agent Zabbix qui demande une liste de contrôles actifs à un proxy agit comme un client TLS. Le proxy joue le rôle de serveur TLS.
  Les utilitaires zabbix_get et zabbix_sender agissent toujours comme des clients TLS.
• Zabbix utilise une authentification mutuelle.
  Chaque côté vérifie son pair et peut refuser la connexion.
  Par exemple, le serveur Zabbix qui se connecte à un agent peut fermer la connexion immédiatement si le certificat de l'agent n'est pas valide. Et inversement, un agent Zabbix qui accepte une connexion du serveur peut fermer la connexion si le serveur n'est pas approuvé par l'agent.
• Examinez les fichiers journaux des deux côtés - du client TLS et du serveur TLS.
  Le côté qui refuse la connexion peut enregistrer une raison précise expliquant pourquoi elle a été refusée. L'autre côté signale souvent une erreur plus générale (par ex. "Connection closed by peer", "connection was non-properly terminated").
• Parfois, un chiffrement mal configuré entraîne des messages d'erreur déroutants qui n'indiquent en rien la cause réelle.
  Dans les sous-sections ci-dessous, nous essayons de fournir une collection (loin d'être exhaustive) de messages et de causes possibles pouvant aider au dépannage.
  Veuillez noter que différents outils cryptographiques (OpenSSL, GnuTLS) produisent souvent des messages d'erreur différents dans les mêmes situations problématiques.
  Parfois, les messages d'erreur dépendent même de la combinaison particulière des outils cryptographiques utilisés des deux côtés.