トップ > 助け合いフォーラム >CCNA/CCNP関連 >最強WEB問題集CCNP SWITCH >問題ID： 4685

Re: 問題ID： 4685

この質問の投稿一覧へ

なし Re: 問題ID： 4685

msg# 1.10.1
depth:
2
前の投稿 - 次の投稿 | 親投稿 - 子投稿なし | 投稿日時 2014-7-12 9:28 | 最終変更
arashi1977  長老 居住地: 広島  投稿数: 1715
どうやら私は根本的に誤解していたようです。
私はumaiumaiさんがこの問題に対して
引用：
正解が4ではない理由は何でしょうか？
と質問されていたと思い、「4(RACL)より7(VACL)のほうが適切ですよ、それはこういう面からです」と、答えていたつもりでした。
ですが
引用：
本来聞きたい質問を答えていただけてないのですが。
とのことなので、上記の考えが完全に違っていたのですね。

ここで言う質問とは「問題文のどこからVLAN11以外をフィルタリングしてはいけないと読み取れるのでしょうか？」のことでよろしいでしょうか？

umaiumaiさんもご認識の通り
引用：
あくまで問題文から客観的に読み取れるものです
と、問題文から客観的に（仮定、推測は含まない）という点を元にお話しないといけなかったのですね。

引用：
また具体的な設定を記載いただいているのですが、その前に情報をいただけないと何を仰られているかわかりません。
とのことですが、これはまさに「問題文から客観的に読み」とって作成したものです。

問題文にあるのは以下のとおりです（フィルタリングに関する部分のみ）
引用：
以下の条件でVLAN11に属するPCがサーバーへアクセスするのを制限するためにどうすれば良いか
・VLAN11では送信元が172.18.1.0/24のみ許可する（フィルタリングは出来る限りサーバーファームに近い位置で行うこと）
「VLAN11では172.18.1.0/24を許可する」以外に許可すべき対象、拒否すべき対象に関して何も情報はありません。

ではそれを踏まえてコンフィグ例を、ということで出したのが前述の例です。再掲しますが
VACL:
ip access-list extended FOR_PERMIT_FROM_VLAN11_TO_SERVERFIRM
 permit ip 172.18.1.0 0.0.0.255 (dest:サーバファーム)
!
ip access-list extended FOR_DENY_FROM_VLAN11_TO_SERVERFIRM
 permit ip any (dest:サーバファーム)
!
vlan access-map VACL_VLAN11 10
 match ip address FOR_PERMIT_FROM_VLAN11_TO_SERVERFIRM
 action forward
!
vlan access-map VACL_VLAN11 20
 match ip address FOR_DENY_FROM_VLAN11_TO_SERVERFIRM
 action drop
!
vlan access-map VACL_VLAN11 30
 action forward
!
vlan filter VACL_VLAN11 vlan 11

RACL:
interface FastEthernet0/1
 ip access-group RACL out
!
ip access-list standard RACL
 permit 172.18.1.0 0.0.0.255
「上記RACL定義のアクセスリストにその他のセグメントのpermit定義がないから間違いだ」と言われたとしても、問題文から客観的に読み取れる情報からではこれしか書きようがありません。
その他の許可すべきセグメントの情報がありませんので…

そうすると、暗黙のdenyによって問題文に明示的に記載されていないVLAN12,13からのトラフィックはSwitchA Fa0/1のout方向のフィルタ（RACL定義）によって破棄されます。
これではVLAN11からのアクセスのみならずVLAN12,13に対するdenyフィルタが発動してしまい、設問にないVLAN12,13へのdeny/permitを考慮しないといけなくなるため誤りになると思うのですが、いかがでしょうか。

引用：
「VLAN11に属するPCがサーバーへアクセスするのを制限するため」
という上記の大前提があります。
を満たしていても、問題文にない「VLAN12,13からサーバファームへのアクセスをフィルタ」といったことをしてしまうのでは「要件の拡大解釈」とならないでしょうか。

一応その他の点についてもですが
引用：
実際に構築する案件なら分かるのですが、試験問題のように結果が決まっているものに対して提案なんてできるものではありません
おっしゃるとおりで、結果も提示されている情報も決まっているのに「VLAN12,13のセグメントのpermitを入れれば正しく動く」と言われても「そのpermit行を書くにあたっての情報はどこにあるの？ないのにどうやって書けるの？」というのが、解説にある「VLAN11以外についてもフィルタリングしてしまうことになるので 誤りです。」になると理解しています。

引用：
具体的な設定を記載いただいているのですが、その前に情報をいただけないと何を仰られているかわかりません。
再掲しますが
引用：
VLAN11に入ってくるトラフィックで
・172.18.1.0/24からサーバファームへは許可 ←問題の「VLAN11では送信元が172.18.1.0/24のみ許可する」に相当
・それ以外からサーバファームへは破棄 ←問題の「VLAN11に属するPCがサーバーへアクセスするのを制限」に相当。許可していないとこからのサーバファームアクセス拒否
・そのほかの通信は許可 ←問題に記載がないので、その他の通信を誤って破棄しない
という設定
です。

引用：
RACLの方がテストが大変とはどういう場合を想定しているのですか？
問題文にない話題なので混乱のもとになるかもしれませんが、例えばですが、
permit 10.3.1.0 0.0.0.255
が元々あって、新たに10.3.2.0/24および10.3.3.0/24が追加されたときに
permit 10.3.0.0 0.0.3.255
と誤って設定した場合を想定して、「10.3.0.0/24が通信可能となっていないこと」といったテスト項目が盛り込まれることが想定されます。
上述のとおり、暗黙のdenyで拒否されていたはずのものが勝手にpermitされてしまうのでは目的を達したとは言えませんよね。それを許容するならそもそもpermit anyしてしまえばいいってことになりかねないので。

また、SwitchA Fa0/1のout方向に適用されているアクセスリストなので、VLAN11,12,13全てが関連していることからテスト対象を絞ることができません。

別の観点から言えば（これも問題文にないのであくまで例示、ですが）、別の意図で元々設定していたSwitchA Fa0/1へのout方向のアクセスフィルタがあった場合、そちらと統合する必要性が出てくることから、適用するACLの修正時には本件のアクセスリスト以外の目的が毀損されていないことの確認が必須となります。
その場合は当然追加（修正）が1行であっても全部テストする必要があります。

VACLの場合であれば、修正したアクセスリストが影響するのがVLANアクセスマップのみであること、ひいてはそのマップを適用したVLANのみしか影響しないことがわかっているので、テスト対象はVLAN11に絞ることができます。

そういった点から「VACLよりもRACLのテストのほうが大変」と想定しています。

投稿ツリー

  >フォーラム検索へ

Copyright (c) 2020 Ping-t All rights reserved.