Web を許可したはずなのに、通信が落ちる。
条件は書いた。ACL も interface の正しい向きに置いた。前話までの見方でいえば、「見る条件」と「見る場所」はそろっている。それでも落ちる。
こういうとき、目は下のほうにある permit 行へ吸い寄せられる。たしかに Web を許可している。宛先も合っている。だから通るはずだ、と考えたくなる。
けれど ACL は、表の中から都合のよい行を探してくれるわけではない。上から順に読み、最初に一致した行で判断が止まる。この読み方に変えると、「許可行を足したのに落ちる」理由が見え始める。
ACL は上から順に読まれ、最初に一致した行で判断が止まるため、結果は条件だけでなく行の順序でも決まる。
考えてみよう: 下に
permit tcp OPS-PC01 WEB-SRV01 Webがあるのに、上にdeny ip 10.1.50.0/24 WEB-SRV01がある。OPS-PC01 から WEB-SRV01 の Web 通信は、どちらの行で止まるだろう。許可行が「ある」ことと、そこまで「読まれる」ことは同じだろうか。
1. ACL は、上から順に読む
ACL は、条件を並べた表として見える。permit は通す。deny は止める。前の話までで、条件の列と置き場所を見てきた。だから、まずは「この通信を許可する行があるか」を探したくなる。
ただし、表は一度に全部を眺めて、いちばん都合のよい行を選ぶわけではない。通信が来ると、ACL は最初の行から順番に「この条件に一致するか」を見る。一致しなければ次の行へ進み、さらに一致しなければ、その次へ進む。
この読み方を忘れると、ACL はただの条件リストに見える。すると、「下に permit があるから通るはず」という見方になる。でも、ACL の読解で大事なのは、条件があるかどうかだけではない。その条件へ、順番としてたどり着くかだ。
ここが抜けると、通信の落ち方を読み間違える。許可行があるのに落ちるのではなく、許可行まで読まれていないのかもしれない。行の存在と、評価の到達は別の話として分けて考える必要がある。
2. first match で、下の行は読まれない
OPS-PC01 から WEB-SRV01 の Web 通信を通したい。ACL には、下のほうに Web を許可する行がある。
deny ip 10.1.50.0/24 WEB-SRV01
permit tcp OPS-PC01 WEB-SRV01 Web
permit icmp OPS-PC01 WEB-SRV01
Web を許可する行だけを見れば、通りそうに見える。けれど ACL は上から読む。最初の行は、10.1.50.0/24 から WEB-SRV01 への通信を広く deny している。OPS-PC01 は 10.1.50.0/24 の中にいて、宛先も WEB-SRV01 なので、Web 通信であっても最初の広い deny に一致する。
そこで判断は止まる。これが first match だ。最初に一致した行で permit / deny の判断が確定し、下にある Web の permit 行は読まれない。広い条件が上にあると、その下の細かい条件を飲み込んでしまうことがある。
3. 表の最後には implicit deny がある
表には、書かれていない最後の deny がある。「deny 行が見当たらないから通る」とは考えないほうがいい。
たとえば、ACL に次の 2 行だけがあるとする。
permit tcp OPS-PC01 WEB-SRV01 Web
permit icmp OPS-PC01 WEB-SRV01
Web は許可されている。ICMP も許可されている。では、OPS-PC01 から WEB-SRV01 へ、ここに書かれていない別の通信が来たらどうなるか。
1 行目には一致しないので、次へ進む。2 行目にも一致しないので、さらに次へ進む。でも、もう明示された行はない。ここで通信は通るのではなく、表の最後にある書かれていない deny で止まる。これが implicit deny だ。
implicit deny は、明示された行として見えないことがある。だから、ACL を読むときは「書かれている deny だけ」を探して終わりにしない。通したい通信は、どこかの permit に一致する必要があり、どの明示行にも一致しなければ表の底で止まる。
4. ACL を読むのは、条件だけでなく順序でも結果が決まること
許可行が下にあるのに通信が落ちるとき、見るのは permit 行の存在だけではない。その通信は上から順に見てどこで最初に一致するのか、その first match は permit なのか deny なのか、下にある行はそもそも読まれる位置にあるのか。どの明示行にも一致しないまま implicit deny へ落ちていないかも見る。
この順番で追うと、ACL の落ち方は説明できる範囲に収まる。条件があり、場所と向きがあり、さらに順序がある。前話までで ACL がどこで評価されるかを見て、今回はその場所に置かれた表が上からどう読まれるかを見た。
頭の中では「この行に当たっているはず」と読めた。実際にその行へ当たっていることは、次に show access-lists の hit count を、「通信全体が成功した証明」ではなく「その条件に一致した証拠」として読むときに確かめる。