拡張ACLはL3・L4をどう見る？IP・プロトコル・ポートの設定例

拡張ACLは、L3の送信元・宛先IPとプロトコルに加え、TCP/UDPではL4のポート番号まで条件にできます。ICMPにTCP/UDPポートを指定することはできず、プロトコルごとに読み取るフィールドが異なります。

本文では通信要件を送信元、宛先、プロトコル、宛先ポートへ分解し、host・any・ワイルドカード、eq・range、名前付きACLの設定例と試験方法を示します。

(出典：筆者のX投稿（X：拡張ACLはL3のIPとL4のTCP・UDP・ポート番号を理解して設定すると整理したポスト。）)

拡張ACLとは？

構成図ではsource/destination IPの入力点と出力点を示し、ip access-list extended APP-ACLで実装状態を確かめます。関連する観点として、通信要件表は送信元、宛先、プロトコル、ポート、方向、NAT前後、期待結果で管理する。 ここまで追うと、用語とpacketの動きがつながります。

成果物には「送信元・宛先・protocol・port・方向を固定」の結果と判断理由を残します。通信要件表は送信元、宛先、プロトコル、ポート、方向、NAT前後、期待結果で管理する。 これにより、担当者が変わっても同じ条件で再確認できます。

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

標準ACLとは何が違う？

「標準ACLとの違い」は、対象layer、判定field、処理する機器、保持する状態、確認コマンドの5軸で比べます。拡張ACLはL3の送信元・宛先IPとIPプロトコル、L4のTCP・UDPポートなどを組み合わせ、通信を細かく識別するCisco IOSのフィルタリング機能です。

個別に暗記するのではなく、1本のpacket flowへ並べるのが実践的です。前段の確認は、標準ACLは主に送信元IPで判定するため、不要な通信まで巻き込まない配置を検討します。 後段では、通信要件表は送信元、宛先、プロトコル、ポート、方向、NAT前後、期待結果で管理する。

設計レビューではprotocolがどの軸に属するかを表にし、「establishedをステートフルFWと同一視」という混同を防ぎます。差分をip access-list extended APP-ACLで説明できれば、configの読み違いを減らせます。

L3で見るIPとは？

そこでportを観測点にし、「ACLがL3/L4すべてを完全制御すると表現」という判断を避けます。別装置のlogやcaptureでは、ICMPはポートを持たずtypeで条件を細分化できる。 複数の観測点を使うと、片側だけを見た誤判定を防げます。

成果物には「rule順序・適用IF・NAT前後をレビュー」の結果と判断理由を残します。通信要件表は送信元、宛先、プロトコル、ポート、方向、NAT前後、期待結果で管理する。 これにより、担当者が変わっても同じ条件で再確認できます。

L4で見るTCP・UDP・ポートとは？

構成図ではwildcard maskの入力点と出力点を示し、permit udp host 10.10.10.53 host 192.0.2.53 eq domainで実装状態を確かめます。関連する観点として、名前付きACLは用途が分かる命名と行単位の管理がしやすい。 ここまで追うと、用語とpacketの動きがつながります。

成果物には「許可・拒否・戻り通信を実行」の結果と判断理由を残します。通信要件表は送信元、宛先、プロトコル、ポート、方向、NAT前後、期待結果で管理する。 これにより、担当者が変わっても同じ条件で再確認できます。

ip access-list extended APP-ACL
 permit tcp 10.10.0.0 0.0.255.255 host 192.0.2.10 eq 443
 permit udp host 10.10.10.53 host 192.0.2.53 eq domain
 permit icmp 10.10.0.0 0.0.255.255 host 192.0.2.10 echo
 deny ip any any log

ICMP指定とは？

実務の開始点は「counter・session・log・server応答を照合」です。通信要件の『10.10.0.0/16から192.0.2.10のHTTPSを許可』を、送信元、宛先、TCP、443、方向へ分解して一行のACLへ変換します。 その結果をpermit icmp 10.10.0.0 0.0.255.255 host 192.0.2.10 echoで確認します。期待値には、IPアドレスはhost、any、ワイルドカードマスクで指定できる。

成果物には「counter・session・log・server応答を照合」の結果と判断理由を残します。通信要件表は送信元、宛先、プロトコル、ポート、方向、NAT前後、期待結果で管理する。 これにより、担当者が変わっても同じ条件で再確認できます。

host・any・ワイルドカードとは？

そこでUDPを観測点にし、「establishedをステートフルFWと同一視」という判断を避けます。別装置のlogやcaptureでは、TCPとUDPでは同じポート番号でも別の通信として扱う。 複数の観測点を使うと、片側だけを見た誤判定を防げます。

eq・rangeとは？

構成図ではICMPの入力点と出力点を示し、該当するshow出力やpacket captureで実装状態を確かめます。関連する観点として、eqは単一ポート、rangeは範囲を指定する。 ここまで追うと、用語とpacketの動きがつながります。

成果物には「通信要件と既存policyを保存」の結果と判断理由を残します。通信要件表は送信元、宛先、プロトコル、ポート、方向、NAT前後、期待結果で管理する。 これにより、担当者が変わっても同じ条件で再確認できます。

名前付きACL設定とは？

「名前付きACL設定」では、要件をいきなりconfigへ置き換えず、対象、方向、入力値、期待出力を中間表にします。設計上の要点は次のとおりです。名前付きACLは用途が分かる命名と行単位の管理がしやすい。

