NAT とは|変換テーブルの仕組みと NAPT・IP マスカレードの違い

  • URLをコピーしました!
目次

はじめに

NAT(Network Address Translation)は、社内ネットワークからクラウド、家庭のブロードバンドルーターまで、IPv4 ネットワークのほぼすべてで動いている土台技術です。それにもかかわらず、学び直そうとすると「NAPT・PAT・IP マスカレードは何が違うのか(結論: ほぼ同じものの呼び方違いです)」「静的 NAT と動的 NAT はどう使い分けるのか」といった用語の揺れと分類の壁に突き当たります。メーカーごとに呼び方が異なることが、この分野の理解を必要以上に難しくしています。

本記事では、NAT の仕組みを 変換テーブルの動き から解説し、種類ごとの使いどころ、メーカー用語の対応関係、そして NAT の限界(ALG・NAT 越え)までを整理します。一次資料として RFC 1918・RFC 3022 を参照します。概念の整理に徹し、機器ごとの設定手順は記事末尾で案内する各メーカー別の記事に委ねます。

この記事でわかること
  • NAT が必要とされる背景(IPv4 アドレスの枯渇とプライベートアドレス)
  • 変換テーブルによる「行き」と「戻り」の対応付けの仕組み
  • 静的 NAT・動的 NAT・NAPT の違いと使いどころ
  • NAPT・PAT・IP マスカレードというメーカー用語の対応関係
  • NAT の限界(ALG が必要なプロトコル、外部からの着信、NAT 越え)

先に結論を示すと、NAT の本質は「変換テーブルによる行きと戻りの対応付け」の 1 点に尽きます。行きのパケットで変換の記録(エントリ)を作り、戻りのパケットをその記録で元に戻す。この動きさえ押さえれば、「なぜ外部から内部へは通信できないのか」「なぜサーバー公開には静的な設定が必要なのか」「なぜ一部のプロトコルは NAT を通らないのか」が、すべて同じ原理から説明できます。また、実務で構成する NAT はほぼ「静的 NAT」と「NAPT」の 2 つであり、動的 NAT の出番は限定的です。

NAT とは(アドレス変換の仕組み)

NAT は、IP パケットのヘッダに含まれる IP アドレス(およびポート番号)を、ルーターやファイアウォールが書き換えながら転送する技術です。まず「なぜ書き換えが必要なのか」という背景から確認します。

NAT が必要とされる背景(IPv4 アドレスの枯渇と RFC 1918)

IPv4 アドレスは 32 ビットで、理論上の総数は約 43 億個です。インターネットの拡大に伴いこの数では足りなくなることが早くから予見され、対策の柱として 1996 年に RFC 1918 が定められました。組織の内部だけで自由に使えるアドレス範囲、いわゆる プライベートアドレス の予約です。

参考: RFC 1918 – Address Allocation for Private Internets
“has reserved the following three blocks of the IP address space for private internets”
(IANA は、プライベートインターネット向けに以下の 3 ブロックの IP アドレス空間を予約しています)
https://www.rfc-editor.org/rfc/rfc1918.html

ブロック範囲プレフィックス
クラス A 相当10.0.0.0 〜 10.255.255.25510.0.0.0/8
クラス B 相当172.16.0.0 〜 172.31.255.255172.16.0.0/12
クラス C 相当192.168.0.0 〜 192.168.255.255192.168.0.0/16

プライベートアドレスは、IANA やレジストリとの調整なしに誰でも使える代わりに、世界中の組織で重複して使われるため、インターネット上ではルーティングされません(172.16.0.0/12 の範囲を「172 で始まるアドレス全部」と誤解しやすい点には注意が必要です。172.32.0.0 以降はパブリックアドレスです)。

ここで問題になるのが、プライベートアドレスの端末がインターネットと通信する方法です。送信元がプライベートアドレスのままのパケットは、相手に届いたとしても 戻りのパケットが帰ってこられません。宛先 192.168.1.10 は世界中に無数に存在するため、インターネット上のルーターはどこへ届ければよいか判断できないからです。そこで、ネットワークの出口でプライベートアドレスをグローバルアドレスに書き換える仕組み、すなわち NAT が必要になります。

変換テーブルの動き(行きと戻りの対応付け)

