前話までで、ACL の行は permit / deny と条件で packet を選別するものとして読めるようになっていた。次は show access-lists の末尾に出る数字を見る場面だ。

show access-lists の末尾に、数字が出ている。

Extended IP access list EDGE-IN
  10 permit tcp host 203.0.113.50 host 10.1.1.80 eq 80 (12 matches)
  20 deny   tcp any host 10.1.1.80 eq 22 (3 matches)
  30 permit udp any host 10.1.1.53 eq domain

この (12 matches) を見た瞬間、少し安心したくなる。数字が増えているのだから、この通信は通った。Web も成功した。戻りも経路も、きっと問題ない。現場では、そのくらいの速さで頭が答えを出そうとする。

ただ、その安心には小さな引っかかりが残る。ユーザーはまだ「画面が出ない」と言っているかもしれないし、戻り通信は別の境界で落ちているかもしれない。カウンタは役に立つが、通信全体の成功を証明するものではない。

hit count は、その行に通信が一致した証拠であって、アプリケーション成功や経路全体の正しさの証明ではない。

考えてみよう: permit 行の hit count が増えた。そこから、Web サーバが応答したことまで言えるだろうか。戻りの通信も通ったと言えるだろうか。それとも、言えるのは「その条件に当たった」までだろうか。

1. カウンタは、一致したことだけを語る

まず困るのは、数字を見た瞬間に判断が広がりすぎることだ。permit 行の 12 matches は、たしかに何かが起きた証拠に見える。けれど、その「何か」をアプリケーション成功まで広げてしまうと、確認すべき場所を見失う。

10 行目を読み直す。

10 permit tcp host 203.0.113.50 host 10.1.1.80 eq 80 (12 matches)

ここで直接言えるのは、外側の端末から Web サーバへ向かう Web 条件に一致した packet が、10 行目に当たったということだ。permit なので、その ACL が置かれた場所では通す判断に入った。だが、Web ページが最後まで表示されたか、戻りの packet が通ったか、途中の別の境界で止まっていないかまでは、この数字だけでは分からない。

Cisco のコマンドリファレンスでも、ACL のカウンタは access list の各 permit / deny statement に一致した packet 数を数えるものとして説明されている。つまり、カウンタは「成功数」ではなく「一致数」だ。show access-lists や show ip access-lists で見る (matches) は、その行に対する一致の記録として扱う。

次に、20 行目を見る。

20 deny   tcp any host 10.1.1.80 eq 22 (3 matches)

この 3 matches は、SSH 条件に一致した packet が 20 行目に当たった証拠だ。deny 行なので、その ACL のその場所では止める判断に入った。ただし、誰かがログイン画面まで到達して失敗した証明ではないし、サーバ側の認証処理が動いた証明でもない。

カウンタは、強い証拠になる。ただし、この数字だけで直接言えるのは ACL 行への一致までだ。その外側にある戻り通信、別経路、アプリケーション処理は、別の観測で確かめる。

2. hit count は、5 観測軸の最後に置く

数字だけを先に見ると、現場の判断は雑になりやすい。12 matches が増えているから大丈夫、3 matches があるからここが原因、と言いたくなる。けれど、どの判断の、どの条件の、どの場所の、どの順序の数字なのかが分からないままでは、カウンタはただの目立つ数字でしかない。

hit count を読む前に、まず見るのは 判断 だ。その行は permit なのか、deny なのか。境界は、その条件に一致した packet を通す側に入れたのか、止める側に入れたのか。

次に 条件 を見る。その行は送信元だけを見ているのか、宛先も見ているのか、protocol や port まで見ているのか。eq 80 や eq 22 は、前に学んだ L4 の目印が、境界の判断材料としてもう一度出てきたものだ。

その次に 場所 を見る。ACL は、どの interface のどちら向きに置かれているのか。入口で見たのか、出口で見たのか。同じ条件でも、見る場所と向きが変われば、カウンタが語る場面も変わる。

さらに 順序 を見る。ACL は上から順に読まれ、最初に一致した行で判断が止まる。下にもっと具体的な permit があっても、上の広い deny に先に当たれば、そこで終わる。

ここまでそろえて、最後に 証拠 として hit count を見る。すると 12 matches は、「なんとなく成功したらしい」ではなく、「この境界のこの向きで、この条件に、この順序で到達し、この行に当たった」という扱いやすい観測になる。

show access-lists を読むときも順番は同じだ。permit / deny、送信元、宛先、protocol、port、interface、in / out、上から読んだときにその行まで届くかを合わせる。そこまで見てからカウンタを見ると、数字は判断を狭く支える証拠になる。

3. 5 つの軸で、境界の選別を読む

最初は permit と deny の表に見えていたものが、境界が通信をどう選別しているかを読む材料に変わる。

最初の軸は 判断 だった。境界は permit / deny の行で、通すか止めるかを決めている。

次の軸は 条件 だった。境界は packet のどこを見るのか。送信元だけなのか、宛先も見るのか、protocol や port まで見るのか。ここで L4 の目印が、通す・止めるの判断材料になる。

その次の軸は 場所 だった。ACL は interface に置かれ、in / out の向きで packet を見る。どこで見るかが、同じ条件の意味を変える。

前回の軸は 順序 だった。ACL は上から順に読まれ、最初に一致した行で判断が止まる。条件が正しくても、行の並びが違えば結果は変わる。

そして今回の軸が 証拠 だ。show access-lists の hit count は、その行に packet が一致した証拠になる。ただし、それは成功証明ではなく、あくまでその行に当たったことを示す証拠として使う。

判断、条件、場所、順序、証拠。この 5 つが揃うと、なぜ通るのか、なぜ止まるのかを設定行の雰囲気ではなく観測の組み合わせで説明できる。どの条件を見たのか、どこで見たのか、どの順番で止まったのか、最後にどの行に当たった証拠があるのか。この順番で読むことが、境界で選別するための最小モデルになる。

4. ACLで選別、NATで書き換え — 同じ境界の別の処理

ACL は境界で選別する。条件を見て、通すか止めるかを決める。ここまでの 5 軸は、その選別を読むための最小モデルだった。

次に出会う NAT の世界では、境界は住所や port を書き換える。ここでは、変換表の中身や処理順序の詳細には入らない。ただ、同じ境界でも「選別する」と「書き換える」は別の処理だという区別を持っておく。

さらにその先には、状態を見る Firewall の世界がある。今回扱ったのは、stateless な packet filter の最小モデルだ。状態を持つ境界、session を追いかける境界、zone で設計する境界は、もう一段深い技術として残しておく。

ACL で見た「境界で選別する」仕組みと、NAT で見る「境界で書き換える」仕組みは、同じ境界に置かれる別の処理だ。判断・条件・場所・順序・証拠の 5 軸で選別を読み切ったことが、次に住所や port の書き換えへ進むときの足場になる。