[comment]: # translation:outdated

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

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

[comment]: # ({385ec312-385ec312})
#### 通用建议

- 首先明确哪个组件作为TLS客户端
    在问题场景中哪一个充当TLS服务器。
    Zabbix server、proxies和agents，具体取决于交互关系
    它们都可以作为TLS服务器和客户端工作。
    例如，Zabbix server 连接到 agent 进行被动检查，
    充当TLS客户端。agent则扮演TLS服务器角色。
    Zabbix agent，向proxy请求活动检查列表，充当
    一个TLS客户端。proxy 充当TLS服务器角色。
    `zabbix_get` 和 `zabbix_sender` 工具始终以 TLS 方式运行
    客户端
- Zabbix使用双向认证。
    每端验证其对等方并可能拒绝连接。
    例如，Zabbix server 连接到 agent 可以关闭连接
    如果agent的证书无效则立即执行。反之亦然 -
    Zabbix agent 接受来自服务器的连接可能会关闭连接
    如果服务器未被agent信任
-  检查TLS客户端和TLS服务器两端的日志文件。
    拒绝连接的一方可能会记录精确的拒绝原因
    被拒绝。对方通常报告较为通用的错误（例如
    "Connection closed by peer", "connection was non-properly
"对等端关闭连接", "连接未正确
    终止
- 有时加密配置错误会导致令人困惑的错误
    消息完全未指向真实原因。
    在以下小节中，我们尝试提供一份（远非详尽无遗的）
    消息收集及可能原因分析
    故障排除。
    请注意，不同的加密工具包（OpenSSL、GnuTLS）通常
    在相同问题情况下产生不同的错误消息。
    有时错误消息甚至取决于特定的组合
    双方加密工具包

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