NAT の動作の核心は、ルーターが保持する 変換テーブル(変換の対応付けの記録) にあります。社内の端末が Web サイトへアクセスする例で、行きと戻りの流れを追います。

  • 端末: 192.168.1.10(プライベートアドレス)
  • ルーターの WAN 側: 203.0.113.1(グローバルアドレス)
  • 接続先 Web サーバー: 198.51.100.20
行き(内→外)
  1. 端末が 198.51.100.20:443 宛のパケットを送信します。送信元は 192.168.1.10:51000 です。
  2. ルーターは通過時に送信元を 203.0.113.1:61000 に書き換え、あわせて 「192.168.1.10:51000 ⇔ 203.0.113.1:61000」という対応付けを変換テーブルに記録 します。
  3. Web サーバーには「203.0.113.1:61000 からの通信」として届きます。サーバーはプライベートアドレスの存在を知る必要がありません。
戻り(外→内)
  1. Web サーバーは応答を 203.0.113.1:61000 宛に返します。
  2. ルーターは変換テーブルを参照し、宛先を 192.168.1.10:51000 に書き戻して端末へ届けます。

この単純な流れに、NAT のすべての性質が含まれています。

変換テーブルのエントリは「行き」の通信によって作られ

つまり、テーブルにエントリのない「外→内」の新規通信は、宛先の復元先が分からず届きません。これが「NAT の内側は外部から直接アクセスできない」ことの正体であり、逆に言えば、サーバー公開には通信より先にエントリを固定的に用意しておく仕組み(静的 NAT・静的 NAPT)が必要になる理由です。

エントリには寿命があ

通信が終わる、または無通信状態が続くと、エントリはタイムアウトで削除され、リソース(アドレス・ポート)が再利用されます。長時間アイドルのセッションが突然切れる事象や、キープアライブが必要になる理由はここにあります。

書き換えられるのは IP ヘッダ(とトランスポート層ヘッダ)だけ

アプリケーションデータ(ペイロード)の中に IP アドレスが書かれていても NAT は関知しません。これが後述する「ALG が必要なプロトコル」の問題につながります。

なお、この例では送信元アドレスとあわせてポート番号も書き換えています。アドレスのみを書き換えるのか、ポート番号まで含めて書き換えるのかが、次の章で解説する NAT の種類(Basic NAT と NAPT)の分かれ目です。

NAT の種類と使いどころ

NAT は「エントリを固定的に作るか、動的に作るか」と「アドレスのみを変換するか、ポート番号まで変換するか」という 2 つの軸で分類できます。この組み合わせから、実務で登場する 3 つの方式(静的 NAT・動的 NAT・NAPT)が導かれます。

静的 NAT(1 対 1 変換)と使いどころ

静的 NAT は、内部アドレスと外部アドレスの 1 対 1 の対応付けを、設定として固定的に定義しておく 方式です。前章で解説した変換テーブルの言葉で言えば、「行きの通信を待たずに、恒久的なエントリをあらかじめ作っておく」ことに相当します。

エントリが通信前から存在するため、外部を起点とする新規通信も内部へ届きます。これが静的 NAT の本質的な価値であり、主な使いどころは以下の 2 つです。

公開サーバーの構成

外部からの接続を受け付ける Web サーバー・VPN 装置などに、専用のグローバルアドレスを対応付けます。

送信元アドレスの固定が必要な対外接続

接続先システムが送信元 IP アドレス単位でアクセス制限をかけている場合(企業間接続・決済系など)、内部サーバーの送信元を常に同じグローバルアドレスに固定できます。

制約は、対応付けた内部ホストの数だけグローバルアドレスを消費することです。アドレスに余裕のない環境では、後述の NAPT のポート単位の静的エントリ(いわゆるポート開放)で代替します。

動的 NAT と使いどころ

動的 NAT は、あらかじめ用意したグローバルアドレスの プール から、通信が発生したタイミングで空いているアドレスを 1 対 1 で貸し出す方式です。通信が終わりエントリがタイムアウトすると、アドレスはプールに返却され再利用されます。

1 対 1 の対応が保証される一方で、対応付けは動的に生まれるため外部起点の通信には使えず、プールのアドレス数を超える同時通信は、空きが出るまで変換できません。「アドレスを節約したいが 1 対 1 でなければならない」という限られた要件(接続先の仕様で送信元とポートの関係を維持する必要がある場合など)でのみ選択される、実務では出番の少ない方式です。本ブログのメーカー別記事でも、4 機種すべてで「利用場面は限定的」という同じ結論になっています。

