[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 的证书无效，可以立即关闭连接。反之亦然——
    Zabbix agent 在接受来自服务器的连接时，如果服务器不被 agent 信任，也可以关闭连接。
-   检查双方的日志文件——即 TLS 客户端和 TLS 服务器两端。<br>
    拒绝连接的一方可能会记录连接被拒绝的精确原因。另一方通常只会报告较为笼统的错误（例如：
    “Connection closed by peer”、“connection was non-properly
    terminated”）。
-   有时，加密配置错误会导致令人困惑的错误消息，完全无法指出真正原因。<br>
    在下面的小节中，我们尝试提供一组（远非详尽的）消息及其可能原因，以帮助进行故障排查。<br>
    请注意，不同的加密工具包（OpenSSL、GnuTLS）在相同的问题场景下通常会产生不同的错误消息。<br>
    有时，错误消息甚至还取决于双方所使用加密工具包的具体组合。

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