ロードバランサ — 間に入った箱が、何を書き換えているか

What — 間に入る箱は、接続を終端する

ロードバランサやリバースプロキシは、通信を素通しにしません。利用者との接続をそこで受け止め（終端し）、別の接続を自分で作ってバックエンドへ送ります。

終端

そこで接続を一度受け止めること。TLS を終端すると、その先は別の接続になる。

X-Forwarded-For

元の送信元 IP を伝えるヘッダー。間に入った箱が追記していく。標準化されたものに Forwarded がある。

ヘルスチェック

振り分け先が正常かを定期的に確かめる仕組み。失敗が続くと振り分けから外す。

アイドルタイムアウト

通信が無いまま接続を保持する上限時間。上流と下流でずれると切断の事故になる。

元の情報は、ヘッダーに移っている

利用者の IP、使われたプロトコル（http / https）、元のホスト名。どれも接続からは分からなくなり、ヘッダーに移ります。

X-Forwarded-Proto を読まないと、https で来たのに http だと思い込み、http:// へリダイレクトして無限ループになる、という事故が起きます。

Why — なぜヘッダーをそのまま信じてはいけないか

X-Forwarded-For を読めば解決、とはいきません。このヘッダーは、利用者が自分で付けられます。

$ curl https://example.com/api/login -H "X-Forwarded-For: 1.2.3.4"

アプリが素直に先頭の値を使うと、攻撃者はリクエストごとに違う IP を名乗れます。レート制限は無意味になり、ログには偽の IP が残り、IP による遮断も効きません。

右から数える

X-Forwarded-For は、間に入った箱が右へ追記していく形です。

X-Forwarded-For: 1.2.3.4, 203.0.113.45, 70.132.1.9
                 ↑偽装     ↑本物の利用者   ↑CDN が見た送信元
                 （利用者が勝手に付けた）

信頼できるのは、自分が置いた箱が付けた値だけです。CDN とロードバランサの2段なら、右から2つ目が利用者の IP です。

つまり、自分の構成で間に何段あるかを数え、その数だけ右から取るのが正しい読み方です。段数を間違えると、偽装された値を掴みます。多くのフレームワークには「信頼するプロキシの数」を設定する仕組みがあり、その設定こそが判断そのものです。

ヘルスチェックは、浅すぎても深すぎても事故になる

ロードバランサは、振り分け先が生きているかを定期的に確かめます。この確認の深さが、障害の形を決めます。

TCP connect 10.0.3.12:3000

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。