NATテーブルとは — 構造と役割、conntrack連携やLinux実装、運用・トラブル対策を徹底解説
NATテーブルとは — 概要と役割
NAT(Network Address Translation:ネットワークアドレス変換)は、プライベートIPアドレス空間とグローバルIPアドレス空間の橋渡しを行う技術です。「NATテーブル」は、その変換の状態・ルールを保持するデータ構造を指します。ルータやファイアウォール、OSカーネル(例:Linuxのnetfilter/conntrack)などのネットワーク機器が、パケットごとにどのように送受信先アドレス/ポートを変換するかを決め、既に確立されている通信については変換結果を再利用するためにテーブル(翻訳エントリ)を管理します。
NATテーブルが果たす具体的な役割
- 外部⇄内部のアドレス・ポート変換(SNAT / DNAT / PAT)の管理
- 接続ごとの一貫した変換結果の保持(ステートフルな動作)
- ポートの再利用・一時割当(オーバーロード:PAT)の管理
- 変換エントリの寿命管理(タイムアウト)とクリーンアップ
- 特殊プロトコル(ICMP、FTP、SIP等)向けの追加処理やALGの連携
NATの種類とテーブルの扱い方
NATには用途に応じていくつかの方式があり、NATテーブルはそれらを実現するための情報を持ちます。主な方式は次の通りです。
- Static NAT(静的NAT):内部IPと外部IPを1対1で固定的に割り当てる。サーバ公開に使われる。テーブルには固定マッピングが登録される。
- Dynamic NAT:内部IPをプールされた外部IPに動的に割り当てる。割当は先着順で、セッション終了後に解放される。
- PAT(Port Address Translation)/オーバーロード:1つの外部IPに複数の内部IPをポート番号で多重化して割り当てる。NATテーブルには内部IP:port ↔ 外部IP:port の対応が保存される。
NATテーブル(翻訳エントリ)の中身
典型的な翻訳エントリは以下のような情報を持ちます(ベンダーや実装で名称は異なる場合があります)。
- 内部側アドレスとポート(inside local / inside global 等の表記)
- 外部側アドレスとポート(outside local / outside global)
- 使用中のプロトコル(TCP/UDP/ICMPなど)
- 接続の状態(確立/CLOSING等、TCPであればSYN/ESTABLISHED等)
- エントリの残り有効時間(タイムアウト)
- エントリが生成された時刻や使用頻度などの統計情報(機器による)
実装の違い:ルータ/ファイアウォール/OSカーネル
機能的には同じ目的でも、実装レイヤや呼び方が異なります。代表的な実装例を簡単に整理します。
- Cisco/Juniper等のハードウェアルータ/セキュリティ機器:独自のNAT実装を持ち、翻訳エントリは装置のメモリに保持される。コマンドで表示・操作できる(例:show ip nat translations、clear ip nat translationなど)。
- Linux(netfilter + conntrack / iptables/nftables):netfilterの「nat」テーブルでDNAT/SNATのフックがあり、状態はconntrack(nf_conntrack)で管理される。iptablesのnatチェーンは主にパケットの初回処理で適用され、以後のパケットはconntrackが保持するエントリにより処理される点が重要です。
- クラウド/ロードバランサ:大規模なNATは専用ハードやソフトウェアでスケールする(接続追跡の分散、ハッシュベースの割当など)。
Linuxのnetfilterにおける「natテーブル」の特徴
Linuxでは「nat」テーブルがあり、主に以下のチェーンで動作します:PREROUTING(到着前、DNATに使用)、OUTPUT(ローカル発のパケット)、POSTROUTING(送信前、SNATに使用)。重要なポイントは、natテーブルのルールは接続の“最初のパケット”に対してのみ適用され、その後はconntrackが保持する翻訳情報が再利用されるという点です。これにより、パフォーマンスを担保しつつ一貫した変換が可能になります。
NATとコネクション追跡(conntrack)の関係
NATは単にアドレスを書き換える処理だけでなく、接続の状態(ステート)を追跡する必要があります。HTTP等の短命な接続だけでなく、長時間続くTCP接続やUDPの擬似コネクション(NATでは擬似的に追跡される)も対象です。conntrackはこのステート情報(プロトコル、アドレス、ポート、シーケンスやタイムアウト)を保持し、対応するNATエントリにつなげます。結果として、NATテーブルはステートフルなネットワーク処理を実現します。
プロトコルごとの注意点(TCP / UDP / ICMP / アプリケーション層プロトコル)
- TCP:3ウェイハンドシェイクを基にセッション管理されるため、NATは比較的扱いやすい。だがTCPの再接続や翻訳後のパケット順序等で注意が必要。
- UDP:コネクションレスなので、NAT実装は「擬似接続(エントリを作り一定時間維持)」で対応する。RFC 4787 はUDPに関する動作要件を示している(マッピングの寿命やポート再利用に関する挙動)。
- ICMP:エコー要求/応答はIDやシーケンス番号を扱うため、ICMP固有のマッピングが必要になる。
- アプリケーション層プロトコル(FTP、SIP、RTSPなど):制御メッセージ内にIP/ポートが埋め込まれるため、そのままでは通らない。ALG(Application Layer Gateway)やSIIT/NAT64のような機能でペイロードの書換えやセッション追跡を行うことがあるが、ALGが誤動作するケースもあるため運用注意。
代表的な運用上の課題と対策
- ポート枯渇(PATでのエフェメラルポート不足):大量の同時接続があるとポート不足に陥る。対処はIPプールを増やす、負荷分散する、IPv6導入でNAT依存を減らす、接続の短縮やアプリ設計の見直し。
- タイムアウト設定の適切化:UDPやTCPのタイムアウトを適切に設定しないと、接続切断後にエントリが長く残る/すぐ消えることで通信障害が発生する。多くの実装でタイムアウトは調整可能。
- ログ/デバッグ:翻訳テーブルを確認するコマンド(後述)で状態を把握。大規模環境ではログが膨大になるためサンプリングや集約が必要。
- NAT越えのアプリケーション設計:P2PやVoIPはNAT越え問題があるため、STUN/TURN/ICE等の技術やサーバ中継の採用を検討。
トラブルシューティングでよく使うコマンド(例)
機器やOSによってコマンドは異なりますが、代表的なものを示します。
- Cisco(IOS): show ip nat translations / show ip nat statistics / clear ip nat translation [ip]
- Linux(iptables + conntrack):
- iptables -t nat -L -n -v
- sudo conntrack -L (conntrack-tools)
- cat /proc/net/nf_conntrack (カーネル内部の表示)
- nftables環境では nft list table nat 等でnatテーブルを確認
例:Linuxで現在のconntrackエントリを表示 sudo apt install conntrack sudo conntrack -L
ヘアピン(NATループバック)やポートフォワーディング
内部クライアントが「公開されたグローバルIP(自分のネットワークの外側のアドレス)」を参照して内部のサーバへアクセスするケース(例:家庭内で自分のグローバルIPのポート80にアクセス)では、普通のNATではうまくルーティングされないことがあります。これを解決するのがヘアピンNAT(NATループバック)で、内部発のトラフィックもDNAT/SNATを適用して正しく内部サーバへ到達させます。多くのルータやファイアウォールは設定でヘアピンを許可できますが、挙動は実装次第です。
NATとIPv6 — 将来的展望とNAT64
IPv6の主要理念はアドレス枯渇の解消とエンドツーエンド性の回復であり、基本的にはNATを不要にします。そのため、IPv6ネイティブではNATを避ける設計が推奨されます。ただし、IPv6とIPv4の共存環境ではNAT64(IPv6クライアントがIPv4サーバにアクセスするための変換)やSIIT等が利用され、これらも翻訳テーブルとステート管理を必要とします(RFC 6146 / RFC 6145 等)。また、運用上の理由でIPv6環境でNAT(Pt)を使うケースもあり得ますが、設計上の考慮が必要です。
スケーラビリティとパフォーマンス
NATテーブルはメモリとCPUを消費します。大量の同時接続(例:大規模なWebプロキシ、NATゲートウェイ)では、conntrackテーブルのサイズ、ハッシュ性能、エントリ作成・破棄コストがボトルネックになります。商用環境ではハードウェアオフロード、分散NAT、ステートレスなロードバランサ設計などでスケール対策を行います。クラウド環境ではスループット課金や同時接続上限に注意が必要です。
まとめ(運用上のチェックポイント)
- NATテーブルは単なるアドレス書換表ではなく、接続追跡(ステート)を含む重要なデータ構造である。
- 実装(ルータ、ファイアウォール、Linux等)による違いを理解し、どのチェーン/どのタイミングで変換が行われるか把握する。
- タイムアウトやポート枯渇、ALGの影響など運用上の落とし穴を事前にチェックする。
- IPv6移行やNAT越えを考慮したアプリ設計(STUN/TURNなど)を検討する。
参考文献
- RFC 2663 — IP Network Address Translator (NAT) Terminology and Considerations
- RFC 3022 — Traditional IP Network Address Translator (Traditional NAT)
- RFC 4787 — Network Address Translation (NAT) Behavioral Requirements for Unicast UDP
- RFC 6146 — Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers
- netfilter — conntrack (connection tracking) project
- netfilter/iptables documentation
- Cisco NAT overview
- Understanding NAT and iptables nat table(Red Hat Developer blog)


