[comment]: # ({ad64ebf5-ad64ebf5})
# 3 故障排除

[comment]: # ({/ad64ebf5-ad64ebf5})

[comment]: # ({12be222f-385ec312})
#### 一般建议

-   首先要弄清在问题场景中，哪个组件充当 TLS 客户端，哪个组件充当 TLS 服务器。<br>
    Zabbix 服务器、proxy 和 agent，取决于它们之间的交互，都可以作为 TLS 服务器和客户端。<br>
    例如，Zabbix 服务器连接 agent 进行被动检查时，充当 TLS 客户端。agent 则充当 TLS 服务器。<br>
    Zabbix agent 从 proxy 请求主动检查列表时，充当 TLS 客户端。proxy 则充当 TLS 服务器。<br>
    `zabbix_get` 和 `zabbix_sender` 工具始终充当 TLS
    客户端。
-   Zabbix 使用双向认证。<br>
    双方都会验证对端，并且可能拒绝连接。<br>
    例如，Zabbix 服务器连接 agent 时，如果 agent 的证书无效，可以立即关闭连接。反之亦然 -<br>
    Zabbix agent 接受来自服务器的连接时，如果 agent 不信任服务器，也可以关闭连接。
-   检查 TLS 客户端和 TLS 服务器两端的日志文件。<br>
    拒绝连接的一方通常会记录被拒绝的准确原因。另一方往往只会报告较为笼统的错误（例如
    "Connection closed by peer"、"connection was non-properly
    terminated"）。
-   有时，配置错误的加密会导致令人困惑的错误消息，完全无法指向真正的原因。<br>
    在下面的小节中，我们尝试提供一组（远非穷尽的）消息及其可能原因，以帮助排查问题。<br>
    请注意，不同的加密工具包（OpenSSL、GnuTLS）在相同问题场景下通常会产生不同的错误消息。<br>
    有时，错误消息甚至取决于双方所使用的加密工具包的具体组合。

[comment]: # ({/12be222f-385ec312})