NAPT(PAT / IP マスカレード)と使いどころ

NAPT(Network Address Port Translation)は、IP アドレスに加えて TCP/UDP のポート番号もあわせて変換する 方式です。RFC 3022 では次のように定義されています。

参考: RFC 3022 – Traditional IP Network Address Translator (Traditional NAT)
“many network addresses and their TCP/UDP ports are translated into a single network address”
(多数のネットワークアドレスとその TCP/UDP ポートを、単一のネットワークアドレスとそのポートに変換します)
https://www.ietf.org/rfc/rfc3022.txt

アドレスだけを見れば「多対 1」ですが、変換テーブルのエントリを「アドレス+ポート番号」の組で管理することで、1 つのグローバルアドレス上で多数のセッションを同時に識別できます。前章の変換テーブルの例(192.168.1.10:51000 ⇔ 203.0.113.1:61000)は、まさに NAPT の動きです。

グローバルアドレス 1 個から構成できるため、インターネット接続用の NAT はほぼすべて NAPT です。家庭のブロードバンドルーターから企業の FW まで、「NAT を設定する」と言うとき実際に構成しているのは大半がこの方式です。

NAPT の限界も、仕組みから素直に導けます。

  • ポート番号の総数が収容の上限になります。1 アドレスあたりのポート番号は最大でも 65,535 個であり、多数の端末が大量のセッションを張る環境ではポート枯渇が起こります(各機器での枯渇時の挙動と確認方法は、メーカー別記事で解説しています)
  • ポート番号を持たないプロトコルは原則として多重化できません。ICMP は識別子で代替されますが、それ以外のプロトコル(ESP・GRE など)は機器ごとの個別実装に依存します。
  • 外部起点の通信は届かないため、サーバー公開にはポート単位の静的エントリ(ポート開放)を併用します。

メーカーごとの用語の対応表

NAPT には、歴史的な経緯からメーカー・実装ごとに異なる呼び名があり、PAT・IP マスカレード・NAPT はいずれも実質的に同じ方式 を指します。「IP マスカレード」は、RFC 3022 にも記載がある通り、もともと Linux における NAT 実装の名称(IP masquerade)に由来し、YAMAHA がこの呼称を採用しています。PAT(Port Address Translation)は Cisco の用語です。

本ブログのメーカー別記事で扱った 4 機種と標準用語の対応は、以下の通りです。

