PCから出ていく通信だからout、と思ってACLを付けると、向きを取り違えることがあります。ACLのin/outは、そのPCではなく、適用するルーターのインターフェースが基準です。
PCからルーターへ入り、ルーターからサーバーへ出る一本の通信でも、入口ではin、出口ではoutになります。図の矢印を追い、どのポートに対する向きかを一つずつ確認しましょう。
inはそのIFへ入る向き、outはそのIFから出る向き
PC、Gi0/1、ルーター、Gi0/2、サーバーという接続を考えます。PCからの要求はGi0/1でルーターへ入るのでin、Gi0/2から出るのでoutです。
サーバーの返信は逆になります。Gi0/2でin、Gi0/1でoutです。同じケーブルでも、要求と返信で向きが変わります。
| 同じPC→サーバー通信 | ルーターから見た向き | 設定例 |
|---|---|---|
| PC側Gi0/1で受信 | Gi0/1に入る | interface Gi0/1+ip access-group WEB-IN in |
| サーバー側Gi0/2から送信 | Gi0/2から出る | interface Gi0/2+ip access-group WEB-OUT out |
| 応答パケット | 反対方向に入って出る | 別の適用点・方向での評価を確認 |
- 制御したい通信の送信元・宛先を決める。
- パケットが通るL3インターフェースを列挙する。
- 各インターフェースで、機器へ入るか出るかを書き込む。
- 既存ACL、NATやFWの処理、戻り通信への影響を確認する。
作業のメモは「PC側だからin」ではなく、「PCからの要求をGi0/1で受信するのでin」と書くと、通信と適用点を結び付けられます。
構成図に要求と返信の矢印を別々に描く
先に送信元と宛先を決め、通る装置とインターフェースを図でたどります。各場所で、パケットがその装置へ入るか、装置から出るかを確認します。
下の図は接続関係と適用方向を示す構成図です。時間順のパケットのやり取りを示す図ではありません。要求の矢印を一本選び、両端の方向を比べてください。
10.0.0.10/24
──
Gi0/1:10.0.0.1/24
Gi0/2:172.28.31.1/24
──
172.28.31.10/24
TCP 443
要求 → PC → Gi0/1 の in → R1 → Gi0/2 の out → サーバー
返信 ← PC ← Gi0/1 の out ← R1 ← Gi0/2 の in ← サーバー
線は機器の接続、矢印は通信の方向です。IPは説明用のプライベートIP。狭い画面では図の中を横へスクロールできます。
- STEP 01送信元PC
- STEP 02Gi0/1 in
- STEP 03ACL判定と経路選択
- STEP 04Gi0/2 out・サーバー
L3スイッチでSVIへACLを付ける場合は、物理ポートだけを見ると誤解しやすくなります。どのVLANのL3インターフェースで評価するかを図へ書きます。
NATがある場合は、向きの確認に加え、その位置で見えるIPも必要です。方向が正しくても、変換前後のIPが合わなければ想定した行へ一致しません。
配置の原則は、止める範囲を考えるために使う
標準ACLは主に送信元IPを見るので、送信元近くで広く拒否すると、必要な別宛先への通信まで止める場合があります。そのため一般に宛先寄りへ置く、と学びます。
拡張ACLは送信元と宛先、プロトコルなどを選べるため、不要な通信を早く止める目的で送信元寄りへ置くことがあります。
ip access-list extended WEB-IN
permit tcp 10.0.0.0 0.0.0.255 host 172.28.31.10 eq 443
deny ip any any log
interface GigabitEthernet0/1
ip access-group WEB-IN in
show ip interface GigabitEthernet0/1
これは配置を考える原則で、すべての現場の正解位置を決めるものではありません。既存構成、管理する装置、処理能力、運用方針も合わせます。
どこへ置くかと、その場所でinかoutかは別の判断です。配置を決めたら、もう一度矢印を追って方向を確かめます。
ACLを定義し、対象IFへ適用したことを確認する
ip access-listでルールを作り、対象のインターフェースでip access-group WEB-IN inのように適用します。ACL本文が存在するだけでは、その場所で評価されません。
show ip interfaceのInbound access listとOutgoing access listで、実際の名前と方向を確認します。既存ACLがある場合は、置き換える影響もレビューします。
名前がWEB-INでも、設定としてoutへ付けることはできます。名前から推測するより、適用表示と設定を確認するほうが確実です。
show ip access-listsでは内容と順序、ヒット状況を読みます。試験前後を比べ、想定した通信がその場所へ来て、対象行へ一致したかを確認します。
逆方向・別IF・戻り通信の漏れを、試験で見つける
よくある見落としは、PCから見た方向で付けること、物理ポートとSVIを取り違えること、要求だけ許可して返信を考えないことです。
変更前にACL全文と適用点を保存し、変更後は通す通信と止める通信を同じ端末から試します。返信が別の経路を通る場合は、そこで評価するACLも確認します。
許可すべき通信が成功しても、広すぎるpermitで不要な通信まで通る場合があります。拒否試験と既存通信の再確認を一緒に行います。
カウンターは別の通信でも増えます。取得時刻と試験の条件を残し、どの増分を確認したか説明できるようにします。
「どのIFに対する向きか」を毎回添える
一本の要求は入口でin、出口でout。返信は逆です。ACLの方向は、この関係を適用インターフェースごとに判断します。
ACL名、対象IF、方向、通信条件を一組でメモすると、設定例を自分の構成へ読み替えやすくなります。
まず短いPC→ルーター→サーバーの図に、要求と返信のin/outを書いてみてください。端末の送受信と、ルーターのインターフェース方向を分ける練習になります。
動画・筆者の投稿で補足する
文章と図で流れをつかんだら、関連する動画も参考にしてください。画面の表示や操作は、機種・ソフトウェアの版によって異なる場合があります。
⭕️ネットワークエンジニアの
ACL設定で実務上かなり大事なことACLは
中身より先に
適用場所と方向を見るACLというと、
送信元IP
宛先IP
ポート番号
permit / denyに目が行きやすい。
でも実務でハマりやすいのは、
むしろそこよりどのインターフェースに
in / out のどちらで当てるか… pic.twitter.com/V5gePt5Sh8— けんと@設計構築チャンネル (@yeiquer12) 2026年5月3日
ACLは条件より先に、適用するインターフェースとin・out方向を見ることが重要だと説明したポスト。
関連する動画・筆者の投稿:2026年5月3日 / 筆者のX投稿 / @yeiquer12 / 設計構築チャンネル
