ACLのin・out方向を判断する方法｜Cisco構成図とconfigで解説

Cisco ACLのinとoutは、ルーターの対象インターフェースにパケットが入るか、出るかで決めます。端末から見た上り・下りや、送信元から宛先への向きだけで判断すると逆になります。

本文では構成図で通信フローとL3入出力を決め、ip access-group ACL-NAME in|outの設定例、show ip interface、ヒットカウンター、許可・拒否試験を一続きで確認します。

(出典：筆者のX投稿（X：ACLは条件より先に、適用するインターフェースとin・out方向を見ることが重要だと説明したポスト。）)

ACLのin・outとは？

inは対象インターフェースからルーター内へ入った直後、outはルーティング後に対象インターフェースから出る直前にACLを評価します。判断の主語は必ず「そのインターフェースから見たルーター」にします。

構成図ではingressの入力点と出力点を示し、ip access-list extended WEB-INで実装状態を確かめます。関連する観点として、ACL本文だけでなく適用IF、方向、VRF、既存ACL置換、適用漏れを確認する。 ここまで追うと、用語とpacketの動きがつながります。

成果物には「送信元・宛先・protocol・port・方向を固定」の結果と判断理由を残します。ACL本文だけでなく適用IF、方向、VRF、既存ACL置換、適用漏れを確認する。 これにより、担当者が変わっても同じ条件で再確認できます。

(出典：Cisco公式ドキュメント（公式・一次情報）)

ルーター目線で考えるとは？

実務の開始点は「通信要件と既存policyを保存」です。PCからサーバーへ向かう通信をGi0/1で受けるならGi0/1 in、Gi0/2から送るならGi0/2 outです。矢印を構成図に描き、機器目線へ変換してからconfigを書きます。 その結果を該当するshow出力やpacket captureで確認します。期待値には、同じ通信でも適用インターフェースを変えると方向表現が変わる。

成果物には「通信要件と既存policyを保存」の結果と判断理由を残します。ACL本文だけでなく適用IF、方向、VRF、既存ACL置換、適用漏れを確認する。 これにより、担当者が変わっても同じ条件で再確認できます。

構成図からACLの適用場所を決める手順は？

送信元から宛先へ通信線を引き、通過するL3インターフェースを順番付けします。各IFでパケットがルーターへ入るならin、ルーターから出るならoutです。変更後は許可通信と拒否通信の両方を試験します。

送信元、宛先、protocol、portを固定して矢印を引き、対象interfaceを通過するときの向きを確認してからip access-groupを設定します。

「構成図から適用場所を決める手順」では、要件をいきなりconfigへ置き換えず、対象、方向、入力値、期待出力を中間表にします。設計上の要点は次のとおりです。同じ通信でも適用インターフェースを変えると方向表現が変わる。

投入前に「rule順序・適用IF・NAT前後をレビュー」を行い、interfaceと既存設定の干渉をレビューします。例としてPCからサーバーへ向かう通信をGi0/1で受けるならGi0/1 in、Gi0/2から送るならGi0/2 outです。矢印を構成図に描き、機器目線へ変換してからconfigを書きます。 この条件を手順書と試験表にも引き継ぎます。

投入後は該当するshow出力やpacket captureだけで完了にせず、実通信、counter、logのいずれかで裏付けます。標準ACLは送信元だけを見るため一般に宛先寄りへ置く。 戻せるconfig差分と中止条件も同時に用意します。

標準ACLと拡張ACLはどこに配置する？

構成図ではsourceの入力点と出力点を示し、ip access-list extended WEB-INで実装状態を確かめます。関連する観点として、ACL本文だけでなく適用IF、方向、VRF、既存ACL置換、適用漏れを確認する。 ここまで追うと、用語とpacketの動きがつながります。

成果物には「許可・拒否・戻り通信を実行」の結果と判断理由を残します。ACL本文だけでなく適用IF、方向、VRF、既存ACL置換、適用漏れを確認する。 これにより、担当者が変わっても同じ条件で再確認できます。

