はじめに
自社製品はWEBページ（A社）のバナーをクリックすることでアクセスできます。
開発の中でWEBページ制作外社のA社と連携テストを行いました。
内容としては、A社のIPアドレスからのリクエストに対し、自社ALBのリスナールールで設定した503のメンテナンス画面を出すというものでした。
その際に、503メンテナンス画面ではなく、なぜか200で通信できてしまったので備忘録として残します。
構成図・前提条件
AWSリスナールールでは以下A社のIPアドレス
- 111.111.111.111
- 222.222.222.222
に対しALBのリスナールールより503メンテナンス画面へ遷移するように設定していました。
課題
A社IPアドレスを送信したところ503のメンテナナンス画面が出ずに自社アプリへの通信が成功してしまった。(ステータスコード200)
仮説
-
キャッシュが残っている
ブラウザにキャッシュが残っており、通信が通ってしまっているのではないかと考えました。しかし、いくらキャシュクリアをしても200で返ってきてしまう。 -
ALBリスナールールに誤りがある
設定しているリスナールールのconditionに誤りがあるため、200番になっているのではないかと考えました。
解決
ALBリスナールールに誤りがありました。
今回HTTPヘッダーのX-Forwarded-Forのvalueにサブネットマスクである/32をつけていることが原因でした。正しくは次のようになります。
X-Forwarded-Forとは
X-Forwarded-Forとは、HTTPヘッダフィールドの1つであり、ロードバランサなどの機器を経由してWebサーバに接続するクライアントの送信元IPアドレスを特定する際のデファクトスタンダードです。クライアントの送信元IPアドレスの特定は、ロードバランサなどでクライアントの送信元IPアドレスが 変換された場合でも、HTTPヘッダに元のクライアントIPアドレスの情報を付加することで実現します。
ここではALBしか書かれていませんが、CloudFrontでも同じです。
CloudFront（エッジロケーション）を経てALBにリクエストが来る場合、IPアドレスはCloudFrontのものとなってしまいます。
CloudFrontのIPアドレスではなく、送信元のIPアドレスを特定することができるHTTPヘッダーがX-Forwarded-Forということです。
おわりに
今回はX-Forwarded-Forのバリューにサブネットマスクを含めていたのが原因でした。
最近AWSの様々なサービスに触れる機会がありますが、ALBやCloudFront、WAFなどでも様々な設定値があり、混乱してしまいます。
一つ一つしっかり整理していかなければいけないと思いました！
参考