リバースプロキシがあれば、SNATは不要？
ネットワークの設定を考えるとき、リバースプロキシがあればSNATは基本的に不要と思いがちですが、「本当に必要ない？」と迷う場面もあるかもしれません。実際には状況によってはSNATが必要になるケースもあります。今回は、リバースプロキシとSNATの役割、それぞれが必要になる場面を整理してみます。
リバースプロキシとSNAT、それぞれの役割
リバースプロキシって何？
リバースプロキシは、外部のクライアントと内部サーバーの間に立ち、以下のような役割を果たします：
クライアントからのリクエストを内部サーバーに転送する。
内部サーバーのIPアドレスを隠す。
たとえば、Webサーバーの前にNginxやApacheをリバースプロキシとして配置すると、外部からはリバースプロキシのIPアドレスしか見えません。内部構成を隠しつつ、クライアントとの通信を効率よく管理できます。
SNATって何？
一方、SNAT（送信元ネットワークアドレス変換）は以下のような場面で使われます：
内部ネットワークから外部ネットワークへ通信を行うときに送信元IPを変換する。
プライベートIPアドレスを外部に公開するためにグローバルIPアドレスに変換する。
たとえば、内部のサーバーが外部APIやサービスにリクエストを送る場合、送信元IPが変換されることで通信が可能になります。
リバースプロキシがあればSNATが不要な理由
リバースプロキシがある環境では、SNATを使う必要がないことが多いです。その理由を見ていきましょう。
リクエストの送信元IPがリバースプロキシになる
クライアントはリバースプロキシを通じてリクエストを送るため、内部サーバーから見える送信元IPはリバースプロキシのものになります。これにより、内部サーバーのIPを隠すためのSNATは不要です。外部通信をリバースプロキシが一元管理
外部との通信はすべてリバースプロキシを通じて行われるため、内部サーバーのIPが直接外部に露出することはありません。
それでもSNATが必要になる場面
リバースプロキシがあっても、以下のような場合にはSNATが必要になることがあります。
内部サーバーから外部に直接通信する場合
内部サーバーが外部のAPIやサービスに直接アクセスする際には、SNATで送信元IPを変換する必要があります。
例：内部サーバーが外部のパッケージリポジトリに接続する場合。クライアントIPを内部サーバーに伝える必要がある場合
クライアントのIPアドレスを内部サーバーに伝える必要があるとき、リバースプロキシは通常、X-Forwarded-ForヘッダーにIPを記録します。しかし、内部サーバーがこのヘッダーを認識しない場合はSNATを使うことがあります。ロードバランサーやNATゲートウェイの影響
リバースプロキシの前にロードバランサーやNATゲートウェイがある場合、それらがSNATを行い、送信元IPを統一するケースもあります。
まとめ
リバースプロキシがある環境では、基本的にSNATは不要。
リバースプロキシが内部サーバーのIPを隠し、外部通信を一元管理してくれます。例外的にSNATが必要なケースもある。
内部サーバーが外部と直接通信するときや、特別な要件がある場合にはSNATを併用します。
リバースプロキシとSNATの使い分けを理解しておけば、ネットワーク設計やトラブルシューティングの際にもスムーズに対応できます。