0

基盤となる TLS API として gnutls を使用して Web サーバーに接続する NGINX 内で SSL/TLS ストリーム プロキシをテストしています。gnutls (gnutls-serv) でコマンド ライン テスト ツールを使用すると、プロセス全体が機能しますが、ロジックが理解できません。

NGINX クライアント (実際のクライアントから gnutls サーバーへの HTTP 要求をプロキシする) は、接続を複数回ハンドシェイクしたいと考えているようです。実際、ほとんどのテストでは、サーバーがテスト Web ページで応答する前に、エラーなしで 3 回ハンドシェイクするようです。Wireshark を使用するか、メッセージをデバッグするだけで、(gnutls サーバーの観点から) クライアント側のソケットが閉じられ、別のポートで再度開かれているように見えます。最後に、接続が成功すると、gnutls は再開されたセッションを使用します。これは、前述の成功したハンドシェイクの 1 つだと思います。

この種の動作に関するドキュメントを見つけることができず、これが単に「NGINX のもの」であるかどうか疑問に思っています。

ハンドシェークは最終的にはテスト プログラムで機能しますが、(複数の高価なハンドシェークを行うのは) 無駄に思えます。クライアントが何をしようとしているのかを実際に理解しないと、非テスト環境でハンドシェーク ロジックを実装するのは難しいでしょう。

トランスポートでタイムアウトや問題が発生しているとは思いません。テスト環境は、1 つのスイッチ間で接続された同じサブネット上のいくつかの異なる VM です。

NGINX のバージョンは最新のメインライン: 1.11.7 です。私はもともと 1.10.something を使用していましたが、動作は似ていましたが、トランスポート エラーが多くなりました。これらのエラーは、アップグレードによってうまくクリーンアップされたようです。

他の人からの情報や経験は大歓迎です!

4

1 に答える 1

0

NGINX とバックエンド サーバー間の RSA キー交換を使用するか、 NGINX にSSLKEYLOGFILE LD_PRELOAD を使用して、Wireshark がデータを復号化するために必要なデータを取得します。

単一の着信接続は 1 つの発信接続のみを生成する必要がありますが、共通ファイル (favicon.ico、robots.txt) をフェッチするために NGINX でいくつかの最適化が行われる場合があります。

于 2017-06-27T14:37:17.377 に答える