This is a translation of the original English documentation page. Help us make it better.

3 トラブルシューティング

一般的な推奨事項

  • 問題が発生した場合、どのコンポーネントが TLS クライアントとして機能し、どのコンポーネントが TLS サーバーとして機能するかを理解することから始めます。サーバー、プロキシ、およびエージェントは、それらの間の相互作用に応じて、すべて TLS サーバーおよびクライアントとして機能します。、Zabbix パッシブチェックのためにエージェントに接続するサーバーは、TLS クライアントとして機能します。 エージェントは TLS サーバーの役割を果たします。エージェントは、プロキシからアクティブなチェックのリストを要求し、TLS クライアントとして機能します。 プロキシは TLS サーバーの役割を果たします。`zabbix_getおよびzabbix_sender` ユーティリティは常に TLS クライアントとして機能します。
  • Zabbix は相互認証を使用します。 それぞれの側がピアを検証し、接続を拒否する場合があります。 たとえば、エージェントに接続している Zabbix サーバーは、エージェントの証明書が無効な場合、すぐに接続を閉じることができます。 逆もまた同様です - サーバーがエージェントによって信頼されていない場合、サーバーからの接続を受け入れるZabbixエージェントは接続を閉じることができます。
  • TLS クライアントと TLS サーバーの両方でログファイルを調べます。、拒否された正確な理由をログに記録する場合があります。 反対側は、かなり一般的なエラーを報告することがよくあります (たとえば、「ピアによって接続が閉じられました」、「接続が正しく終了されませんでした」など)。
  • 暗号化の設定を誤ると、実際の原因を示すものではなく、混乱を招くエラー メッセージが表示されることがあります。 以下のサブセクションでは、トラブルシューティングに役立つ可能性のあるメッセージと考えられる原因の (完全ではない) コレクションを提供しようとしています. さまざまな暗号化ツールキット(OpenSSL、GnuTLS)は、同じ問題の状況で異なるエラー メッセージを生成することがよくあります。 場合によっては、エラー メッセージが両側の暗号化ツールキットの特定の組み合わせに依存することもあります。