UDP コネクションそれ自体は、ステートフルなコネクションではない。どちらかといえばステートレスなコネクションだ。理由としてはいくつかあるが、まず、接続の確立もクローズも備えていないという点。そもそも UDP 接続にはシーケンス [訳者補足: sequence = 順序、手順] がない。ある順序で UDP データグラムがやりとりされる場合でも、どういう順序で送るかといった情報のやりとりは何もないのだ。それにもかかわらず、カーネル内部で接続のステートを判定することは可能だ。では、コネクションがどのように追跡されるか、 conntrack の中身はどんな風に見えるかを見ていこう。
ご覧の通り、 TCP 接続とまったく同じ要領でコネクションが確立する。これはユーザ空間から見た様子だ。内部的に見ると conntrack 情報は少し様子が違う。とはいえ、細部は本質的には変わらない。ではまず、最初の UDP パケットが送られた時のエントリを見てみよう。
udp 17 20 src=192.168.1.2 dst=192.168.1.5 sport=137 dport=1025 \ [UNREPLIED] src=192.168.1.5 dst=192.168.1.2 sport=1025 \ dport=137 use=1
第一と第二の値から、これが UDP パケットであることが分かる。第一はプロトコル名であり、第二はプロトコルナンバーだ。 TCP コネクションと同様である。第三の値は、このステートエントリがどれだけの時間保持されるべきかを示す。そこから先は、検出したパケットの情報と、このコネクションで次に送信主から来るパケットに期待される情報だ。つまり、送信元、送信先、送信元ポート、宛先ポートだ。この時点では、 [UNREPLIED] フラグが記され、このパケットに対する返答はまだ一度も行われていないことを示している。そして最後に、返答パケットに期待される事柄の簡潔なリストがある。後者のグループでは、エントリが前者のものとは入れ違いになっていることも見逃さないでいただきたい。この時点でのタイムアウトは、デフォルトでは 30 秒だ。
udp 17 170 src=192.168.1.2 dst=192.168.1.5 sport=137 \ dport=1025 src=192.168.1.5 dst=192.168.1.2 sport=1025 \ dport=137 [ASSURED] use=1
この時点で、最初の送出パケットへの応答がなされ、コネクションは ESTABLISHED の判定に移行した。見ての通り、その事実はコネクション追跡には明示されない。主な違いは [UNREPLIED] フラグが消え去ったことだ。それに加えて、デフォルトタイムアウトは 180 秒に変わった。ただし、この例では既に 170 秒に減少している。さらに 10 秒後には 160 秒となるだろう。しかし、まだ何かひとつ足りない。そう、前にも述べた [ASSURED] フラグだ。追跡中のコネクションに [ASSURED] フラグが付くには、 NEW 状態のパケットに対して正規な回答パケットが返ってきている必要がある。
udp 17 175 src=192.168.1.5 dst=195.22.79.2 sport=1025 \ dport=53 src=195.22.79.2 dst=192.168.1.5 sport=53 \ dport=1025 [ASSURED] use=1
この時点をもって、コネクションは確立 (assured) した。コネクションの様子は先ほどの例と全く同じだ。もしも、180 秒の間この接続が使用されなければ、コネクションはタイムアウトする。180 秒というとかなり短いように思えるが、ほとんどの場合にはこの数字で充分だ。エントリにマッチするパケットがファイヤーウォールに入ってくる度に、この値はデフォルト値へとリセットされる。他の内部ステートについてもこれと同じことが言える。