ip access-list extended WEB-IN
 permit tcp 10.0.0.0 0.0.0.255 host 192.0.2.10 eq 443
 deny ip any any log
interface GigabitEthernet0/1
 ip access-group WEB-IN in
show ip interface GigabitEthernet0/1

ip access-group設定の具体例は？

「ip access-group設定例」では、要件をいきなりconfigへ置き換えず、対象、方向、入力値、期待出力を中間表にします。設計上の要点は次のとおりです。拡張ACLは送信元・宛先・プロトコル・ポートを見られるため一般に送信元寄りへ置く。

投入前に「counter・session・log・server応答を照合」を行い、destinationと既存設定の干渉をレビューします。例としてPCからサーバーへ向かう通信をGi0/1で受けるならGi0/1 in、Gi0/2から送るならGi0/2 outです。矢印を構成図に描き、機器目線へ変換してからconfigを書きます。 この条件を手順書と試験表にも引き継ぎます。

投入後はip access-group WEB-IN inだけで完了にせず、実通信、counter、logのいずれかで裏付けます。inは対象インターフェースから機器内部へ入る通信。 戻せるconfig差分と中止条件も同時に用意します。

show ip interfaceでACLの適用方向をどう確認する？

show ip interface INTERFACEのInbound access listとOutgoing access listで、ACL名と方向を確認します。さらにshow access-listsでACEの順序とヒットカウンターを見て、想定したパケットが想定した行で評価されたかを判定します。

開始点は「送信元・宛先・protocol・port・方向を固定」です。出力には対象機器、VRF・VLAN・interface、取得時刻を添え、構成図や対向機器の結果と照合します。outは経路選択後に対象インターフェースから出る通信。

想定と違っても、その場でclearや設定変更はしません。ACL本文だけでなく適用IF、方向、VRF、既存ACL置換、適用漏れを確認する。 この順序なら、作業前後で同じ条件を比較できます。

適用方向ではどんなミスが起きやすい？

「適用方向ミス」では、最初から原因を1つに決めず、正常な区間と異常な区間を分けます。判断の手掛かりは次の点です。outは経路選択後に対象インターフェースから出る通信。

現場では「送信元側は必ずinと固定化」という早合点を避け、PCからサーバーへ向かう通信をGi0/1で受けるならGi0/1 in、Gi0/2から送るならGi0/2 outです。矢印を構成図に描き、機器目線へ変換してからconfigを書きます。 変更前に対象、取得時刻、直前変更を記録し、再現条件を崩さないことが重要です。

確認は「通信要件と既存policyを保存」から進めます。該当するshow出力やpacket captureでextended ACLの期待値と実測値を比べます。さらに別の証跡では、同じ通信でも適用インターフェースを変えると方向表現が変わる。

変更前後はどう試験する？

実務の開始点は「rule順序・適用IF・NAT前後をレビュー」です。PCからサーバーへ向かう通信をGi0/1で受けるならGi0/1 in、Gi0/2から送るならGi0/2 outです。矢印を構成図に描き、機器目線へ変換してからconfigを書きます。 その結果を該当するshow出力やpacket captureで確認します。期待値には、標準ACLは送信元だけを見るため一般に宛先寄りへ置く。

成果物には「rule順序・適用IF・NAT前後をレビュー」の結果と判断理由を残します。ACL本文だけでなく適用IF、方向、VRF、既存ACL置換、適用漏れを確認する。 これにより、担当者が変わっても同じ条件で再確認できます。

関連する仕組みをどの順序で確認する？

• ネットワークのポリシーテストとは？FW・ACLの試験手順
• Pingが通らない原因は？ネットワーク障害の切り分け手順

よくある疑問への答えは？

