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

はじめに

NEC IX シリーズは、Cisco に似た CLI 体系を持ちながら、NAT まわりの設計思想が大きく異なるルーターです。最大の特徴は、NAT（アドレスのみを変換）と NAPT（アドレスとポート番号を変換）が独立した別機能として実装されており、それぞれ ip nat 系・ip napt 系の別コマンドで設定する ことです。Cisco では PAT も含めて「NAT」の設定体系に統合されているため、Cisco の感覚のまま IX を触ると、この分離構造でつまずきます。

本記事では、NAT と NAPT の違いとパケット評価フロー（併用時の優先順位）の整理から始め、NAPT によるインターネット接続の基本設定、サーバー公開の 3 つの方法（静的 NAPT・サービス NAPT・静的 NAT）、NAPT キャッシュの確認方法までを解説します。コマンドは NEC の公式ドキュメント（IX-R/IX-V 機能説明書・コマンドリファレンス・設定事例集、UNIVERGE IX シリーズ公式 FAQ）に基づきます。IX-R/IX-V シリーズのドキュメントを基準としますが、コマンド体系は従来の IX2000/3000 シリーズ（IX2215 等）と基本的に共通です。

なお、NAT・NAPT そのものの動作原理については、関連記事『NAT とは｜変換テーブルの仕組みと NAPT・IP マスカレードの違い』を参照してください。

先に結論を示すと、実務で構成する IX の NAT の大半は、WAN 側インターフェイスへの ip napt enable の 1 行（インターネット接続）と、サーバー公開が必要な場合の ip napt static または ip napt service の追加 で構成できます。グローバル IP アドレスを複数保有し 1 対 1 の変換が必要な場合にのみ ip nat static を併用し、その際は NAT が NAPT より優先処理されることを踏まえて設計します。

NEC IX の NAT/NAPT の全体像

設定コマンドに入る前に、IX の NAT/NAPT の構造を押さえます。「NAT と NAPT は別機能」「併用時は NAT が優先」という 2 点が、この後のすべての設定と切り分けの土台になります。

NAT と NAPT の違い（アドレスのみ / アドレス＋ポート）

NAT（ip nat 系コマンド）は、IPv4 アドレスのみを変換する機能 です。1 対 1 の対応付けを固定的に定義する静的 NAT（ip nat static）と、アドレスプールから動的に割り当てる動的 NAT（ip nat dynamic）があります。ポート番号を変換しないため、同時に通信する端末の数だけグローバルアドレスが必要です。

NAPT（ip napt 系コマンド）は、IPv4 アドレスとトランスポート層のポート番号をあわせて変換する機能 です。

参考: NEC – UNIVERGE IX シリーズ FAQ（IPv4、NAT、DHCP）
「NAPTは、内部ネットワークで使用しているプライベートIPv4アドレスとトランスポート層のポート番号から、外部ネットワークアクセス用のグローバルIPv4アドレスとトランスポート層のポート番号に変換します」
https://jpn.nec.com/univerge/ix/faq/ip.html

グローバルアドレス 1 個で多数の端末を収容できるため、インターネット接続の標準はこちらです。他機種の用語と対応させると、IX の NAPT は Cisco の PAT（overload）、YAMAHA の IP マスカレードに相当します。

NAPT には、機能上の重要な性質がもう 1 つあります。動的な NAPT は「内→外」方向の通信で変換キャッシュが生成されて初めて「外→内」方向の戻り通信を通すため、キャッシュのない外部からの新規通信はすべてブロックされる、簡易的なファイアウォールとして動作します。外部からの通信を意図的に受け入れるには、静的 NAPT またはサービス NAPT の明示的な設定が必要です。

参考: NEC – IX-R/IX-V 機能説明書 2.12. NAT/NAPT の設定
「内部向きでは、staticまたはserviceの設定がないと、外部から通信は開始できません」
https://support.necplatforms.co.jp/ix-nrv/manual/fd/02_router/13-2_nat.html

なお、Cisco の NAT が「inside/outside のドメイン宣言＋グローバルコンフィグでの変換ルール定義」という 2 層構造であるのに対し、IX の NAT/NAPT は WAN 側インターフェイスの設定内で完結する 構造です。inside 側のインターフェイスには何も設定しません。Cisco の NAT 体系との比較は、関連記事『Cisco NAT 設定の手順｜静的 NAT と PAT（overload）の使い分け』を参照してください。