概念RFC の用語CiscoFortiGateYAMAHA RTXNEC IX
アドレス+ポート変換(多対 1)NAPTPAT(overload)IP Pool(Overload タイプ)IP マスカレード(masquerade)NAPT(ip napt
アドレスのみ 1 対 1(固定)Basic NAT(static)静的 NATVIP / IP Pool(One-to-One)静的 NAT(nat descriptor static静的 NAT(ip nat static
アドレスのみ 1 対 1(動的)Basic NAT(dynamic)動的 NATIP Pool(One-to-One)nat タイプ動的 NAT(ip nat dynamic
ポート単位の静的公開静的 PATVIP(ポートフォワーディング)静的 IP マスカレード静的 NAPT / サービス NAPT

あわせて、用語の使われ方について 1 点補足します。RFC の定義では「NAT」はアドレスのみを変換する Basic NAT を指し、NAPT とは区別されますが、現場の会話や機器の設定画面では、NAPT まで含めた総称として「NAT」が使われるのが実態 です。文脈上どちらを指しているか曖昧な場面(設計書のレビューなど)では、「アドレスのみの 1 対 1 か、ポート変換ありか」を確認しておくと、認識齟齬による手戻りを防げます。

NAT の限界と注意点

NAT は IPv4 を延命させた実用的な技術ですが、「アドレスを書き換える」という動作そのものが、通信の前提をいくつか壊します。RFC 2663 は NAT の限界を明示的に整理しており、実務で遭遇するトラブルの多くはここに帰着します。

ペイロードにアドレスを含むプロトコルと ALG

第 1 章で触れた通り、NAT が書き換えるのは IP ヘッダとトランスポート層ヘッダに限られます。アプリケーションデータ(ペイロード)の中身には手を出しません。

参考: RFC 2663 – NAT Terminology and Considerations
“NAT devices do not change the payload of the packets”
(NAT 装置はパケットのペイロードを変更しません)
https://www.rfc-editor.org/rfc/rfc2663.html

大半のアプリケーションではこれで問題ありませんが、ペイロードの中に IP アドレスやポート番号を埋め込んで通信するプロトコルでは、ヘッダだけを書き換えても通信が成立しません。ヘッダは変換後のグローバルアドレスなのに、中身にはプライベートアドレスが書かれたまま相手に届き、相手はその到達不能なアドレスへ接続しようとして失敗します。

代表例は以下の通りです。

FTP(アクティブモード)

データコネクション用のアドレス・ポートを制御チャネルのペイロードで通知します。

SIP / VoIP

音声ストリーム(RTP)の宛先をシグナリングのペイロードで交換します。

SNMP

MIB の中に IP アドレスが含まれます。RFC 2663 も、NAT ルーターは SNMP ペイロード内のアドレスを変換しないと明記しています。

この問題への対処が ALG(Application Level Gateway) です。ALG は NAT 装置に組み込まれるアプリケーション固有の変換エージェントで、ペイロード内のアドレス情報まで踏み込んで書き換えます。ただし ALG には構造的な限界があります。

対応プロトコルは実装依存

機器ごとに対応リストが異なり、世の中のすべてのアプリケーションに追随することは現実的に不可能です。

暗号化されたペイロードは書き換えられない

TLS で保護された通信の中身を ALG は解釈できません。

ALG 自体が不具合の原因になることがあ

SIP ALG が意図しない書き換えを行い VoIP が不安定になる、という事例は実務でよく知られています。この場合、ALG を無効化して端末側の NAT 越え機能に任せる判断が取られます。

NAT 環境で特定のアプリケーションだけが失敗する場合、ALG の対応状況と動作の確認を切り分けに含める ことが、原因特定への近道です。各機器での ALG の扱いは、記事末尾で案内するメーカー別記事で解説しています。

外部からの着信と NAT 越えの問題

第 1 章で確認した通り、変換テーブルのエントリは内側からの通信によって作られます。したがって エントリのない外部からの新規通信は、宛先の復元先が判断できず届きません。サーバー公開に静的な設定が必要なのはこのためですが、この性質はもう 1 つ、より厄介な問題を生みます。

NAT の内側にある端末同士が、直接通信できない という問題です。VoIP・ビデオ会議・オンラインゲーム・P2P など、双方が NAT の内側にいる状態で端末間の直接通信を確立したいケースでは、どちらも相手側の変換テーブルにエントリを持たないため、通常の方法では接続が成立しません。この課題を解決する技術群が「NAT 越え(NAT traversal)」と呼ばれ、STUN・TURN・ICE といった仕組み、および IPsec VPN における NAT-T が該当します。

また、IPsec のトランスポートモードのように 通信内容の完全性を IP ヘッダを含めて検証する仕組みは、NAT によるヘッダ書き換えと原理的に両立しません。RFC 2663 も、NAT と ALG の組み合わせでは IPsec が保証するエンドツーエンドのセキュリティは提供できないと明記しています。IPsec VPN が NAT 環境で失敗する場合、この原理的な非互換が背景にあります(実務では NAT-T によりカプセル化して回避します)

なお、NAT 越えの分類(フルコーン・シンメトリック等の NAT タイプ)と STUN/TURN/NAT-T の詳細は、別記事で扱う予定です。同じ NAT の内側から自社の公開サーバーへグローバル IP でアクセスできないという、より身近な折り返し通信の問題については、関連記事『ヘアピン NAT とは|内部からグローバル IP でアクセスできない原因と対処』で解説しています。

セキュリティ機能としての NAT の位置づけ

「NAT があるから外部から攻撃されない」という説明を目にすることがあります。この理解は 半分正しく、半分は危険 です。

正しい部分は、これまで見てきた通りです。NAPT 環境では変換テーブルにエントリのない外部起点の通信は内部へ到達できず、結果として内部ホストは外部から直接スキャンできません。RFC 2663 も、NAT と ALG を組み合わせれば内部のプライベートアドレスを外部から隠蔽できる点に触れています。この遮蔽効果は事実です。

危険な部分は、この効果はあくまで「アドレス変換の副産物」であり、設計されたセキュリティ機構ではない という点です。

NAT は通信の中身を検査しない

内部から外部への通信(マルウェアの C2 通信、情報の持ち出しなど)は、NAT を素通りします。

ポート開放した瞬間に穴が開

公開サーバー向けの静的エントリは、外部からその内部ホストへの直接の経路そのものです。開放したポートの先にあるサービスの脆弱性は、NAT では防げません。

設定次第で遮蔽は失われ

1 対 1 の静的 NAT は全ポートを外部に晒します。

IPv6 環境では前提が変わ

アドレスが潤沢な IPv6 では NAT を使わない設計が基本であり、「NAT による遮蔽」を前提にした防御はそのまま成立しません。

したがって、NAT はファイアウォールの代替にはなりません。実務上の整理としては、「NAT はアドレス変換の機能であり、通信の可否を制御するのはフィルタ / ファイアウォールの役割」と役割を明確に分け、内向き・外向き双方の通信制御は、NAT の遮蔽効果に頼らずフィルタで明示的に設計する ことが推奨されます。本ブログのメーカー別記事でも、「ポート開放(変換)とフィルタ許可は別機能であり両方の設定が必要」という点を、機器ごとに繰り返し取り上げています。

メーカー別の設定記事への案内

ここまで整理した NAT の概念は、実際の機器では それぞれ異なる設定体系 として実装されています。同じ NAPT を構成するにも、機器ごとに設定の考え方・コマンド・確認方法が大きく異なるため、本ブログでは主要 4 メーカーの設定手順を個別の記事にまとめています。

FortiGate NAT 設定の手順|VIP と IP Pool の使い分けと確認コマンド

SNAT を IP Pool、DNAT を VIP という専用オブジェクトで定義する体系です。変換ルールをファイアウォールポリシー内に置くか(ポリシー NAT)、独立したテーブルで一元管理するか(セントラル NAT)という 2 方式の選択が設計上の分岐点になります。

Cisco NAT 設定の手順|静的 NAT と PAT(overload)の使い分け

インターフェイスに inside / outside の役割を宣言し、変換対象を ACL で定義する体系です。inside local / inside global / outside local / outside global という 4 つのアドレス用語の理解が、設定と変換テーブルの読み解きの土台になります。

YAMAHA RTX NAT ディスクリプターの設定|静的 IP マスカレードの手順

変換ポリシーを「NAT ディスクリプター」として番号付きで定義し、インターフェイスに適用する 2 段階の体系です。定義しただけでは動作しない構造と、変換対象範囲の指定方法が理解の要点になります。

NEC IX NAPT 設定の手順|静的 NAT との使い分けと確認コマンド

NAT(アドレスのみ)と NAPT(アドレス+ポート)を独立した別機能として持ち、WAN 側インターフェイスの設定内で完結する体系です。両者を併用した場合の優先順位と、フィルタとの評価順序が設計上のポイントになります。

いずれの記事も、設定手順に加えて確認コマンド・よくあるトラブルの切り分け・機器固有の制約までを実務目線で解説しています。

まとめ

本記事では、NAT の仕組みを変換テーブルの動きから整理し、種類ごとの使いどころ、メーカー用語の対応関係、そして NAT の限界までを解説しました。方式の分類も、サーバー公開に静的な設定が必要な理由も、一部のプロトコルが NAT を通らない理由も、すべて「変換テーブルによる行きと戻りの対応付け」という 1 つの原理から導けます。

  • NAT の本質は変換テーブルによる行きと戻りの対応付け
  • エントリは内側からの通信で作られ、外部起点の通信は届かない
  • 実務で使うのは主に静的 NAT と NAPT の 2 方式
  • NAPT・PAT・IP マスカレードはいずれも同じ方式の呼び方違い
  • ペイロードにアドレスを含むプロトコルは ALG の対応が前提となる
  • NAT の遮蔽効果は副産物であり、ファイアウォールの代替にはならない
  • 機器ごとに設定体系が大きく異なるため個別の確認が必要

以上、最後までお読みいただきありがとうございました。

よかったらシェアしてね!
  • URLをコピーしました!

この記事を書いた人

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ(ネットワーク・サーバ・クラウド・セキュリティ)の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus(取得から20年以上)/ VCAP-DCA / Azure Solutions Architect Expert

▶ 運営者プロフィール(詳細)

目次