ACLのin/outは通信の向きではなく対象IFとルーターの関係で判断し、1個のACLは一方向の通信を評価します。反対方向も制御する場合は別途設計し、暗黙のdenyと既存通信への影響を試験します。

ACL in out 方向で最初に確認すべきことは？

最初は「送信元・宛先・protocol・port・方向を固定」です。ACLのin・outはルーターやL3スイッチのインターフェースを基準に、パケットが機器へ入る方向か、機器から出る方向かを示します。 対象と期待値を固定してからshow出力や実通信を取得します。

設定変更前に何を残すべきですか？

「ACLのin・out方向を判断する方法｜Cisco構成図とconfigで解説」の変更前証跡として、対象機器・インターフェース、現行config、関連テーブル、カウンター、ログ、構成図、直前変更を保存します。変更後も同じ対象と取得条件を使い、before／afterの差分を確認します。

Xポストの内容だけで実機に設定してもよいですか？

「ACLのin・out方向を判断する方法｜Cisco構成図とconfigで解説」の設定例を、そのまま本番へ投入してはいけません。対象製品の公式資料、OSバージョン、ライセンス、現行設定との差、検証結果を確認し、レビューと切り戻し手順をそろえてから変更します。

ACLのin・out方向を判断する方法を現場で確認するときの完了条件

ACLのin・out方向を判断する方法の確認は、コマンドが一度成功した時点では終わりません。対象と前提を固定し、正常時との差を観測し、復旧後に既存通信への影響まで確認します。

インフラエンジニアが案件で考えることは？

実案件ではACL本文が正しくても、別IFや逆方向へ適用すると通信要件を満たしません。変更レビューではACL名、適用IF、方向、VRF、既存ACLの有無、置換方式を一組で確認し、許可通信と拒否通信の両方を同じ送信元から試験します。

例えば、PCからサーバーへ向かう通信をGi0/1で受けるならGi0/1 in、Gi0/2から送るならGi0/2 outです。矢印を構成図に描き、機器目線へ変換してからconfigを書きます。 このとき「show ip interface GigabitEthernet0/1」と「ip access-list extended WEB-IN」を闇雲に取るのではなく、どの仮説を確認する出力かを手順書に書きます。対象と時刻がないlogは、後から正常・異常を判断できません。

レビューでは「送信元側は必ずinと固定化、製品ごとの処理差を無視」を禁止事項にするだけでなく、代わりに確認する資料とコマンドを決めます。ACL本文だけでなく適用IF、方向、VRF、既存ACL置換、適用漏れを確認する。 変更の一部が正常でも業務通信全体が成立するとは限らないため、層の異なる証跡を組み合わせます。

また、同じACLを4方向へ適用した場合の判定差を比較する。 この観点を設計書、config レビュー、試験仕様、作業手順の各成果物へ通して反映します。個人の経験に閉じず、第三者が同じ順序で再現できる状態にすることが、設計構築案件の品質につながります。

まとめ：ACLのin・out方向を判断する方法の要点

「ACL in out 方向」を理解するときは、定義だけでなく、構成のどこで処理され、何を観測すれば正否を判断できるかまで整理します。ACLのin・outはルーターやL3スイッチのインターフェースを基準に、パケットが機器へ入る方向か、機器から出る方向かを示します。

最後に押さえるのは「送信元・宛先・protocol・port・方向を固定」から「counter・session・log・server応答を照合」までを1本の手順にすることです。ACL本文だけでなく適用IF、方向、VRF、既存ACL置換、適用漏れを確認する。 これを構成図、config、show出力、試験結果で説明できれば、設計構築の実務でも再現できます。

この記事の執筆・監修者

けんと＠設計構築チャンネル

ネットワーク設計構築エンジニア／インフラ転職コンパス編集者

30歳未経験からネットワークエンジニアへ。金融系・オフィス系ネットワークの設計構築経験をもとに、工程・技術・求人選びを具体的に解説しています。

YouTube 設計構築チャンネル Xで現場発信を見る