パケット評価フローと NAT・NAPT 併用時の優先順位

NAT と NAPT は同一インターフェイスで併用でき、その場合の処理順序は公式のパケット評価フローとして定義されています。内→外方向のパケットは、以下の順で評価されます。

1. キャッシュ処理（NAPT キャッシュ → NAT キャッシュの順に照合し、該当すれば変換して終了）
2. NAT 処理（静的 NAT → 動的 NAT の順。動的 NAT で変換アドレスが枯渇している場合は 廃棄）
3. NAPT 処理（NAPT 対象の判定 → 静的 NAPT → サービス NAPT → 動的 NAPT の順。変換ポートが枯渇している場合は 廃棄）
4. NAT・NAPT のいずれにも該当しない場合は、変換せずそのまま転送

このフローから、実務上重要な 2 つの帰結が導けます。

NAT は NAPT より優先されます

公式 FAQ にも併用可能であり NAT が優先して処理される旨が明記されています。静的 NAT の対象アドレスからの通信は、NAPT の設定内容にかかわらず NAT で変換されるため、「NAPT のアドレスで出ていくはず」という想定とずれた場合はまず NAT 側の定義を疑います。

枯渇時の挙動は「廃棄」です

動的 NAT のアドレス枯渇、NAPT のポート枯渇のいずれも、該当パケットは変換されずに破棄されます。YAMAHA RTX の address inner 範囲外のような「素通し」ではない点は、機種をまたいで運用する際に押さえておきたい挙動差です。

なお、評価フローの詳細（外→内方向のフロー、フィルタとの処理順序）は、トラブルシューティングのセクションで改めて取り上げます。

NAPT の設定手順（インターネット接続の基本）

IX の NAPT は、WAN 側インターフェイスへの設定だけで完結します。最小構成は 1 行ですが、その 1 行が内部的にどう展開されているかを知っておくと、ip napt address・ip napt inside list による制御が素直に理解できます。

ip napt enable の基本設定

LAN 内の端末をインターネットに接続させる NAPT の最小設定は、WAN 側インターフェイスへの ip napt enable の 1 行です。LAN 側インターフェイスには何も設定しません。

WAN 側が DHCP 払い出しの場合

interface GigaEthernet0.0
  ip address dhcp receive-default
  ip napt enable                     # これだけで LAN 側全端末の NAPT が動作する
  no shutdown

PPPoE の場合

ppp profile ppp-prof
  authentication myname user-a@example.com
  authentication password user-a@example.com password-a
!
interface GigaEthernet0.1
  encapsulation pppoe
  ppp binding ppp-prof
  ip address ipcp
  ip napt enable
  no shutdown

参考: NEC – IX-R/IX-V 設定事例集 NAT/NAPT 設定
https://support.necplatforms.co.jp/ix-nrv/manual/ex/Section1/7_nat_napt.html

公式機能説明書によると、ip napt enable のみを設定した場合、アドレスと範囲指定は内部的に次の既定値で動作します。

• 変換アドレス: ip napt address <インターフェイスアドレス>（インターフェイスに設定された、または DHCP / IPCP で取得したアドレス）
• 変換対象の範囲: すべて（範囲指定なし）

つまり最小構成の 1 行は、「このインターフェイスのアドレスを変換アドレスとして、通過するすべての内→外通信を NAPT する」という設定の省略形です。この既定値を明示的に変更するのが、次に解説する 2 つのコマンドです。

参考: NEC – IX-R/IX-V 機能説明書 2.12. NAT/NAPT の設定
https://support.necplatforms.co.jp/ix-nrv/manual/fd/02_router/13-2_nat.html

ip napt address によるアドレス範囲の制御

変換アドレスの変更（ip napt address）

インターフェイスのアドレスとは別のグローバル IP アドレスを NAPT の変換アドレスに使いたい場合は、ip napt address で明示的に指定します。固定 IP 複数個の契約で、インターフェイスのアドレスとは別のアドレスを LAN からのインターネットアクセス用に割り当てる構成などで使用します。

interface GigaEthernet0.0
  ip address 203.0.113.1/24
  ip napt enable
  ip napt address 203.0.113.2        # 変換アドレスをインターフェイスアドレス以外に変更
  no shutdown

