前話で、パケットには IP アドレスだけでなく、TCP / UDP のポート番号も載ることを見た。
宛先 IP が同じでも、443 番なら Web、22 番なら SSH として扱われる。通信の中には、「どこへ行くか」だけでなく、「何の通信か」を見分ける手がかりも入っている。
社内 PC から外の Web サイトは開ける。けれど、同じ PC から SSH で外へ出ようとすると、そこだけ通らない。経路が壊れているなら Web も落ちるはずだ。宛先の IP アドレスは間違っていない。用途を示す L4 の手がかりも、パケットの中に残っている。それでも Web だけが通り、SSH が止まるなら、途中の境界で「その通信を通してよいか」が見られている。
ACL は、境界で通信を通すか止めるかを判断する条件表である。
境界装置は、通信が来るたびに条件表と照らし合わせ、通すか止めるかを決めている。ACL (Access Control List) と呼ばれるこの表で、条件に当たった通信は permit なら通り、deny なら止まる。どの明示的な許可にも当たらない通信は、最後に implicit deny で止まる。
考えてみよう: Web は開けるのに、同じ端末から別の用途の通信だけ止まる。L3/L4 の手がかりは見えているはずなのに、なぜ結果が分かれるのか。先に 5 秒だけ、自分なりの説明を置いてみる。
境界は、条件表を読んでいる
通信を見るとき、最初は「届くかどうか」に目が向く。ケーブルはつながっているか、IP アドレスは合っているか、ルートはあるか。L3 は宛先のネットワークへ向かうための材料で、L4 はホストの中でどの用途へ届けるかを分ける材料だった。
境界では、届く前にもう 1 つ別の判断が入る。宛先へ届く材料がそろっていることと、境界が通してよいと判断することは、同じではない。境界装置は通信の情報を条件表に照らし、条件に当たればその行に書かれた判断に従う。Web の通信は通してよい条件に当たり、SSH は許可の条件に当たらないか、止める条件に当たる。同じ端末から出た通信でも、条件表に照らした結果が異なるため、通るものと止まるものに分かれる。
permit は通す、deny は止める
条件表の判断は、入口では permit と deny の 2 つに分けて考えればよい。permit は、条件に一致した通信を通す判断。deny は、条件に一致した通信を止める判断だ。
permit や deny を通信の種類そのものと混同しやすい。「Web だから必ず permit」「SSH だから必ず deny」ではない。設定された条件に当たったとき、その行に permit と書かれていれば通り、deny と書かれていれば止まる。条件表に「この宛先へ向かう Web の通信は通す」とあれば進み、「この用途は止める」とあれば境界で止まる。結果を分けているのは、条件との一致だ。
ACL には底のルールもある。明示的な許可に当たらない通信は、最後に implicit deny で止まる。設定に deny と書かれていないから通る、ではない。deny と書かれた行だけが通信を止めると読むと、明示的な deny が見えないのに止まる場面で原因を別の場所へ探しに行ってしまう。許可に当たらなければ、最後は implicit deny で止まる。
L4 の手がかりが、境界で呼び戻される
L4 ヘッダは、ホストの中で届け先や用途を分けるための手がかりだった。Web を見る通信、名前を引く通信、ファイルを送る通信、遠隔操作の通信は、同じ端末から出ても用途が違う。L4 の情報があるから、ホストはそれぞれを別の処理へ渡せる。
境界装置も、この情報を判断材料として使える。通信の送信元や宛先だけでなく、用途を示す情報まで条件に入っていれば、境界は用途ごとに通すか止めるかを分けられる。届けるために使っていた材料が、境界では選別の材料にもなる。送信元だけを見るのか、宛先も見るのか、プロトコルやポートまで見るのかは、ACL の書き方で変わる。それは次の話で扱う。
ACL が見るものを読む準備
Web は開けるのに、同じ端末から別の用途の通信だけ止まるのは、境界の条件表で見た結果が違うからだ。届く材料があっても、境界で許可されなければ先へ進めない。
通すか止めるかを判断する条件表として ACL が見えたら、次は条件の中身を読む。条件表は通信のどの部分を見ているのか。送信元だけなのか、宛先も見るのか、用途を示すプロトコルやポートまで見るのか。次は、その条件表が通信のどの部分を見るのかを読む。