IT用語集 2024/12/20

PATとは？ 10分でわかりやすく解説

コラム

ネットワーク管理の現場では、IPv4のグローバルIPアドレスが潤沢に用意できないケースが珍しくありません。そこで広く使われているのが、限られたグローバルIPアドレスを“共有”して外部通信を成立させる技術PAT（Port Address Translation）です。

この記事では、PATの基本、NATとの違い、動作のしくみ、導入時の注意点、トラブル時の切り分けまでを整理します。読了後に「自社の構成でPATをどう使うか」「どこに落とし穴があるか」を判断できるようになることを目指します。

PATとは？NATとの違いを理解しよう

PATの基本概念

PAT（Port Address Translation）は、IPアドレスに加えてポート番号も書き換えることで、複数の端末が1つ（または少数）のグローバルIPアドレスを共有しながらインターネットへ通信できるようにする仕組みです。一般に「NAPT（Network Address and Port Translation）」や「NAT（多対1）」と呼ばれることもあり、家庭用ルーターから企業のファイアウォールまで幅広く実装されています。

典型的には、LAN側の端末（例：192.168.1.10:53124）が外部へ通信する際、ゲートウェイが送信元を（例：203.0.113.5:40001）のように変換し、戻り通信を変換表（セッション表）に基づいて元の端末へ戻します。

PATとNATの違い

NATという言葉は広く使われており、現場では「アドレス変換全般」をNATと呼ぶこともあります。ここでは、概念整理のために次のように区別します。

項目	NAT（狭義：アドレス変換）	PAT（ポートも含む変換）
変換の単位	主にIPアドレス	IPアドレス＋ポート番号
典型例	1対1（静的NAT）	多対1（NAPT / マスカレード）
グローバルIPの必要数	構成により複数必要になりやすい	少数でも多数端末を収容しやすい
使いどころ	公開サーバーの固定割当など	社内端末の外向き通信の集約など

PATは「NATの一形態」であり、ポート番号を活用して多対1の変換を成立させる点が特徴です。

PATの仕組み

PATは、内部→外部の通信を契機に「変換表（セッション表）」を作り、戻り通信をその表で逆変換します。流れを簡略化すると次のとおりです。

内部端末が外部宛に通信（送信元：プライベートIP:ポート）を開始する
ゲートウェイが送信元を「グローバルIP:未使用ポート」に変換し、変換表へ登録する
外部からの応答は「グローバルIP:割り当てたポート」宛に戻る
ゲートウェイが変換表を参照して、宛先を元の内部端末へ戻す

この変換表があることで、単一のグローバルIPアドレスでも、多数の端末が“別々の通信”として外部とやり取りできます。

PATを使う理由

グローバルIPアドレスの節約：少数のアドレスで多くの端末を収容しやすい
構成の単純化：端末側はプライベートアドレスのままで運用しやすい
外部公開面の抑制：内部端末が直接インターネットに露出しにくくなる（※ただし“安全になる”ではなく、別途ポリシー設計が必要）

PATの設定方法

PATは多くの場合、ルーターやファイアウォールで「送信元NAT（SNAT）」として実装されています。製品ごとに画面や名称は異なりますが、考え方はほぼ共通です。

PATの設定に必要な機器

PAT（NAPT）に対応したルーターまたはファイアウォール
内部ネットワーク（プライベートIP）を持つ端末群
インターネット回線（ISP）と接続するWAN回線・終端装置（ONU/モデム等）

ルーターでのPAT設定の基本手順（一般論）

WAN側インターフェースに、ISPから割り当てられたグローバルIP（またはPPPoE等）を設定する
LAN側にプライベートIP帯（例：192.168.0.0/24）とDHCP等を設定する
NAT/PAT（NAPT、マスカレード等）の機能を有効化し、LAN→WANの送信元変換を設定する
必要なセキュリティ設定（ステートフルFW、許可ポリシー、ログ等）を整える
端末から名前解決・Web閲覧等ができるかを確認し、ログや変換表で挙動を確認する

ファイアウォールでのPAT設定の基本手順（一般論）

外部（WAN）／内部（LAN）のゾーンやインターフェース設計を確定する
送信元NAT（SNAT）ルールとして、内部アドレス範囲→グローバルIP（インターフェースIP等）へ変換するルールを作成する
合わせて、通信許可ポリシー（どこからどこへ、何を許すか）を明示する
ログ（許可・拒否・NAT）を必要十分に取得し、運用上の見える化を行う

PATの設定における注意点

