本文へ移動

インフラ転職コンパスわからないところから、ひとつずつ。

メニュー

PATとは?NATとの違いとIP・ポート変換の仕組み

PATはIPアドレスとポート等を対応付け、複数の通信を一つまたは少数の変換後アドレスへまとめるNAT方式です。CiscoではNAT overload、RFCではNAPTという表記で説明されます。戻り通信はその対応情報を使って元の端末へ戻します。

インターネット接続で使われますが、外側が必ず公開IPであることはPATの成立条件ではありません。この記事は外側もプライベートIPの隔離ラボを使い、構成と変換表、往復のIP・ポートを追います。

この記事でわかること

  • NAT・PAT・SNAT・DNATは、比較している軸が違う
  • 同じ宛先へ出る2端末を、変換表へ対応させる
  • inside globalは、公開IPであることを意味する固定の呼称ではない
2端末のTCP通信を172.29.240.9の異なるportへ変換し、戻りの宛先を元のIP・portへ戻す隔離ラボ構成と変換表
上はPATの検証構成、下は変換の対応です。外側もプライベートIPで、インターネット接続の構成ではありません。 タップで拡大できます。

NAT・PAT・SNAT・DNATは、比較している軸が違う

用語 指す範囲 見ること
NAT アドレス変換の総称として使われる どのアドレスをどう対応付けるか
Static NAT 固定した1対1のアドレス対応 固定ルールと双方向の到達
Dynamic NAT poolからアドレスを割り当てる 割当と使用数、pool
PAT / NAPT アドレスとport等で多重化する プロトコル、IPとport、対応情報
SNAT / DNAT 送信元・宛先のどちらを変えるか 通信方向と変換されるフィールド

SNATかDNATかは「どちらを変えるか」、PATは「port等を使ってどう識別するか」という軸です。戻りでは逆変換になるため、往路の送信元変換を、戻りでも送信元変換と固定して読まないでください。Staticのポート転送は、外から接続する固定の対応を用意する用途で、動的な外向きPATの戻りとは条件が違います。

参考:RFC 3022:Basic NATとNAPT(2026年10月5日確認)

用語と方向の整理はSNATとDNATの違いへ進めます。製品によってinside/outsideの呼称やstateの持ち方も違うため、実際のルールと観測点を基準にしてください。

同じ宛先へ出る2端末を、変換表へ対応させる

図ではPC-A 172.29.84.15とPC-B 172.29.84.25が、Web-S 172.29.250.25のTCP443へ接続します。PAT後の送信元IPは両方172.29.240.9で、PC-Aのport50115を41015、PC-Bの50125を41025に対応させています。portの値は独自の説明例で、製品が必ずこの番号へ割り当てる規則ではありません。

通信 変換前の送信元 変換後の送信元 宛先
A / TCP 172.29.84.15:50115 172.29.240.9:41015 172.29.250.25:443
B / TCP 172.29.84.25:50125 172.29.240.9:41025 172.29.250.25:443

この例は同じ宛先へ接続するため、変換後の送信元portを分けて識別します。実際は元のportを保持できる場合や、宛先ごとに対応情報を扱う実装があります。「すべての通信で必ず別portに変更する」とは決めつけません。

TCPとUDPはプロトコルも識別に含みます。ICMP EchoはTCP/UDPのportがなく、Identifier等を使う扱いがあるため、「全パケットにportがある」と説明しないでください。変換に伴うIPやTCP/UDP等のchecksumも適切に更新されます。

inside globalは、公開IPであることを意味する固定の呼称ではない

Ciscoのinside localは内側のホストの元の表現、inside globalは外側から見える内側ホストの表現です。このラボではinside globalにプライベート172.29.240.9を使います。インターネットへ到達する公開アドレスや経路を用意した構成ではありません。

外側のWeb-Sのアドレスはこの例で変換しないため、outside localとoutside globalの値は同じです。inside/outsideの文字だけで全フィールドが違うと考えず、何を変えて何を維持するルールかを一行ずつ確認します。

参考:Cisco:NATの用語と設定(2026年10月5日確認)

図はPAT部分に範囲を絞っています。実際のラボでは内側のGW、各区間の経路、Web-Sから変換後IPへ返す経路、対象サービスと許可ルールも別に用意し、図と設定表へ追加します。PATルールだけで通信は成立しません。

戻りは宛先IPとportを、元の端末へ戻す

取得点 戻りパケットの送信元 戻りパケットの宛先
外側 / A 172.29.250.25:443 172.29.240.9:41015
内側 / A 172.29.250.25:443 172.29.84.15:50115
外側 / B 172.29.250.25:443 172.29.240.9:41025
内側 / B 172.29.250.25:443 172.29.84.25:50125

変換後port41015に対する対応情報でPC-Aへ戻します。サーバーのログでは送信元が変換後のIPに見える場合があり、端末を区別するには日時、プロトコル、port、変換ログ等を合わせます。観測点ごとのIPの見え方はSNAT後のログで確認してください。

戻りが別の装置へ到達し、必要なstateがそこにない場合は逆変換できないことがあります。冗長構成では経路と状態同期、切替時の既存セッションを確認します。外側から任意のportへ届くことを、動的PATが新規接続も受け付ける証明にしません。

変換なし・戻りなし・一部失敗を分けて調べる

Cisco IOS系:読み取りの確認例
show ip nat translations
show ip nat statistics
show ip route
show access-lists
show interfaces
症状 確認する場所 証拠
対応が作られない ルール、対象ACL、IF、経路、実通信 元のタプル、設定、hitと取得点
対応はあるが戻りなし 外側への送信、サーバー、復路、FW 外側の要求・応答と経路
戻るが内側へ出ない 対応state、非対称、端末への転送 逆変換、内側capture、ARP・経路
一部だけ失敗 port/state/装置資源、上限、timeout 使用数、失敗カウンター、負荷と時刻
長時間通信だけ切断 idle、keepalive、ルール変更、切替 stateの変化とアプリの再試行

変換表があることだけで、TCP接続やHTTP処理の成功は分かりません。ACLがNATの対象選択用なのか、通信を許可するフィルタなのかも設定場所で読み分けます。NATとFWの参照アドレスや処理順はNAT前後のポリシーで製品ごとに確認します。

capacityとtimeoutは、端末数だけで決めない

1台の端末も多数の接続を作るため、同時変換、port、生成・終了rate、ピーク、timeout、CPU等の上限を確認します。portの数だけで全製品共通の収容端末数を計算しません。TCP/UDPや宛先、複数IPを使う方式でも条件が変わります。

検証では同じ送信元・宛先と処理を使い、前後の変換表・ログ・両側captureを保存します。全変換のclearやタイマー変更は既存接続へ影響するため、調査の最初に一律実施する手順へは入れません。二つの通信を表で追い、最後に端末の正常処理まで確認してください。

筆者の関連ポスト:Xで読む

最近の記事
ピックアップ