ロードバランサ（LB）構成でよくある悩みが、
「SNATを有効にするとクライアントIPが見えなくなるが、これは問題なのか？」
というものです。
- ログにLBのIPしか出ない
- アクセス制御ができない
- でも通信自体は正常
この状態で、
「SNATを切るべき？」「Proxy Protocolを使うべき？」
と迷う人は非常に多いです。
本記事では、
- SNATあり構成の正体
- クライアントIPが必要かどうかの判断基準
- 用途別の正しい設計解
を、前提から丁寧に解説します。
そもそもSNATありLB構成とは何か
SNAT（Source NAT）ありのLB構成では、
LBが通信の送信元IPを書き換えます。
通信イメージ
Client (1.1.1.1)
↓
LB (SNAT)
↓
Server（送信元IP = LB）サーバから見ると、
「通信相手はすべてLB」
に見えます。
これは異常ではなく、SNATの仕様です。
なぜSNATを使うのか（メリット）
SNATを使う最大の理由は、
戻り通信を必ずLB経由にするため
です。
- 非対称ルーティングを防げる
- FWセッションが安定する
- 構成が単純になる
特に大規模環境では、
SNATありが「安全側」の設計
になることが多いです。
問題になるのは「クライアントIPが必要な時」
SNAT構成そのものが問題なのではなく、
クライアントIPを使う要件があるか
が判断軸になります。
クライアントIPが必要なケース
- アクセスログのIP分析
- IP制限（allow/deny）
- 不正アクセス検知
これらがある場合、
SNATあり＋何もしない構成はNG
です。
判断基準①：サーバ側で「IPを直接使うか」
まず最初に考えるべき質問はこれです。
「アプリやOSが送信元IPを直接参照するか？」
Yesの場合
- IP制限をサーバで実施
- アプリがIPをロジックに使用
→ SNATあり構成は工夫が必要
Noの場合
- 通信できればよい
- IPは参考情報
→ SNATありのままで問題なし
解決策①：X-Forwarded-Forを使う
HTTP/HTTPS環境で最も一般的な解決策です。
LBがHTTPヘッダに、
X-Forwarded-For: 1.1.1.1を付与します。
判断基準
- L7（HTTP）で処理できる
- アプリ側でヘッダを読める
→ この条件なら最優先候補
解決策②：Proxy Protocolを使う
L4（TCP）レベルでIPを伝えたい場合は、
Proxy Protocol
を使います。
判断基準
- HTTP以外のプロトコル
- 送信元IPが必須
注意点として、
サーバ側が対応していないと通信できません。
解決策③：SNATを使わない（非推奨になりがち）
SNATを無効にすることで、
クライアントIPはそのまま届きます。
しかし、
- 戻り通信の経路設計
- FWとの整合性
を厳密に管理する必要があります。
「IPを見たいだけ」で選ぶのは危険です。
よくある設計ミス
- SNATありなのにIP制限をサーバで実施
- X-Forwarded-Forを信頼せず無視
- Proxy Protocolを有効にしたがサーバ未対応
これらは、
通信できない or 意味のないログ
を生みます。
設計判断のまとめ（これだけ覚えればOK）
- SNATは「戻り通信安定化」のため
- 問題は「IPを使う要件」があるかどうか
- HTTPならX-Forwarded-For
- L4ならProxy Protocol
SNATありLB構成は、
理解して使えば、最も安全で運用しやすい構成
です。
「IPが見えない＝悪」ではなく、
「要件に合った設計か」を判断する
ことが重要です。
