Ciscoルータであれ、Ciscoスイッチやその他のネットワーク機器であれ、標準的なACLアクセス制御リストは、通信の送信元アドレスと宛先アドレスの両方の特性を満たすことができず、今日のネットワーク世界の「粒度」制御の要件を満たしていません。サーバーにPingを打つことはできません。その後、標準のACLアプリケーションを置き換えるために拡張ACLを使用する必要があります、実際のアプリケーション制御では、標準のACLよりも拡張ACLは、管理者に人気があるようです。
デモの目的：拡張 ACL を設定して、ネットワークアプリケーションをより詳細に制御します。
デモ環境：次の図を使用して、ACL デモ環境に示す標準 ACL の構成部分をデモします。
デモの背景： ホストA（192.168.1.2）はサーバーAのWEBサービスにアクセスする必要がありますが、ホストAはサーバーAがあるサブネットを経由するpingを許可されていません。上記の制御要件を満たすために拡張ACLを使用し、ACLを適用する場所を考えてください。
デモンストレーションのステップ
***拡張 ACL は送信元アドレスと宛先アドレスの両方を一致させることができ、より通信元 に近い場所に適用できるため、ルータ R1 上で設定を完了することを推奨します。
R1(config)#access-list 101 permit tcp 192.168.1.0 0.0.255 host 192.168.5.2 eq www
* 許可 tcp 192.168.1.0.0.0.255host 192.168.5.2 eq www 送信元サブネット192.168.1.0がTCPポート80の宛先アドレス192.168.5.2へアクセスすることを許可するよう指示します。文中の*** IPサブネットと逆は、通信の送信元サブネットと対応する逆を示し、2番目のIPアドレス192.168.5.2は、hostによって特定のホストであると主張されていることに注意してください。
R1(config)#access-list 101 deny icmp 192.168.1.0 0.0.255 host 192.168.5.2
* 拡張ACLリスト101を定義する2番目のステートメントは、送信元サブネット192.168.1.0がICMPプロトコルを介して宛先ホスト192.168.5.2にアクセスすることを拒否します。
R1(config)#access-list 101 permit icmp 192.168.1.0 0.0.255 host 192.168.4.2
* 送信元サブネット192.168.1.0がICMPプロトコルを介して宛先ホスト192.168.4.2にアクセスすることを許可するように、拡張ACLリスト101の3番目のステートメントを定義します。
R1(config)#access-list 101 permit icmp 192.168.1.0 0.0.255 host 192.168.3.2
* 送信元サブネット192.168.1.0がICMPプロトコルを介して宛先ホスト192.168.3.2にアクセスすることを許可するように、拡張ACLリスト101の4番目のステートメントを定義します。
R1(config)#interface e1/0
R1(config-if)#ip access-group 101 in
R1(config-if)#exit
推奨：ACL 101 をルータ R1 の E1/0 インターフェースに適用します。これは、ソースサブネットに最も近い場所です。拡張 ACL はソースアドレスと宛先アドレスの両方にマッチするので、理論的には、制御基準さえ満たせば、トラフィックが通過するどのデバイスにも適用することができますが、ソースサブネットに最も近い場所に適用することを推奨します。最も近い場所で適用することを推奨するのは、最終的にフィルタリングされたトラフィックを宛先まで転送する必要がない、または中途半端にしかドロップしないため、貴重な帯域幅を利用する上で科学的ではないからです。
Step 2: 上記の設定が完了したら、ホストA(192.168.1.2)のサーバーAのWEBサービスにアクセスし、サーバーA、B、CにPingを打ちます。設定にエラーがなければ、下図のような状態になり、背景の説明の制御要件に沿った状態になります。
ステップ3： ルータR1のフィルタリング状況を確認するために、R1でshow ip access-listsコマンドを実行すると、以下の図10.13に示すように、WWWパケットが5つ許可され、サーバAへのICMPパケットが8つ拒否され、サーバBとCへのICMPパケットがそれぞれ4つ許可されていることがわかります。許可されていることがわかります。
#FormatImgID_2#
その他のACL損失の形態と適用上の注意点
このセクションでは、ACL の主な適用について、ACL の入力形式と出力形式、ACL の場所、および ACL エントリの追加と削除を含め、以下のように要約します：
ACLステートメントのlose-write形式について：
access-list 1permit host 192.168.100.1 は、access-list 1 permit 192.168.100.1 0.0.0.0の機能と等しくなります。IPアドレスがホストIPアドレスであることを示します。
access-list 102permit tcp 0.0.0.0 255.255.255.255 0.0.0.0255.255.255.255.255 eq www access-list 102 permit tcp any any eq 80 の機能に等しい。文中の送信元 IP アドレスと宛先 IP アドレスは 0 で、送信元 IP アドレスと宛先 IP アドレスはどの IP アドレスでもよいことを示し、送信元アドレスと宛先 アドレスの逆符号は 255 で、どのビットも気にしないことを示します。文中の送信元IPアドレスと宛先IPアドレスは0であり、送信元IPアドレスと宛先IPアドレスはどのIPアドレスでもよいことを示します。送信元アドレスと宛先アドレスの逆符号は255であり、どのビットも気にしないことを示します。これは、拡張ACLでanyキーワードとともに送信元IPアドレスと宛先IPアドレスが現れる場合と等価です。注意：もしWebサーバーのポートがよく知られているポート80を使用しない場合、いくつかのセキュリティ上の理由や特別な要件のために、サーバーの管理者は、Webのサービスポート番号をカスタマイズし、入力とACLの書き込みでは、唯一の特定のポート番号のアサーションの後にeqキーワードをすることができます、wwwを肯定しないように、そうでなければ、ACLは一致を完了することはできません。
アクセスリスト 102 permit ip host 192.168.1.2 host 192.168.2.2 は、アクセスリスト 102 permit ip 192.168.1.20.0.0.0 192.168.2.2 0.0.0.0 と同じです。は特定のホスト IP アドレスであるため、ACL ステートメントで host キーワードを使用すると、完全一致形式の逆と同じ意味を持つホストアドレスをアサートできます。
ACLの適用場所の設計について：
n 標準のACLはソースアドレスにしか注意を払わないので、制御対象に最も近いインターフェイス位置に適用されなければなりません。
n 拡張 ACL は送信元アドレスと宛先アドレスの両方を気にします。トラフィックを最適化し、バックボーン上の不要なトラフィックオーバーヘッドを削減するために、制御元に最も近いインターフェイス位置に適用することを推奨します。
n 同じインターフェイス、同じプロトコル、同じ方向には、1 つのアクセス制御リストしか適用できません。
n アクセス制御リストは、ルータを通過するトラフィックのみをフィルタリングできるため、アクセス制御リストが適用されているルータでローカルに生成されたトラフィックには効果がありません。
レガシーIOSリリースでのACLエントリの追加と削除について
従来のバージョンのIOSでは、ACLエントリを追加または削除するのは面倒です。なぜなら、ACLの複数のステートメントがルータに設定されている場合、ACLにフィルタステートメントを追加したい場合、この追加されたステートメントは、すでに存在するすべてのACLステートメントの後に表示されます。このことをよりよく理解するために、例を示します：
ユーザー***はACL 101を完了しました：
ACL 101 の *** 文： access-list 101 deny ip host 192.168.1.2 host192.168.2.1
ACL 101の2番目のステートメント： access-list 101 permit ip any any
今、ユーザーは元のACL 101を変更したいので、上記の2つのステートメントの間に以下のACLステートメントを追加したいと思います：
アクセスリスト 101 deny ip host192.168.3.1 host 192.168.4.1
しかし、あなたが結合を終了すると、この結合されたステートメントは、ACL 101の***に配置され、下図のように、同じ順序でマッチするように、***結合されたステートメントは、ACLリストの***に配置され、2番目のステートメントは、すべてのトラフィックを許可するので、3番目のステートメントにマッチする機会をまったく与えません。PERMIT ANY ANYで有効になることを望んでも、実際には有効になりません。マイクロコンピュータのスタック原理に似ています。
通常、管理者は現在の ACL をテキストファイルにコピーしてステートメントを追加または削除し、no access-list 101 を使用してルータに元々設定されている ACL をすべてクリアしてから、テキストファイル内の変更された ACL をルータにコピーします。これは、ACLステートメントを1つずつ変更する効果では不可能です。
ACL エントリを追加および削除するには、ACL の拡張編集機能を使用します。
新しいIOSは、従来のIOSのACLエントリ変更制限を破り、次の図のように、各ACL文にシーケンス番号を追加します。例えば、*** ACL文のシーケンス番号は10、2番目のACL文のシーケンス番号は20で、*** ACLの入力と書き込みの基本数値シーケンス番号は10で、新しいACL文の入力と書き込みは10ずつ増加します。シーケンス番号10と20の間にACL文を追加する必要がある場合は、10と20の間に該当するシーケンス番号を追加するだけで、新しいACL文は10と20の間に存在することになります。
例えば、次のコンフィグレーションのように、シーケンス番号が 15 の ACL ステートメントを 10 と 20 の間に追加します。 コンフィグレーションのステートメント中の 15 は、これから挿入する ACL ステートメントを示すシーケンス番号です。 コンフィグレーションの完了後、ルータで show ip access-lists を使用すると、次の図 10.16 に示すように、各 ACL のステートメントを表示できます。シーケンス番号 10 と 20 の間にシーケンス番号 15 の ACL ステートメントが表示され、従来の IOS での ACL 編集の難しさを打破し、ACL の編集機能が強化されています。
2つのACLステートメントの間に、シーケンス番号15のコンフィグレーションを挿入します：
R1(config)#ip access-list extended 101
R1(config-nacl)#15 deny ip host 192.168.3.1 host192.168.4.1
#FormatImgID_5#
IOSの多くのバージョンがあり、それを使用するとき、どのように、どのIOSのバージョンは、ACLの拡張編集機能をサポートし、どのIOSのバージョンは、ACLの拡張編集機能をサポートしていない知っていますか？それは非常に簡単です、ユーザーはIOSのバージョン番号を覚えておく必要はありません、それは本当に覚えておくのは難しいことですので、あなたは直接表示結果で、各ACL文の前にシーケンス番号がある場合は、ACLリストを表示するには、show ip access-listsを介してすることができますデバイスは、ACLの拡張編集機能をサポートしており、その逆はできません。
Q: なぜIOSシステムは、10を基本番号としてACLステートメントにシーケンス番号を自動的に挿入するのですか?
実際には、これはまた、シーケンス番号のベースが10に設定されたときに生成された*** ACLステートメントについては、編集ACLの便宜のために、元の*** ACLステートメントを与え、スペースを確保するためにACLを挿入することです、少なくともユーザはまた、同じことの増分番号として10に1〜9 ACLステートメント、後続のACLを挿入することができます、もちろん、ユーザは、ベース番号と後続のACLによって生成されたインクリメントの数の*** ACL自動挿入を変更するには、独自のニーズに応じてすることができますが、私はデフォルトの設定を維持することをお勧めします。もちろん、ユーザは自分のニーズに応じて、ベース番号と後続のACLの増分数を変更することができますが、私はデフォルトの設定を維持することをお勧めします。
