SNATとは？仕組み・iptables/nftables設定例、conntrackとクラウド運用の注意点をわかりやすく解説
エバープレイ編集部SNATとは：概要
SNAT（Source Network Address Translation、送信元アドレス変換）は、ネットワークアドレス変換（NAT）の一種で、パケットの送信元IPアドレス（および場合によっては送信元ポート）を書き換える技術です。主にプライベートIPアドレス空間からグローバルIPアドレス空間へ通信を出す際に使われ、内部ネットワーク（LAN）からインターネットへの通信を可能にします。逆に、外から内部に届いたレスポンスはコネクション追跡（conntrack）情報をもとに元の内部アドレスへ戻されます。
なぜSNATが必要か
- プライベートIP（RFC1918）を持つ多数の端末が限られたグローバルIPv4アドレスでインターネットへアクセスするため。
- ファイアウォールやロードバランサで、内部IPを隠蔽して外向き接続を一元管理するため。
- 複数の内部ホストが同一グローバルIPで外部と通信する際のアドレス管理（PAT/ポート変換と組み合わせ）。
SNATの仕組み（基本動作）
SNATは通常、パケットがルーティングされた後（POSTROUTINGチェイン）で適用されます。具体的には、内部ホストA（例：192.168.0.10）が外部サーバ（例：8.8.8.8:53）へUDPパケットを送ると、ルータ/ファイアウォールは送信元IPをグローバルIP（例：203.0.113.10）に書き換え、必要であれば送信元ポートも書き換えます。レスポンスが返ってくると、conntrackデータベースに記録された変換テーブルを参照して、宛先（変換前の内部IP）へパケットを戻します。
SNATと関連する用語の違い
- DNAT：Destination NAT。宛先アドレスを変更する。通常、外部から内部へのポートフォワーディングで使用され、PREROUTINGチェインで適用される。
- PAT（Port Address Translation）/オーバーロード：多数対1のNAT。複数内部アドレスを1つのグローバルIPで扱うためにポート番号を使って識別する。SNATは単に送信元を書き換える概念だが、実装上PATを伴うことが多い。
- MASQUERADE：iptablesでよく使われるターゲットで、外向きインタフェースのIPが動的に変わる環境（PPPoEやDHCP）で便利。MASQUERADEは実行時のインタフェースアドレスを使って自動的にSNATを行う。インタフェースIPが頻繁に変わらない固定IP環境ではSNAT（--to-source）を使う方が効率的。
- Hairpin NAT（NAT loopback）：同一ネットワーク内のクライアントが外部公開IP（またはロードバランサIP）を利用して自分の内部サービスへアクセスする際に利用されるSNAT/DNATの組み合わせ。
iptablesによるSNATの例
代表的なIPv4の例：
iptables -t nat -A POSTROUTING -s 192.168.0.0/24 -o eth0 -j SNAT --to-source 203.0.113.10インタフェースのアドレスが動的な場合は：
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADESNATは--to-sourceでアドレス（と場合によってはポート範囲）を指定できます。例：--to-source 203.0.113.10:1024-65535 のようにポート範囲を指定してPAT的に扱うことも可能です。
nftablesによる設定例
# table と chain を作成
nft add table ip nat
nft 'add chain ip nat postrouting { type nat hook postrouting priority 100 ; }'
# 固定IPでのsnat
nft add rule ip nat postrouting oifname "eth0" ip saddr 192.168.0.0/24 snat to 203.0.113.10
# 動的IPでのmasquerade
nft add rule ip nat postrouting oifname "eth0" masquerade
接続追跡（conntrack）とSNAT
SNATは単発の書き換えだけでなく、カーネルのconntrackが接続状態を保持することで機能します。conntrackは5-tuple（送受信のIP/ポート、プロトコル）情報を元に、送信元書き換えの逆変換を管理します。これにより、外部からのレスポンスが適切な内部ホストへ戻されます。Linuxではconntrackツール（conntrack コマンドや /proc/net/nf_conntrack）で状態を確認できます。
よくある利用ケース
- 家庭や企業ネットワークでのインターネット共有（LAN→WANの出口でSNAT）
- ロードバランサやリバースプロキシでクライアントの送信元を固定のアドレスに置き換える（アウトバウンドSNAT）
- クラウド環境やコンテナでのノード/ホストの出口NAT（例：KubernetesのIPマスカレードやCNIプラグインによるSNAT）
- ファイアウォールで内部構成を隠蔽し、ログやアクセス制御を簡素化するための統一IP化
クラウドでのSNAT（例）
主要クラウドはマネージドな「NAT Gateway」や「Cloud NAT」を提供し、インスタンス・コンテナのアウトバウンド接続に対してSNATを行います。例えばAWSのNAT GatewayやAzureのアウトバウンドSNAT、GCPのCloud NATなどです。これらはスケーラビリティや高可用性、管理運用の面で利点があります。
注意点・制限
- エンドツーエンド接続の崩壊：SNATにより送信元アドレスが書き換わるため、外部から内部へ直接アクセスできなくなる（ポートフォワーディングやDNATが必要）。
- ログとトレーシングの難化：外部側のログにはSNAT後のアドレスしか記録されないため、誰がアクセスしたかの特定に追加的なログ連携が必要。
- ポート枯渇：多数の内部セッションを1つのグローバルIPで扱うと、エフェメラルポートが枯渇する可能性がある。特に大規模なアウトバウンド接続がある場合は複数のパブリックIPやNAT Gatewayのスケールが必要。
- プロトコル依存の問題：FTPやSIPなど、ペイロード内にIP/ポート情報を含むプロトコルは、アプリケーションレベルのNATヘルパーやALGが必要になることがある（ただしこれらのヘルパーはセキュリティ/互換性の問題を起こすこともある）。
- 非対称ルーティング：返りのパケットが別経路で来た場合、SNATを適用していた機器が返信を処理できず接続が切れることがある。ルーティング設計で対称性を保つことが重要。
- IPv6では原則不要：IPv6はグローバルアドレスを各ホストが持つのが基本であり、SNATは推奨されない。どうしても必要ならNPTv6（Prefix Translation）などがあるが使用は限定的。
トラブルシューティングの手順（実用例）
- まずは基本のチェック：iptables -t nat -vnL、nft list ruleset でNATルールを確認。
- conntrack テーブルの確認：conntrack -L または cat /proc/net/nf_conntrack で変換状態を確認。
- tcpdumpでパケットの送出時と受信時のIP/ポートを確認（例：tcpdump -i eth0 host 8.8.8.8）し、SNATが期待通りに起きているかを追跡。
- ポート枯渇の確認：ss -s や netstat、/proc/sys/net/ipv4/ip_local_port_range を確認し、必要ならエフェメラルポート範囲の拡張や複数パブリックIPの割当てを検討。
- 非対称ルーティングの確認：ルーティングテーブル（ip route show）を見て、返信が同じ出口を使うか確認。必要ならPolicy Routingを導入。
実践的なベストプラクティス
- インタフェースIPが固定ならSNAT（--to-source）を使い、動的IP環境ではMASQUERADEを使う。
- 大量のアウトバウンド接続がある場合は、エフェメラルポート枯渇対策として複数パブリックIPを割り当てるか、クラウドのNATサービスでスケーリングを利用する。
- ログや監査のために内部IPと外部IPの紐付けを中央で記録する仕組みを用意する（NATテーブルのログ出力やFlowログ等）。
- アプリケーションがIP情報をペイロードに含む場合は、アプリ対応（例：SIPのALGsは注意が必要）やアプリレベルのプロキシで処理する。
- IPv6への移行を検討する：可能ならIPv6のエンドツーエンドを採用し、NATに依存しない設計を目指す。
まとめ
SNATは、内部ネットワークからインターネットへ安全かつ効率的に通信を行うための基本的な技術です。仕組み自体は単純（送信元を書き換える）ですが、接続追跡、ポート管理、ルーティングやアプリケーションの特性との関係など、運用面で考慮すべき点が多くあります。適切な設計（固定IPか動的か、ポート数の計画、非対称ルーティングの回避、ログ管理）を行えば、スケーラブルで安定したアウトバウンド通信基盤を構築できます。特にクラウド環境やコンテナ環境では、マネージドNATやCNIの仕様に注意して設計することが重要です。
参考文献
- Netfilter（iptables / nftables の公式）
- iptables(8) - Linux manual
- nftables 公式 Wiki
- Linux kernel - Connection tracking (nf_conntrack)
- AWS NAT Gateway（AWS公式ドキュメント）
- Google Cloud NAT（GCP公式ドキュメント）
- Azure のアウトバウンド接続（Azure公式ドキュメント）
- RFC 2663 - NAT terminology and considerations
- RFC 6296 - NPTv6 (Network Prefix Translation for IPv6)
投稿者プロフィール
