|
サイズ: 3094
コメント:
|
サイズ: 3292
コメント:
|
| 削除された箇所はこのように表示されます。 | 追加された箇所はこのように表示されます。 |
| 行 22: | 行 22: |
| 1. !ＩＰｖ４アドレス → match は「no match」 1. !ＩＰｖ６アドレス → match は「no match」 1. any → match は「match」 |
1. !ＩＰｖ４アドレス → 一致した場合「no match」という評価で完了 1. !ＩＰｖ６アドレス → 一致した場合「no match」という評価で完了 1. any → 一致（常に一致する）した場合「match」という評価で完了 上記をまとめて解釈すると、 |
| 行 26: | 行 29: |
| 1. 「ＩＰｖ４アドレス『ではない』」の評価をする。「ＩＰｖ４アドレス」であれば「no match」として評価完了。そうでないなら「match」として次の評価。 1. 「ＩＰｖ６アドレス『ではない』」の評価をする。「ＩＰｖ６アドレス」であれば「no match」として評価完了。そうでないなら「match」として次の評価。 |
1. 「ＩＰｖ４アドレス『ではない』」の評価をする。指定された「ＩＰｖ４アドレス」であれば「no match」として評価完了。そうでないなら「match」として次の評価。 1. 「ＩＰｖ６アドレス『ではない』」の評価をする。指定された「ＩＰｖ６アドレス」であれば「no match」として評価完了。そうでないなら「match」として次の評価。 |
Ａ．ＢＩＮＤ９のＡＣＬ（Access Controll Lists）の癖となります。詳しくは参考文献をお読みください。 というのは不親切なので、解説すると、
- ＡＣＬの処理はリストの左から右へ評価されます。これはＡＮＤ結合であるということを意味しません。
- よってブール論理で解釈するのではなく、ファーストマッチ・ファーストアウトで解釈する必要があります。
- 接続元ＩＰアドレスに対して、以下の３つが判断されます。
- match and accept（一致かつ受諾）
- match and reject（一致かつ拒絶）
- no match（一致しない、なので次のリストに委ねる）
- これは「!」（reject）と「 」（accept、「!」が指定されてない）のニュアンスが直感的に違うことを意味します（今まで一致・不一致に見えませんでしたか？）。
- ネスト（{･･･}）されていた場合、その内容について下記の２つの評価を行い（ここでは一致・不一致の直感とマッチする）、その結果に対して上記３つの判断が実施されます。
- match（一致）
- no match（不一致）
- 当然ネストの中に更にネストできるので、それは上記２評価（match または no match）の繰り返しとなる。
上記ルールを踏まえ、問題のルールを解析すると･･･。
- 大枠は２つのリストに分かれる（「!」の意味に注意）。
- !{ !ＩＰｖ４アドレス; !ＩＰｖ６アドレス; any; } → match and reject
- key "ＴＳＩＧキー名." → accept or reject
- 最初のネストを分解すると、３つのリストに分かれる。
- !ＩＰｖ４アドレス → 一致した場合「no match」という評価で完了
- !ＩＰｖ６アドレス → 一致した場合「no match」という評価で完了
- any → 一致（常に一致する）した場合「match」という評価で完了
上記をまとめて解釈すると、
- 最初のネスト内では以下の評価を行う（「!」の評価に注意）。
- 「ＩＰｖ４アドレス『ではない』」の評価をする。指定された「ＩＰｖ４アドレス」であれば「no match」として評価完了。そうでないなら「match」として次の評価。
- 「ＩＰｖ６アドレス『ではない』」の評価をする。指定された「ＩＰｖ６アドレス」であれば「no match」として評価完了。そうでないなら「match」として次の評価。
- 「any」（任意の全てのアドレス）に･･･とここまで来ると常に match と解釈され、評価が終了する。
- また any の時点で既に、「match」評価されてるので、この場合の「any」の指定のあり／無しに意味はない（人間の直感には反するから入れておいた方がいい）。
- このネストでの結果を全体「!」＝match and reject で評価することから、「no match」（つまり次のリストの評価）の時は、次のリスト key が評価される。