#19「本番でやってたら大変なことになってたね」—Cisco ルーターの ACL 設定でハマった私が、二度と繰り返さないために整理した話
対象読者: 実務層（ネットワークエンジニア2年目～)
※目指せ。有料記事です！
はじめに：検証環境でハマって、自分の理解の甘さを知った日
「なんで通信が止まるんだろう……」
先輩から「本番適用の前に検証環境で一通り試しておいて」と言われ、Cisco ルーターに ACL を設定していたときのことです。設定自体はシンプルで、特定のポートへのアクセスを遮断するだけ。30分もあれば終わると思っていました。
ところが ACL を適用した瞬間、検証端末からルーターへの SSH が切れました。焦って設定を見直しても、どこが問題なのかわからない。結局、先輩に「ACL の方向、逆じゃない？」と指摘されて気づきました。`in` と `out` を逆に設定していたんです。
「これ、本番でやってたら大変なことになってたね」
先輩の一言が刺さりました。検証環境だったから笑い話で済みましたが、同じことを本番でやれば全社の通信を止めていたかもしれない。それからACLの適用方向について、ちゃんと理解し直しました。
この記事は、あの検証環境での失敗から私が学んだ「ACL 設定で詰まらないための実務知識」をまとめたものです。
1. Cisco の ACL とは何か――「何を止めるか」より先に「どこで止めるか」
ACL（Access Control List：アクセスコントロールリスト）は、Cisco ルーターやスイッチで特定のトラフィックを許可・拒否するためのフィルタリング機能です。
ACL 自体は `ip access-list` コマンドで定義しますが、定義しただけでは動作しません。 インターフェースに適用して初めて効力を持ちます。
そしてここが最初の落とし穴です。インターフェースへの適用には 方向 があります。
interface GigabitEthernet0/0
ip access-group 100 in ← このインターフェースに「入ってくる」パケットに適用
ip access-group 101 out ← このインターフェースから「出ていく」パケットに適用出典: Cisco「Configuring IP Access Lists」（Cisco IOS Security Configuration Guide）
この方向の概念は「ルーターの CPU 視点」で考えると直感的です。CPU に向かって入ってくるパケットが `in`、CPU から出ていくパケットが `out` です。端末から見た「送信」「受信」と逆になるため、ここで混乱するエンジニアは非常に多いです。
外部から内部へのパケットは、外部側インターフェースの `in` 方向を通ります。ここを間違えると、意図したフィルタが全く機能しないか、逆に通すべきトラフィックを全部落とすかのどちらかになります。
2. やらかしポイント：`in` と `out` の方向を間違えるとどうなるか
私がやったミスは、要件書にあった「外部からの特定ポートへのアクセスを遮断する」という設定で、外部側インターフェースに `out` で適用してしまったことです。
外部から内部へのトラフィックは外部インターフェースの `in` 方向を通ります。`out` に適用した ACL はそれには一切効かず、代わりに内部から外部へ出ていくトラフィックに ACL が当たりました。
暗黙の `deny any` が発動して内部からの通信がすべてブロックされました。
! 実際に設定したACL（末尾の permit ip any any を書き忘れていた）
ip access-list extended BLOCK_EXTERNAL
deny tcp any any eq 23
← ここに permit ip any any が必要だったが抜けていた
interface GigabitEthernet0/0
ip access-group BLOCK_EXTERNAL out ← in であるべきだった2つのミスが重なっていました。
1つ目は `permit ip any any` の書き忘れ。Cisco ACL には末尾に暗黙の `deny any` があるため、明示的な permit を書かないと deny 対象以外のすべてのトラフィックも落ちます。
2つ目は 適用方向の逆。`out` に適用したことで、遮断したかった外部からの Telnet（23番）は何も止まらず、代わりに内部から外部への全トラフィックが暗黙の `deny any` に当たりました。
SSH が切れた理由も同じ構造です。`out` に ACL が当たったことで、ルーターが端末へ返そうとする SSH の応答パケット（Reply） が暗黙の `deny any` に引っかかり、TCP セッションが維持できなくなったんです。ACL の方向を間違えると「行き」だけでなく「戻り」も止まる——この TCP の往復を意識していなかったことが根本原因でした。
3. 番号付き ACL vs 名前付き ACL――現場での使い分け基準
Cisco ACL には「番号付き ACL」と「名前付き ACL」の2種類があります。現場ではどちらを使うべきか、判断基準を整理します。
番号付き ACL（Numbered ACL）
番号の範囲でタイプが決まります。
標準 ACL は送信元 IP アドレスのみを条件にします。ポート番号の指定はできません。
! 標準 ACL の例（送信元 IP のみ）
access-list 1 deny 192.168.1.0 0.0.0.255
access-list 1 permit any
! 拡張 ACL の例（プロトコル・ポートまで指定可能）
access-list 100 deny tcp any any eq 23
access-list 100 permit ip any any出典: Cisco「IP Access List Entry Sequence Numbering」（Cisco IOS Security Configuration Guide）
番号付き ACL の編集：かつては途中の行を変えるには全削除して再投入が必要でした。現在の主流である IOS 15.x 系では、`ip access-list extended 100` と打つと名前付き ACL と同様の編集モードに入り、シーケンス番号を指定して行の挿入・削除が可能です。ただし、番号だけでは意図が伝わらないため、可読性の観点から現場では名前付きが推奨です。
名前付き ACL（Named ACL）
ip access-list extended BLOCK_TELNET
10 deny tcp any any eq 23
20 permit ip any any現場での推奨は名前付き ACL です。 理由は3つあります。
名前で目的が伝わる：`100` より `BLOCK_TELNET_FROM_OUTSIDE` の方が引き継ぎ時に意図が明確
シーケンス番号で途中挿入ができる：`15 deny tcp any host 192.168.1.1 eq 22` のように後から追加できる
削除が行単位でできる：`no 10` で特定の行だけ消せる
標準 ACL vs 拡張 ACL の配置ルール
この配置ルールを知らないと、標準 ACL を送信元の近くに置いてしまい、意図しない通信まで止めてしまうことがあります。
4. ACL を安全に適用するための作業手順
`reload in X` による保険の掛け方
リモート作業で ACL を誤適用して SSH 接続が切れると、コンソールケーブルを持参してオンサイト対応が必要になります。これを防ぐのが `reload in` コマンドです。
Router# reload in 10
Reload scheduled in 10 minutes by console
Proceed with reload? [confirm]10分後に自動再起動し、startup-config（保存済み設定）が読み込まれます。running-config に加えたミス設定は消えて元の状態に戻ります。
`reload in` 実行前の落とし穴：`reload in` をセットする前に、必ず `show running-config` と `show startup-config` を見比べて、前任者が保存し忘れた設定が startup-config に残っていないか確認してください。再起動した瞬間に ACL 以外の場所で別の障害が起きるリスクを排除するためです。「reload で元に戻るはずが、元の startup が壊れていた」という二次障害を防ぐための一手間です。
安全な作業手順（このフローで動いてください）:
Step 1: show running-config をテキストに保存（作業前のスナップショット）
Step 2: reload in 10 を実行（保険をセット）
Step 3: ACL を定義（まだインターフェースには適用しない）
Step 4: show ip access-lists で ACL 内容を目視確認
Step 5: 適用方向を図で確認してからインターフェースに適用
Step 6: 別端末から ping・SSH・業務アプリの疎通を即確認
Step 7: 問題なければ reload cancel → copy running-config startup-config
Step 8: 問題あれば no ip access-group で即取り外し、または reload を待つ`copy running-config startup-config` を忘れない：これを忘れると再起動後に設定が消えます。`write memory`（ショートカット：`wr`）でも同じ動作です。現場では `wr` の方が速いため、確認後は即 `wr` を打つ習慣をつけることを推奨します。
出典: Cisco「reload」コマンドリファレンス（Cisco IOS コマンドリファレンス）
5. 本番作業前に必ず確認する `show` コマンド完全版
作業前（現状把握）
# インターフェースの状態と適用中 ACL を確認
show ip interface GigabitEthernet0/0
# → "Inbound access list is XXX" / "Outbound access list is not set" で方向確認
# 現在定義されている全 ACL とヒットカウントを確認
show ip access-lists
# ルーティングテーブルの確認（意図しないルートがないか）
show ip route
# 保存済み設定との差分確認（archive 機能が有効な場合のみ使用可能）
show archive config differences
# archive 未設定の場合は show startup-config で手動比較する適用直後（疎通確認）
# ACL のヒット数が増えているか確認（deny がヒットしていないか）
show ip access-lists BLOCK_TELNET
# インターフェースに正しい方向で適用されているか確認
show ip interface GigabitEthernet0/0 | include access list
# パケットカウンタのリセット（作業後の確認のためにゼロにする）
clear ip access-list counters BLOCK_TELNET`log` キーワードの活用
ACL エントリに `log` を付けると、マッチしたパケットの情報が syslog に記録されます。問題診断に非常に有効です。
ip access-list extended BLOCK_TELNET
10 deny tcp any any eq 23 log
20 permit ip any anyただし `log` はルーターの CPU 負荷を上げるため、本番の常時適用には向きません。診断目的での一時的な使用に限定することを推奨します。
6. よくある ACL ミス6パターンと診断フロー
現場でよく遭遇するミスと、確認コマンドをセットで整理します。
診断フロー
通信が止まった
│
├─ ACL がインターフェースに適用されているか？
│ show ip interface [if] | include access
│ └─ No → ip access-group で適用
│ └─ Yes ↓
│
├─ ACL のヒットカウントが増えているか？
│ show ip access-lists
│ └─ deny 行のカウントが増加 → フィルタが当たっている
│ └─ カウントが増えない → 方向が逆か、ACL が空
│
├─ 適用方向は正しいか？
│ show ip interface [if]
│ └─ Inbound / Outbound の表示を確認
│
└─ permit any が末尾にあるか？
show ip access-lists
└─ なければ追加。あれば ACL の外の問題7. 企業環境で使える ACL 設計テンプレート3選
テンプレート1：インターネット接続ルーターの基本フィルタ（外部インターフェース `in`）
ip access-list extended INBOUND_FILTER
! RFC 6890 のスプーフィングアドレスを遮断
10 deny ip 10.0.0.0 0.255.255.255 any log
20 deny ip 172.16.0.0 0.15.255.255 any log
30 deny ip 192.168.0.0 0.0.255.255 any log
40 deny ip 127.0.0.0 0.255.255.255 any log
! Telnet / rsh / rlogin を遮断
50 deny tcp any any eq 23 log
60 deny tcp any any eq 513 log
70 deny tcp any any eq 514 log
! それ以外は許可
80 permit ip any any
interface GigabitEthernet0/0
description TO_INTERNET
ip access-group INBOUND_FILTER inテンプレート2：内部セグメント間のアクセス制御（VLAN 間ルーティング）
! 開発VLAN(192.168.10.0/24)から本番VLAN(192.168.20.0/24)へのアクセスを制限
ip access-list extended DEV_TO_PROD
! 必要な管理ポートのみ許可
10 permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 22
20 permit tcp 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 eq 443
! それ以外の本番向けアクセスを遮断
30 deny ip 192.168.10.0 0.0.0.255 192.168.20.0 0.0.0.255 log
! 他の通信は許可
40 permit ip any any
interface GigabitEthernet0/1.10
description DEV_VLAN
ip access-group DEV_TO_PROD inテンプレート3：管理アクセス（SSH）を特定 IP のみに制限
! 踏み台サーバー(192.168.100.10)からのSSHのみ許可
ip access-list extended MGMT_ACCESS
10 permit tcp host 192.168.100.10 any eq 22
20 deny tcp any any eq 22 log
30 permit ip any any
! vty 回線に適用（インターフェースではなく line vty に当てる）
line vty 0 4
access-class MGMT_ACCESS in
transport input ssh注意①：vty への ACL 適用は `ip access-group` ではなく `access-class` コマンドを使います。ここは間違えやすいポイントです。
注意②：古い IOS バージョンやプラットフォームでは、`access-class` に使える ACL が標準 ACL（1〜99）のみの場合があります。環境によっては拡張 ACL が受け付けられないため、確実性を求める場合は標準 ACL で代替してください。
出典: Cisco「Controlling Access to a Router」（Cisco IOS Security Configuration Guide）
8. まとめ：再発ゼロのための作業前後チェックリスト
今回の失敗から得た3つの教訓です。
ACL の in/out は「ルーター視点」で考える。インターフェースに入ってくる方向が `in`、出ていく方向が `out`。外部からの制御は外部側インターフェースの `in` に適用する。
`reload in 10` を保険として使う。リモート作業でアクセス不能になる最悪シナリオを防ぐ、シンプルかつ強力な手法。
名前付き拡張 ACL ＋ シーケンス番号を標準にする。番号付き ACL より保守性が高く、途中挿入・削除が安全にできる。
作業前後チェックリスト（コピーしてご利用ください）
【作業前】
□ show running-config をテキストに保存した（スナップショット）
□ show ip access-lists で既存の ACL 状況を把握した
□ show ip interface [if] で現在の ACL 適用状態を確認した
□ reload in 10 を実行した（保険をセット）
□ 名前付き拡張 ACL で定義した（番号付きは使わない）
□ ACL 末尾に permit ip any any を記載した
□ 適用方向（in/out）をインターフェース図で確認した
【適用直後】
□ show ip access-lists でヒットカウントが正常か確認した
□ 別端末から ping・SSH・業務アプリの疎通を確認した
□ deny 行に意図しないヒットが出ていないか確認した
【作業完了時】
□ reload cancel を実行した（保険を解除）
□ write memory（wr）で設定を保存した
□ show archive config differences（または show startup-config との手動比較）で差分が意図どおりか確認した
□ 作業記録（変更内容・確認結果）をチケットに記録したあの検証環境での失敗は今でも忘れられません。でもあれがなければ、私はきっと本番で同じミスをやらかしていたと思います。
最後に（宣伝です！）
ちょっとだけ宣伝です：一緒に働く仲間を探しています！
この記事を書いているアクシスNWチーム広報部をはじめ、当社では現在、新しいメンバーを積極的に採用しています。 最先端のAIをパートナーに、ワクワクするような挑戦ができる環境が整っています。まずはカジュアルにお話ししませんか？ 新卒の方も、キャリア採用の方も、ぜひお気軽にチェックしてください！
⇒株式会社アクシス人事採用担当(note)
⇒株式会社アクシス求人情報(私の仲間の取材がいっぱいあります)
⇒株式会社アクシス中途採用サイト
⇒株式会社アクシスホームページ
#アクシス #アクシスNWチーム広報部
#ゼロトラスト #サイバーセキュリティ #ネットワーク
#すきしてみて
コメント