なお、ヘアピン NAT（ip napt hairpinning）は ip napt address で指定したアドレス宛のパケットにのみ適用される仕様のため、このコマンドはヘアピン構成の設計にも関わります。

変換対象範囲の制御（ip napt inside list）

NAPT の変換対象を特定の送信元に限定したい場合は、アクセスリストと組み合わせて ip napt inside list を設定します。公式機能説明書では、DMZ にグローバルアドレスの公開サーバーを置き、社内 LAN（プライベートアドレス）だけを NAPT 対象にする構成が用途として挙げられています。

ip access-list napt-list1 permit ip src 192.168.0.0/24 dest any
!
interface GigaEthernet0.0
  ip address 10.0.0.1/24
  ip napt enable
  ip napt inside list napt-list1     # 192.168.0.0/24 のみ NAPT 変換対象
  no shutdown

このコマンドには、押さえておくべき仕様が 3 つあります。

• 範囲外のパケットは NAPT 変換対象外となり、変換されないまま転送されます。第 1 章で整理したパケット評価フローの通り、NAT・NAPT のいずれにも該当しないパケットは廃棄ではなく素通しです。YAMAHA RTX の address inner 範囲外と同型の「プライベート IP のまま WAN へ出ていく」トラブルにつながるため、範囲設計とセグメント追加時の運用は同じ注意が必要です。
• NAPT アドレス自体（この例ではインターフェイスアドレス）は、リストに関係なく常に変換対象です。
• アクセスリストにルーター自身のアドレスを含めない場合、自発パケット（ルーター自身が送信する NTP・DNS・syslog 等）は NAPT 変換されません。公式機能説明書に明記されている注意点で、「LAN の端末は通信できるのにルーター自身の時刻同期だけ失敗する」という切り分けの難しい事象の原因になります。

送信元別のアドレス使い分け（複数 NAPT）

inside list に outside オプションを組み合わせると、1 つのインターフェイスで送信元セグメントごとに異なる変換アドレスを使い分けられます。公式機能説明書の設定例に基づく構成は以下の通りです。

ip access-list access-1 permit ip src 10.10.10.0/24 dest any
ip access-list access-2 permit ip src 10.10.20.0/24 dest any
ip access-list access-2 permit ip src 10.0.0.1/24 dest any    # 自発パケット用に自アドレスを含める
!
interface GigaEthernet0.0
  ip address 10.0.0.1/24
  ip napt enable
  ip napt address 10.0.0.2                          # access-1 用の変換アドレス
  ip napt inside list access-1
  ip napt inside list access-2 outside 10.0.0.1     # access-2 は物理アドレスで変換
  no shutdown

この例では、10.10.10.0/24 からの通信は 10.0.0.2 に、10.10.20.0/24 からの通信とルーターの自発パケットは 10.0.0.1 に変換され、それ以外は NAPT されません。セグメントごとに送信元グローバル IP を分けたい要件（対外接続先のアクセス制限が送信元 IP 単位の場合など） に対応できる構成です。FortiGate であれば central-snat-map、Cisco であればルートマップ NAT で実現する要件に相当しますが、IX ではインターフェイス設定内で完結します。

サーバー公開の設定手順（static / service）

第 1 章で整理した通り、動的な NAPT は変換キャッシュのない外部からの新規通信をすべてブロックします。内部サーバーを外部に公開するには明示的な設定が必要で、IX には 静的 NAPT（ポート単位）・サービス NAPT（サービス名管理）・静的 NAT（アドレス単位の 1 対 1） の 3 つの方法があります。グローバル IP が 1 個ならポート単位（static または service）、公開サーバー専用のグローバル IP を割り当てられるなら静的 NAT、という使い分けが基本です。

静的 NAPT（ip napt static）によるポート単位の公開

NAPT アドレスの特定プロトコル・ポート番号を、特定の内部端末専用に固定する設定です。外部からそのポート宛に届いた通信は、キャッシュの有無にかかわらず指定した内部アドレスへ転送されます。

interface GigaEthernet0.1
  encapsulation pppoe
  ppp binding ppp-prof
  ip address ipcp
  ip napt enable
  ip napt static 192.168.0.80 tcp 443    # NAPT アドレスの TCP 443 宛を 192.168.0.80 へ
  ip napt static 192.168.0.80 tcp 80
  no shutdown

