接続フックはセッションポリシーであり、パケットフィルターではない
クライアント接続フックはセッションごとに一度だけ動作し、ペイロードを目にすることはありません。受け入れはセッションがある場所に、コンテンツの変更はリクエストがある場所に置きます。
クライアントがトンネルを通じて何を送っているかを調べたいと考えた人が、ドキュメントで接続フックを見つけ、パケットを一つも受け取らないスクリプトを書き始める。フックは実在し有用だが、その作業単位はセッションであり、バイトではない。適切な部品を選ぶことは、作業が起こりうる三つの場所の比較であり、決定的な問いは、それぞれが実際にどの単位を見られるかである。
フックが受け取るもの、決して受け取らないもの
クライアント接続フックは、認証済みのクライアントがセッションを確立したときに一度だけ、サーバーのプロセス文脈で、文書化された引数とコモンネームや割り当てアドレスといった環境値とともに動作する。クライアントごとの設定を書き、受け入れを判断し、外部リソースを割り当て、あるいは接続が起きたことを記録できる。できないのはトラフィックを観察することで、最初のパケットがトンネルを渡るころにはフックはすでに戻っている。
これは回避すべき制約ではない。ストリームを処理しようとするセッションコールバックは接続の寿命いっぱい動き続ける必要があり、デーモンのスクリプト契約はその形を想定していない。フックが邪魔だと決める前に、何のためにあるのかを問うべきである。
再接続も重要である。切断して再接続するクライアントは新しいセッションなので、フックが割り当てるものは冪等であるか、後片付けをする切断イベントと対になっていなければならない。再接続のたびに漏れる状態は、フック基盤の設計で最初に現れる典型的な不具合である。
セッションポリシーはフックの内側にある
受け入れはフックの自然な仕事である。誰がどこからどの証明書で接続したかを知っており、このセッションを続行させるか拒否するかを決められる。その判断は安価で、一度だけ起こり、ペイロードのバイトを一つも見る必要がない。
設定の割り当ても同じ形に収まる。フックはクライアントのアドレスを選び、その身元にふさわしいオプションを渡し、サーバーがこのクライアントのために読む断片を書くことができる。判断がセッション単位なので、何かがうまくいかず、特定のクライアントが特定のアドレスを得た理由を誰かが説明しなければならないときも、理解可能なままでいられる。
記録は三つ目の適合である。セッションが受け入れられたことを、その身元と時刻とともに示す監査エントリは、まさにここに属する。それはトラフィックログではなく、そう見せかけるべきでもない。後でクライアントがトンネルの内側で何をしたかを誰かが尋ねるなら、答えは別の場所から来なければならない。
パケットの仕事はパケット経路にある
飛んでいるバイトを見たり変えたりするのが要件なら、部品は転送経路に置かれなければならない。待ち行列を伴うファイアウォール規則、トラフィック制御のフック、あるいはユーザー空間のフォワーダーである。それらの仕組みはパケットを見ており、独自の状態、独自の故障の仕方、独自の性能特性を持っている。
その層でペイロードを編集するのは、読むより難しい。一バイトを変えると長さフィールド、チェックサム、プロトコルの状態機械が無効になりうるし、第三層のトンネルはそのどれからも守ってくれない。外側のヘッダーが編集対象ではないというだけのことである。誰かにコンテンツの書き換えを約束する前に、その修復作業を見積もっておくべきだ。
インターフェースのキャプチャはこの分類で最も安価な道具であり、編集者ではなく観察である。両方ともトラフィックを見ると説明されるため混同されやすいが、キャプチャはファイルを生み、パケット経路は判断を生む。
アプリケーションの変更はアプリケーションにある
リクエストが何を含むか、あるいは応答がどう形成されるかを変えるのが目的なら、正しい場所はサービス自体か、意図的にプロトコルを終端するプロキシである。それらの部品はすでにリクエスト、応答、そしてアプリケーションが期待する認証を理解しており、それはまさにパケットフィルターに欠けている文脈である。
アドレス変換がこの一覧の最後にあるのには理由がある。アドレスとポートを書き換え、ペイロードには手を触れないので、コンテンツに触れるレシピにどれほど頻繁に現れても、コンテンツの道具ではない。
これらの境界を分けておくことが、設計を説明可能にする。フックの中のセッションポリシー、パケット経路でのパケット処理、そしてプロトコルが意図的に終端される場所でのアプリケーション変更。この三文はレビューのチェックリストにもなる。
TLS がなお会話を終わらせる場所
以上のすべてを生き延びるものがある。トンネルの内側で HTTPS を運ぶトラフィックは、それ自身の転送暗号化を保つ。VPN の鍵を持っていても得られるのは内側の IP パケットであり、向こう側のウェブサイトのセッション鍵は得られない。
だからフックは原理的にもコンテンツを検査できず、だからこそ配備が意図的に内側の TLS を終端しない限り、パケット経路が見るのは暗号文である。 スクリプト契約 フックに何が与えられるかを述べている。ペイロードについては何も語らない。与えるべきペイロードが存在しないからだ。