投入前に「rule順序・適用IF・NAT前後をレビュー」を行い、source/destination IPと既存設定の干渉をレビューします。例として通信要件の『10.10.0.0/16から192.0.2.10のHTTPSを許可』を、送信元、宛先、TCP、443、方向へ分解して一行のACLへ変換します。 この条件を手順書と試験表にも引き継ぎます。

投入後はip access-list extended APP-ACLだけで完了にせず、実通信、counter、logのいずれかで裏付けます。ICMPはポートを持たずtypeで条件を細分化できる。 戻せるconfig差分と中止条件も同時に用意します。

通信要件からACLへ変換とは？

「通信要件からACLへ変換」では、要件をいきなりconfigへ置き換えず、対象、方向、入力値、期待出力を中間表にします。設計上の要点は次のとおりです。名前付きACLは用途が分かる命名と行単位の管理がしやすい。

投入前に「許可・拒否・戻り通信を実行」を行い、protocolと既存設定の干渉をレビューします。例として通信要件の『10.10.0.0/16から192.0.2.10のHTTPSを許可』を、送信元、宛先、TCP、443、方向へ分解して一行のACLへ変換します。 この条件を手順書と試験表にも引き継ぎます。

投入後はip access-list extended APP-ACLだけで完了にせず、実通信、counter、logのいずれかで裏付けます。名前付きACLは用途が分かる命名と行単位の管理がしやすい。 戻せるconfig差分と中止条件も同時に用意します。

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

• ポート番号とは？TCP・UDPとの関係と代表的な番号一覧
• ネットワークのポリシーテストとは？FW・ACLの試験手順

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

拡張ACLは上から順に評価され、最初に一致したACEで許可または拒否が決まります。合致する行がなければ暗黙にdenyされるため、広いpermitを先に置く、必要な制御通信を漏らす、TCP/UDPとICMPを混同するミスに注意します。

拡張ACL L3 L4で最初に確認すべきことは？

最初は「送信元・宛先・protocol・port・方向を固定」です。拡張ACLはL3の送信元・宛先IPとIPプロトコル、L4のTCP・UDPポートなどを組み合わせ、通信を細かく識別するCisco IOSのフィルタリング機能です。 対象と期待値を固定してからshow出力や実通信を取得します。

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

「拡張ACLはL3・L4をどう見る？IP・プロトコル・ポートの設定例」の変更前証跡として、対象機器・インターフェース、現行config、関連テーブル、カウンター、ログ、構成図、直前変更を保存します。変更後も同じ対象と取得条件を使い、before／afterの差分を確認します。

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

「拡張ACLはL3・L4をどう見る？IP・プロトコル・ポートの設定例」の設定例を、そのまま本番へ投入してはいけません。対象製品の公式資料、OSバージョン、ライセンス、現行設定との差、検証結果を確認し、レビューと切り戻し手順をそろえてから変更します。

拡張ACLはL3・L4をどう見るを現場で確認するときの完了条件

拡張ACLはL3・L4をどう見るの確認は、コマンドが一度成功した時点では終わりません。対象と前提を固定し、正常時との差を観測し、復旧後に既存通信への影響まで確認します。

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

実案件ではExcelの通信要件表をそのままconfigへ写さず、NAT前後、戻り通信、stateful/stateless、適用位置を補います。レビューでは要件表の一行とACL sequenceをひも付け、不要なany、ワイルドカードの桁、TCP/UDPの取り違えを機械的に確認します。

例えば、通信要件の『10.10.0.0/16から192.0.2.10のHTTPSを許可』を、送信元、宛先、TCP、443、方向へ分解して一行のACLへ変換します。 このとき「ip access-list extended APP-ACL」と「permit tcp 10.10.0.0 0.0.255.255 host 192.0.2.10 eq 443」を闇雲に取るのではなく、どの仮説を確認する出力かを手順書に書きます。対象と時刻がないlogは、後から正常・異常を判断できません。

レビューでは「ACLがL3/L4すべてを完全制御すると表現、establishedをステートフルFWと同一視」を禁止事項にするだけでなく、代わりに確認する資料とコマンドを決めます。通信要件表は送信元、宛先、プロトコル、ポート、方向、NAT前後、期待結果で管理する。 変更の一部が正常でも業務通信全体が成立するとは限らないため、層の異なる証跡を組み合わせます。

また、通信要件表1行をCisco拡張ACLへ変換する例を掲載する。 この観点を設計書、config レビュー、試験仕様、作業手順の各成果物へ通して反映します。個人の経験に閉じず、第三者が同じ順序で再現できる状態にすることが、設計構築案件の品質につながります。

まとめ：拡張ACLはL3・L4をどう見るの要点

「拡張ACL L3 L4」を理解するときは、定義だけでなく、構成のどこで処理され、何を観測すれば正否を判断できるかまで整理します。拡張ACLはL3の送信元・宛先IPとIPプロトコル、L4のTCP・UDPポートなどを組み合わせ、通信を細かく識別するCisco IOSのフィルタリング機能です。

最後に押さえるのは「送信元・宛先・protocol・port・方向を固定」から「counter・session・log・server応答を照合」までを1本の手順にすることです。通信要件表は送信元、宛先、プロトコル、ポート、方向、NAT前後、期待結果で管理する。 これを構成図、config、show出力、試験結果で説明できれば、設計構築の実務でも再現できます。

この記事の執筆・監修者

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

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

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

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