構文は「内部アドレス、プロトコル、ポート番号」の順で、TCP・UDP のほかプロトコル番号での指定（例: ICMP を通す ip napt static 192.168.0.80 1）もできます。ポート番号を持たないプロトコルを外部から受け入れたい場合の手段です。

静的 NAPT には、他機種にない重要な用途がもう 1 つあります。NAPT 有効時は、ルーター自身宛の通信も変換キャッシュがなければ届かないため、ルーター自身のサービス（SSH での外部からの管理アクセス等）を受けるにも静的 NAPT の設定が必要 です。この場合、内部アドレスの代わりにインターフェイス名を指定します。

interface GigaEthernet0.1
  ip napt static GigaEthernet0.1 tcp 22   # ルーター自身の SSH を外部から受け付ける

参考: NEC – IX-R/IX-V 設定事例集 NAT/NAPT 設定（PPPoE ＋サーバー公開の設定例）
https://support.necplatforms.co.jp/ix-nrv/manual/ex/Section1/7_nat_napt.html

「NAPT を有効にしたら外部からルーターにログインできなくなった」という事象はこの仕様によるもので、故障や別の設定ミスと切り分けるためにも押さえておきたいポイントです（なお、外部からの管理アクセスの開放はセキュリティリスクを伴うため、送信元制限のフィルタと併用することが推奨されます）。

サービス NAPT（ip napt service）による予約サービス名での公開

サーバー公開のもう 1 つの方法が、サービス名で変換を管理する ip napt service です。HTTP・HTTPS・SMTP・POP3 など、よく使うプロトコルは予約サービス名として定義されています。

interface GigaEthernet0.1
  ip napt enable
  ip napt service http 192.168.0.80 none tcp 80      # Web サーバーの公開
  ip napt service https 192.168.0.80 none tcp 443
  ip napt service smtp 192.168.0.81 none tcp 25      # メールサーバーの公開

構文は「サービス名、内部サーバーアドレス、変換ポート、プロトコル、ポート番号」の順で、3 番目のフィールドはポート変換の指定です（none はポート変換なし）。予約サービス名を使う場合、変換ポート以降のフィールドは省略できることが公式コマンドリファレンスに明記されています。

参考: NEC – IX-R/IX-V コマンドリファレンス NAPT
「予約サービス名を使用した場合、PORT-TRANS、PROTOCOL、PORT-RANGE は省略可能です」
https://support.necplatforms.co.jp/ix-nrv/manual/crm/cli/ipv4/cli_napt.html

静的 NAPT との使い分けは、機能的にはどちらでもサーバー公開が可能なため、構成の管理しやすさで選ぶ のが実務的です。公開サービスが複数あり設定の可読性を上げたい場合はサービス NAPT（show running-config でサービス名から用途が読み取れます）、単発のポート開放やルーター自身のサービス公開、プロトコル番号指定が必要な場合は静的 NAPT が向いています。なお、サービス NAPT の変換は、内部サーバーアドレスが有効範囲内である NAPT アドレスでのみ行われる仕様のため、ip napt inside list で範囲を制御している構成では対象範囲との整合に注意が必要です。

公開設定と対になるのがフィルタです。ip filter による受信フィルタを WAN 側に適用している構成では、公開ポートの着信許可が必要になりますが、IX のフィルタは変換前後どちらのアドレスで書くべきかという評価順序の問題 があります。これは次のセクション（動作確認とトラブルシューティング）でまとめて解説します。

また、公開後の動作確認を内部 LAN からグローバル IP 宛に行うと、ヘアピン NAT（ip napt hairpinning）を構成していない限り失敗し、機種によってはルーターの管理画面に接続されてしまいます。折り返し通信の仕組みと IX での構成方法は、関連記事『ヘアピン NAT とは｜内部からグローバル IP でアクセスできない原因と対処』で解説しています。

静的 NAT（ip nat static）による 1 対 1 変換

公開サーバー専用のグローバル IP アドレスを割り当てられる場合は、静的 NAT でアドレス単位の 1 対 1 変換を定義します。NAT の有効化（ip nat enable）と変換ルールを、WAN 側インターフェイスに設定します。

interface GigaEthernet0.0
  ip address 203.0.113.1/24
  ip nat enable
  ip nat static 192.168.0.80 203.0.113.80   # 内部 192.168.0.80 を 203.0.113.80 で公開
  ip napt enable                             # LAN のインターネットアクセス用 NAPT と併用可
  no shutdown

