IPオリジンをnginxヘッダーに追加する

Question

スティッキー セッション用の nginxで、トラフィックが常に 1 つのサーバーにのみ送信される状況がありますip_hash。nginx は Google Cloud ロード バランサの背後で実行されており、実際にポッドの 1 つに移動する前に、nginx からアプリの GC Kubernetes ロード バランサに到達します。

すべてのユーザーの IP が GC ロード バランサーによってマスクされ、nginx がそれらを 1 つのソースとして認識するようになったのではないかと考えています。

ロード バランサがユーザーを別のユーザーとして認識できるように、ユーザーの元の IP を nginx のヘッダーに追加できると言われました。どうすればいいでしょうか? または、別の解決策はありますか?

Answer 1

ネットワーク負荷分散（ターゲットプールを使用）を使用している場合、ロードバランサーはIPを保持します。Kubernetesは、送信元IPクラスター/ノード IP を使用します。

KubernetesにはクライアントのソースIPを保持する機能があります。ドキュメントで確認できます。Type=LoadBalancer のサービスでクライアントのソース IP を保持する方法(ネットワーク負荷分散)。

Answer 2

構成、設定セッションアフィニティ初期設定中にターゲットプール次のいずれかに設定することでデフォルト以外の値望ましいレベルを提供するためにスティッキーセッション:

CLIENT_IP

送信元 IP と送信先 IP を使用する 2 タプル ハッシュ。インスタンスが正常である限り、クライアントからのすべての接続はプロトコルに関係なく同じインスタンスで終了します。

CLIENT_IP_PROTO

3 タプル ハッシュ。送信元 IP と宛先 IP およびプロトコルを使用します。クライアントからのすべての接続は、同じプロトコルを使用し、インスタンスが正常な状態である限り、同じインスタンスで終了します。

ラクシュマン・ディワアカルセッションアフィニティ設定は変更不可能な属性セットであることを意味する「作成中」ターゲット プール。利用可能な Cloud Compute の負荷分散機能に関する彼のレビューは、興味深い内容かもしれません。ネットワーク ロード バランサと HTTP(s) ロード バランサ。

Answer 3

proxy_set_header を使用して、IP オリジナルを NGINX ヘッダーに追加します。次の例を確認してください。

proxy_set_header X-Real-IP $remote_addr;

proxy_set_header X-Forwarded-Host $remote_addr;

proxy_set_header X-Forwarded-For $remote_addr;

同様に、IP オリジンを NGINX ヘッダーに追加することもできます。