Cisco IOSのNAT・ACL・ルーティング処理順は、inside-to-outsideかoutside-to-insideか、input ACLかoutput ACLか、NVI/VRF/platform機能を使うかで見方が変わります。暗記表だけでルールを設計せず、対象バージョンのパケット processing資料とdebug以外の状態情報で確認します。
この記事はネットワークエンジニア転職完全ガイドの関連テーマです。工程の全体像から確認したい場合はそちらへ。
⭕️インフラエンジニアが
設計で理解しておきたいことNAT
ACL
Routing
の処理順L3機器に
インターフェイスACL
NAT
Routing
を設定しているとする。では、Gi0/1にパケットが着信した瞬間、
そのパケットは何から処理されるのか。ここを理解していないと、
設計や障害切り分けでハマる。… pic.twitter.com/YPQH7f8FhI— けんと＠設計構築チャンネル (@yeiquer12) 2026年6月21日
Cisco IOSのinside→outside通信でinput ACL、Routing、NAT、output ACLの順を整理したポスト。
Cisco IOSのNAT・ACL・ルーティングはどの順で処理される？
従来型のinside／outside NATを使うCisco IOSでは、通信方向によってNATと経路検索の順序が入れ替わります。Ciscoの解説（検証環境：IOS 12.2(27)）では、inside→outsideは入力ACL→経路検索→NAT→出力ACL、outside→insideは入力ACL→NAT→経路検索→出力ACLです。
| 方向 | 主要な処理順（簡略） | 設計で見る点 |
|---|---|---|
| inside → outside | input ACL → routing → NAT → output ACL | 入力側は変換前の送信元、出力側は変換後の送信元 |
| outside → inside | input ACL → NAT → routing → output ACL | 入力側は公開宛先、出力側は変換後の内部宛先 |
これは掲載資料の構成とIOS版に限った主要段階の説明です。NVI、VRF、Zone-Based Firewall、ハードウェア転送、IOS XEの機種差へ無条件に一般化できません。対象製品と版の資料、ACLカウンター、変換表、実パケットで照合します。
根拠：Cisco：Understand the NAT Order of Operation
insideからoutsideでは何を見る？
例：社内PC 10.0.0.10が外部サーバー 203.0.113.20へ接続し、送信元が 198.51.100.10に変換される場合です。
| 観測点 | 送信元IP | 宛先IP |
|---|---|---|
| inside入力ACL | 10.0.0.10（変換前） | 203.0.113.20 |
| 経路検索 | 10.0.0.10 | 203.0.113.20宛の出力先を選ぶ |
| NAT後／outside出力ACL | 198.51.100.10（変換後） | 203.0.113.20 |
ip access-groupで適用するインターフェースACLと、NAT対象を選ぶためのACLは用途が違います。両方を単に「NATのACL」と呼ばず、設定箇所と評価されるアドレスを分けて記録します。
outsideからinsideでは何を見る？
返信パケットが外部サーバー 203.0.113.20から公開アドレス 198.51.100.10へ戻る場合です。従来型のinside NATでは、outside入力ACLを通った後に宛先が内部PC 10.0.0.10へ逆変換され、その宛先で経路検索されます。
| 観測点 | 送信元IP | 宛先IP |
|---|---|---|
| outside入力ACL | 203.0.113.20 | 198.51.100.10（公開側） |
| NAT後の経路検索 | 203.0.113.20 | 10.0.0.10（内部側） |
| inside出力ACL | 203.0.113.20 | 10.0.0.10 |
変換エントリがない、復路が別のNAT装置へ流れる、経路やACLが合わない場合は戻り通信が成立しません。変換表だけで成功判定せず、両側でパケットとカウンターを確認します。
input・output ACLはどのアドレスを参照する？
症状ごとの原因候補と、次に確認することを次の表にまとめます。正常時の出力と並べて差を見ます。
| 症状・誤り | 主な原因候補 | 次に確認すること |
|---|---|---|
| 図とカウンターが不一致 | 別ルール/経路/参照範囲 | matched sequenceとVRF |
| 変換なし | NAT ACL不一致・inside/outside誤り | statisticsと設定 |
| 変換あり通信なし | 戻り経路・outside ポリシー | reverse direction |
| debugで高負荷 | 無条件debug | カウンター/ログ/キャプチャを先に使う |
設計と実機をどう照合する？
Ciscoのdebug ip パケットやdebug ip natは本番負荷と大量出力を招く可能性があります。maintenance条件とフィルターを設計し、まずshow command、ACL カウンター、フロー record、パケットキャプチャで絞ります。
- 対象機器・インターフェース・VRF/VLAN
- 取得日時・タイムゾーン・ソフトウェアバージョン
- 変更前後の同一コマンド出力
- 期待値・実測値・判定者
- 異常時の停止条件と切り戻し結果
関連する記事
まとめ：暗記した順序ではなく、対象方向のカウンターと変換で検証する
要点は、暗記した順序ではなく、対象方向のカウンターと変換で検証することです。NAT前後どちらのアドレスで一致したかを、ACLのヒットカウンタで確認します。