構文は「内部アドレス、外部アドレス」の順です。ポートを限定しない全プロトコルの 1 対 1 変換となるため、公開サーバーに対する不要な着信はフィルタで明示的に遮断する設計が前提になります。

この構成のポイントは NAT と NAPT の併用と優先順位 です。第 1 章のパケット評価フローで整理した通り、NAT は NAPT より先に評価されるため、192.168.0.80 からの通信は常に静的 NAT（203.0.113.80）で変換され、それ以外の LAN 端末は NAPT（203.0.113.1）で変換されます。公開サーバーの送信元を専用アドレスに固定しつつ、一般端末のインターネットアクセスを 1 台でまかなう、固定 IP 複数個契約の標準的な構成です。

参考: NEC – UNIVERGE IX シリーズ FAQ（NAT と NAPT の併用）
https://jpn.nec.com/univerge/ix/faq/ip.html

なお、動的 NAT（ip nat dynamic）はアドレスプールと ACL の組み合わせで構成できますが、公式機能説明書自体が「NAPT の方が有効なので通常は NAPT を利用」する旨を案内しており、実務での出番は限定的です。1 対 1 の動的割り当てが明確な要件になっている場合のみ検討します。

動作確認とトラブルシューティング

IX の NAT/NAPT の切り分けは、NAPT キャッシュテーブルの確認が起点です。あわせて、IX 特有の「フィルタとの評価順序」を押さえておくと、公開設定まわりのトラブルに迷わず対応できます。

NAPT キャッシュの確認コマンド

現在の NAPT キャッシュテーブル（変換の対応付け）は、show ip napt translation で確認します。インターフェイス名・プロトコルでの絞り込みと、verbose による詳細表示に対応しています。

Router# show ip napt translation
Interface: GigaEthernet0.1
NAPT Cache - 5737 entry, 14263 free, 12878 peak, 30205093 create, 0 overflow
Codes: A - ALG, S - Static, Service
（以下、変換エントリの一覧）

参考: NEC – IX-R/IX-V コマンドリファレンス NAPT（show ip napt translation）
https://support.necplatforms.co.jp/ix-nrv/manual/crm/cli/ipv4/cli_napt.html

1 行目のサマリーが監視・切り分けの要点です。

• entry / free: 使用中エントリ数と残り容量。キャッシュの最大エントリ数は機種・ソフトウェアバージョンで異なり、公式 FAQ に機種別の一覧があります（例として、Ver.9.5 以下の IX2106 / IX2215 は 65,535）。
• peak: エントリ数のピーク値。収容設計の妥当性を判断する材料になるため、定常監視に加えておく ことが推奨されます。
• overflow: キャッシュ枯渇により変換できなかった回数。第 1 章のパケット評価フローで整理した通り、NAPT のポート・キャッシュ枯渇時のパケットは廃棄されるため、このカウンタが増加していれば「散発的に通信が失敗する」事象の有力な原因候補 です。

エントリのコード（S = Static / Service など）で、静的設定による変換と動的な変換を見分けられます。キャッシュの手動クリアは clear ip napt translation（インターフェイス指定可）です。設定変更後に旧キャッシュの挙動が残る場合に使用しますが、既存セッションの変換情報が失われるため、本番環境では影響を確認した上で実行します。

よくあるトラブルと切り分け（フィルタの評価順序・キャッシュ枯渇）

トラブル 1: フィルタを変換後のアドレスで書いてしまい、通信が通らない / 全部通る

IX でサーバー公開とフィルタを併用する際に最も間違えやすいのが、フィルタに書くアドレスです。公式 FAQ に評価順序が明記されています。

• 受信方向: NAPT 処理 → フィルタ処理
• 送信方向: フィルタ処理 → NAPT 処理

つまり、どちらの方向でも フィルタは NAPT 変換を考慮せず、元々の（内部ネットワーク側の）IP アドレスで記述します。例えば WAN 側受信フィルタで公開サーバー宛の HTTPS を許可する場合、宛先にはグローバル IP ではなく変換後の内部アドレスを指定します。

# 宛先は変換後の内部アドレスで書く（グローバル IP では一致しない）
ip access-list wan-in-flt permit tcp src any sport any dest 192.168.0.80/32 dport eq 443
!
interface GigaEthernet0.1
  ip napt enable
  ip napt static 192.168.0.80 tcp 443
  ip filter wan-in-flt 10 in

