問題タブ [aws-nlb]

最近、nlb で問題が発生しています。lb で https 終端を使用して nlb をリダイレクト http=>https と EKS で ingress-nginx を使用して動作させるのは、かなりの冒険でした。

ここで、X-Forwarded ヘッダーをポッドに渡したいのですが、それによって http=>https リダイレクトが中断され、http 要求で 400 が返されます。

サービスで、httpまたはtcpプロトコルでサービスを配置しようとしましたが、同じです。

サービスにヘッダーを追加するservice.beta.kubernetes.io/aws-load-balancer-proxy-protocol: "*"と、すべてのターゲットでプロキシ プロトコル v2 がアクティブuse-proxy-protocol: 'true'になり、nginx の configmap でアクティブ化すると、http スニペットが 308 リダイレクトで壊れます。

すべての適切なヘッダーとリダイレクトが機能する nlb を使用できるようにする方法はありますか?

コメント要求で編集して、完全な作業構成を追加します

.Net 4.8 を実行している WCF クライアントがあり、TLS リスナーを使用する AWS Network Load Balancer を介して WCF サービスに接続したいと考えています。問題は、それを介して接続できないことです。NLB で TCP リスナーを使用している場合、正しく接続できます。

この問題について AWS サポートに問い合わせたところ、調査の結果、私の NLB 構成に問題がないことが確認され、TLS を介して適切に通信するには、WCF クライアントが NLB の TLS リスナーとの TLS 通信を開始する必要があるとアドバイスされました。

しかし、私の調査によると、クライアントのセキュリティ要件を決定するのは WCF サービスです。これは、このMicrosoft リソースの最初の行に記載されています。WCF クライアントに TLS 通信を強制的に開始させる方法はありますか?

私はすでにクライアントコードに持っています：

そして私のクライアント設定ファイルでは、これをバインディング設定に持っています。

また、TCP リスナーでの正常な通信中にパケットを調べたところ、TCP ハンドシェイクの後、クライアントとサービスは TLS 通信を開始する前にいくつかの情報を交換しました。それが重要かどうかはわかりませんが、私はそれを述べたいと思います。

TLS を使用するように構成されたブラウザーのように動作する WCF クライアントが必要です。この場合、通信相手のバックエンド エンティティとの TLS 通信を開始するのは WCF クライアントです。(例: Web サーバー、ロードバランサーなど)

WCF クライアントに TLS 通信を強制的に開始させる方法はありますか?