「外部公開」と「外向き通信」を混同しない：外部から内部へ到達させたい場合は、PATとは別にポート開放（DNAT/ポートフォワード）等が必要になります。
安易なDMZ設定は避ける：手早い切り分け目的で全開放するのは危険です。必要最小限のポートだけを明示して公開する考え方が基本です。
ログ設計を先に決める：多対1の変換では、同じグローバルIPに多数の通信が集約されます。後から追跡できるよう、NATログ（変換前後のIP/ポートと時刻）の扱いを決めておくと安心です。
タイムアウト値が“体感”に効く：セッションの保持時間が短すぎると、特定アプリで切断が増えることがあります（逆に長すぎると表が膨らみやすい）。

PATのメリットとデメリット

PATを導入するメリット

グローバルIPアドレスの節約：少数のアドレスで多数端末の外向き通信を収容しやすい
外部公開面の抑制：内部端末のアドレス体系をインターネットから直接見えにくくできる
運用のしやすさ：内部はプライベートアドレスで統一しやすく、移設や増設の影響を抑えやすい

PATの欠点と限界

ポート資源の制約：同一グローバルIPで同時接続が増えると、利用可能ポートやセッション表が枯渇する可能性
一部プロトコルとの相性：アドレス情報をアプリ層で埋め込む方式や、NAT越えを前提にしない方式では追加設定が必要になることがあります
追跡・調査の難しさ：同一グローバルIPに集約されるため、インシデント調査や監査で“誰が何をしたか”を追うにはNATログが重要になります
暗号化トラフィックの可視性：PAT自体は暗号を解けないため、別途の監視設計（出口対策・エンドポイント対策等）が必要です

PATに適したネットワーク環境

オフィス、SOHO、拠点網など、端末の外向き通信が中心の環境
グローバルIPを多く確保できない、または確保したくない環境
外部公開は限定的で、必要なサービスのみ明示して公開する方針の環境

PATを使う上での留意点

「ポート番号の競合」より「ポート資源の枯渇」を意識する：端末同士が同じ宛先へ同じポートで通信しても、PAT側で外向きポートを割り当て直すため、衝突は通常回避されます。問題になりやすいのは、同時接続が増えて割当先が足りなくなるケースです。
公開が必要ならルールを最小化する：ポートフォワードは“必要な宛先・必要なポートだけ”に絞るのが原則です。
将来の移行も視野に入れる：IPv6の併用や、アプリ側の設計変更で“PATに頼らない”構成が選択肢になることもあります。

PATのトラブルシューティング

PATは便利な一方で、切り分けでは「どこで詰まっているか」を順序立てて見ることが重要です。

PATが機能しない場合の主な原因

送信元NAT（PAT）ルールの適用条件ミス（対象ネットワーク／宛先ゾーンの誤り）
デフォルトゲートウェイやルーティングの誤り（戻り経路不整合）
ファイアウォールポリシーで遮断されている（NATは通っても許可されない）
DNSの問題（“通信できない”の実態が名前解決失敗）
セッション表／ポート資源の枯渇、タイムアウトの不整合

PATの設定ミスの見つけ方（切り分け手順）

端末のIP設定（IP/マスク/ゲートウェイ/DNS）を確認する
LAN内疎通（ゲートウェイまでping/疎通）を確認する
DNSとIP直打ちを分けて確認する（例：名前解決と、IP宛の疎通を別々に）
ゲートウェイ側で、NATルールのマッチ状況（ヒットカウント等）を確認する
変換表（セッション表）に通信が載っているか、戻りパケットが来ているかを確認する

PATのログ確認のポイント

NATログ：変換前（内部IP:ポート）→変換後（外部IP:ポート）の対応が出ているか
ポリシーログ：許可/拒否のどちらで落ちているか
セッション数：短時間に急増していないか（枯渇兆候）
エラーログ：リソース不足、テーブル上限、異常終了等が出ていないか

よくある対処事例

症状	想定原因	対処の方向性
特定サービスだけ不安定	タイムアウト不整合／アプリ相性	タイムアウト見直し、必要な補助機能の有無確認
一部端末だけ通信不可	端末設定／ルーティング／ポリシー差分	IP設定と経路、該当端末の通信ログを個別に確認
混雑時に全体が遅い・切れる	セッション表／ポート資源枯渇	上限値・装置性能の見直し、出口の増強、帯域制御の検討

切り分けが難しい場合は、端末側のキャプチャとゲートウェイ側のNAT/ポリシーログを突き合わせると、原因が一気に絞れることがあります。

まとめ

PAT（Port Address Translation）は、IPアドレスに加えてポート番号も変換することで、少数のグローバルIPアドレスを多数端末で共有し、外向き通信を成立させる技術です。IPアドレス枯渇への現実的な対策として広く普及している一方、セッションやポート資源の制約、ログ追跡の難しさ、一部プロトコルとの相性といった注意点もあります。導入時は「NATの設定」だけで終わらせず、許可ポリシー、ログ、タイムアウト、公開要件（必要な場合は最小限のポートフォワード）まで含めて設計すると、運用でつまずきにくくなります。