参考: NEC – UNIVERGE IX シリーズ FAQ（NAPT とフィルタの処理順序）
https://jpn.nec.com/univerge/ix/faq/ip.html

Cisco IOS はこの逆（受信時は NAT 変換前＝グローバル側アドレスでフィルタ評価）のため、Cisco の感覚で ACL を書くと IX では一致しません。機種をまたぐエンジニアが特につまずきやすいポイントです。

トラブル 2: NAPT を有効にしたらルーター自身の通信ができなくなった

2 つの典型パターンがあります。

1. 外部からルーターへの管理アクセス（SSH 等）が届かない → 前章で解説した通り、ip napt static GigaEthernet0.1 tcp 22 のようにインターフェイス名指定の静的 NAPT が必要です。
2. ルーター自身の自発パケット（NTP・DNS・syslog 等）だけ失敗する → ip napt inside list の ACL にルーター自身のアドレスが含まれていないことが原因です（第 2 章で解説した公式仕様）

トラブル 3: 散発的・断続的に通信が失敗する

show ip napt translation の overflow カウンタを確認します。増加していればキャッシュ枯渇です。エントリの持続時間は ip napt translation 系コマンド（最大エントリ数・プロトコル別タイムアウト）で調整できるため、大量の短命セッションが発生する環境ではタイムアウトの短縮を検討します。恒常的に枯渇する場合は、キャッシュ容量の大きい上位機種への更改も含めた検討になります。

制約事項・設計上の注意

最後に、IX の NAT/NAPT を設計に組み込む際に把握しておきたい制約と注意点を整理します。

NAPT キャッシュの最大エントリ数は機種・バージョンに依存する

キャッシュサイズが収容能力の上限を決めるため、端末数と 1 端末あたりのセッション数（近年の Web アプリは 1 端末で数十〜数百セッションを張ります）から必要量を見積もり、公式 FAQ の機種別一覧と突き合わせて機種選定します。

ペイロードにアドレスを含むプロトコルは ALG の対応状況を確認する

IX には ip napt alg コマンドがあり、ペイロード内にアドレス情報を持つプロトコルの変換補助を制御できます。NAT 越しに特定のアプリケーションだけが失敗する場合は、対象プロトコルの ALG 対応状況をコマンドリファレンスで確認します。

ヘアピン NAT には利用条件がある

ip napt hairpinning は TCP・UDP・ping のみ対応、1 装置 1 インターフェイスのみ、ip napt address で指定したアドレス宛のみ適用、UNIVERGE IX-V のクラウド利用時は使用不可、という公式制約があります。また 1 回の変換で 2 つの NAPT キャッシュを消費するため、キャッシュ容量の見積もりにも影響します。詳細は関連記事『ヘアピン NAT とは｜内部からグローバル IP でアクセスできない原因と対処』を参照してください。

ドキュメントは IX-R/IX-V 系と従来 IX 系で体系が分かれている

本記事は IX-R/IX-V シリーズのドキュメントを基準としています。コマンド体系は従来の IX2000/3000 シリーズと基本的に共通ですが、機能の対応状況（ヘアピン NAT の対応バージョン等）には差異があるため、従来機種では使用機種・バージョンのマニュアルでの最終確認が推奨されます。

まとめ

本記事では、NEC IX の NAT/NAPT 設定を、2 つの機能の違いとパケット評価フローの整理から、サーバー公開の 3 手法、キャッシュの確認方法まで解説しました。「NAT と NAPT は別機能で NAT が優先」「フィルタは変換前の内部アドレスで書く」という 2 つの仕様を押さえておけば、構築と切り分けの両方に一貫した理解で対応できます。

• NAT はアドレスのみ、NAPT はアドレスとポートを変換する別機能
• インターネット接続は WAN 側への ip napt enable の 1 行で動作
• 併用時は NAT が NAPT より優先して処理される
• サーバー公開は static・service・静的 NAT の 3 手法を要件で使い分ける
• ルーター自身宛の通信の受け入れにはインターフェイス名指定の静的 NAPT が必要
• フィルタは NAPT 変換を考慮せず内部側のアドレスで記述する
• キャッシュ枯渇は show ip napt translation の overflow カウンタで確認

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