【CCNA_3】ステートフルとステートレスは何が違う？｜通信の「状態を見る」とは
前回、ACLとファイアウォールの違いを調べている中で出てきた、
ステートレス（Stateless）
と
ステートフル（Stateful）
という言葉。
「ステートレスは通信の状態を持たない」
「ステートフルは通信の状態を持つ」
と説明されることが多いですが、
正直、それだけだと少し分かりにくい。
そもそも、
通信の“状態”って何？
というところから気になりました。
今回は、ステートフルとステートレスの違いを、実際の通信の流れをイメージしながら整理します。
そもそも「State」って何？
Stateは、日本語では「状態」という意味です。
ネットワーク通信でいう「状態」とは、
その通信が今どういう段階にあるのか
という情報です。
たとえばTCP通信であれば、
* まだ通信を開始していない
* 接続を確立しようとしている
* 接続が確立している
* 通信中
* 接続を終了しようとしている
といった状態があります。
つまりステートフルな機器は、
単純に目の前のパケットだけを見るのではなく、
「このパケットは、今どの通信の流れの中にいるのか」
を把握しながら判断します。
ステートレスとは？
ステートレスな通信制御では、
それまでの通信の流れを基本的には記憶せず、受け取ったパケットごとに判断します。
たとえばACLによる基本的なパケットフィルタリングでは、
送られてきたパケットについて、
* 送信元IPアドレス
* 宛先IPアドレス
* プロトコル
* ポート番号
などを確認し、設定された条件と一致するかどうかでpermit／denyを判断します。
重要なのは、
「このパケットは、さっき送った通信への返事なのか？」
という通信全体の流れを基本的には記憶していないこと。
毎回、
「今来たこのパケットは条件に合う？」
と判断するイメージです。
ステートフルとは？
一方、ステートフルな通信制御では、
通信の状態を記録し、その情報を使って次のパケットを判断します。
ステートフルファイアウォールでは、通信が開始されると、
* 送信元IPアドレス
* 宛先IPアドレス
* 送信元ポート
* 宛先ポート
* プロトコル
* 接続状態
などの情報を記録します。
そして、その後に届いたパケットが、
既に開始されている通信の一部なのか
を確認します。
この情報を記録しておく仕組みを、
ステートテーブル
や
コネクションテーブル
などと呼びます。
Webサイトを見る通信で考えてみる
たとえば、社内PCからWebサイトにアクセスするとします。
PCからWebサーバーへ、
「このWebページを見たい」
という通信を送ります。
その後、WebサーバーからPCへレスポンスが返ってきます。
ステートフルファイアウォールは、最初の通信が通ったときに、
「このPCから、このWebサーバーへの通信が開始された」
という情報を記録します。
そのため、Webサーバーから返ってきた通信を見たときに、
「これは外部から突然始まった通信ではなく、内部のPCから開始された通信への返事だ」
と判断できます。
これが、
状態を持って通信を判断する
ということです。
ステートレスの場合はどうなる？
ステートレスな制御では、
戻ってきたパケットについても、
基本的にはそのパケット自身の条件を見て判断します。
つまり、
「これはさっきの通信の返事だからOK」
ではなく、
「このパケットは設定された条件に一致しているか？」
を確認します。
そのため、双方向通信を扱う場合は、
行きの通信だけでなく、戻り通信についても許可する条件を考える必要があります。
TCPだとステートフルが分かりやすい
ステートフルという考え方は、TCP通信で考えるとかなり分かりやすいです。
TCPでは、通信を始めるときに接続を確立します。
代表的なのが、
3ウェイハンドシェイク
です。
1. クライアントからSYN
2. サーバーからSYN/ACK
3. クライアントからACK
という流れで接続を確立します。
ステートフルファイアウォールは、
こうした通信の流れを追跡できます。
そのため、
「このSYN/ACKは、さっき送られたSYNへの返事なのか」
といった形で、
通信の前後関係を見ながら判断できます。
UDPは接続しないのにステートフル？
ここで少し疑問。
TCPには接続状態がありますが、
UDPはコネクションレス型のプロトコルです。
では、UDPではステートフルにできないのでしょうか。
そんなことはありません。
UDPにはTCPのような接続確立はありませんが、ステートフルファイアウォールは、
送信元・宛先IP、ポート番号、一定時間内の通信などをもとに、通信の流れを管理することができます。
つまり、
TCPとまったく同じ方法ではないものの、
UDP通信でも「この戻り通信は、さっき開始された通信に関連している」と判断することは可能
です。
ステートフルのメリット
ステートフルな通信制御の大きなメリットは、
通信の流れを理解したうえで判断できること
です。
たとえば、
内部ネットワークから外部へのWebアクセスを許可した場合、
その戻り通信について、
毎回細かく条件を設定しなくても、
既存の通信へのレスポンスとして扱うことができます。
また、
外部から突然届いた通信と、
内部から開始された通信への返事を区別できるため、
より柔軟に通信を制御できます。
ステートフルにもデメリットはある
ステートフルだから、すべての面で優れているというわけではありません。
通信状態を追跡するには、
その情報を保存し続ける必要があります。
つまり、ステートレスな処理と比べると、
* メモリを使う
* 処理が複雑になる
* 大量の接続を管理する必要がある
といった負荷が発生します。
一方でステートレスな処理は、
基本的にパケットごとに判断するため、
仕組みがシンプル
という特徴があります。
どっちがいい、ではない
ここまで見ると、
「じゃあステートフルの方が上位互換なのでは？」
と思ってしまいます。
でも、重要なのは、
用途によって使い分ける
ということです。
単純なパケットフィルタリングで十分な場所では、ステートレスな制御が使われます。
一方で、
通信の流れまで把握してセキュリティを高めたい場合には、ステートフルな制御が使われます。
つまり、
ステートレス＝古い、弱い
ステートフル＝新しい、強い
という単純な話ではありません。
今回のまとめ
今回一番大事なのは、
ステートレス
→ 通信の状態を基本的に保持せず、パケットごとに条件を見て判断する。
ステートフル
→ 通信の状態を記録し、前後の通信との関係も見ながら判断する。
という違いです。
かなりざっくり言えば、
ステートレス
「今来たこのパケットは通していい？」
ステートフル
「今来たこのパケットは、さっき始まった通信の続き？」
という違い。
「状態を見る」という言葉だけでは少し分かりにくかったですが、
通信の前後関係を覚えているかどうか
と考えると、かなり理解しやすくなりました。
※この記事は初学者が学習の中で調べながらまとめた内容になります。
先輩エンジニアの皆さま、間違いや誤解があるなという箇所や追加の補足情報などありましたらご指摘いただけますと大変ありがたいです🙇♂️
関連記事
・前回｢【CCNA_2】ACLとファイアウォールは何が違う？｜似ているようで違う役割を整理｣
・次回｢タイトル未定｣
▶︎現在執筆中！
