VPNゲートウェイ向け暗号カード——購入前の四つの受け渡し

古い暗号アクセラレータがPCIの一覧に現れると、VPNの暗号化が速くなると考えられがちだ。それが本当になるには、四つの別々の受け渡しが成功しなければならない。システムがデバイスを見つけ、保守されているドライバがそれを動かし、インターフェースがVPNの必要とする操作を公開し、VPNの稼働中のバックエンドがそれを要求する。どれか一つでも失敗すれば、カードはトンネルの実際の経路の外に留まる。

検出は最初の受け渡しであって、最後ではない

検出が証明するのは、バスがデバイスを見ていることと、カーネルがそれが何かの見当を持っていることにすぎない。次の関門はドライバの対応であり、これはバージョン依存だ。古いリリースにあったモジュールが現在のカーネルパッケージから完全に消えていることがある。さらに、ドライバはデータチャネルが使う特定のアルゴリズムとモードを登録しなければならない。AES-CBCを加速するカードは、AES-GCMを交渉する構成には何の役にも立たない。

評価では各受け渡しを個別に名付ける。四つ目での失敗は、外から見れば一つ目での失敗とまったく同じに見えるからだ。

カーネルのアルゴリズム一覧を読む

ホストがデバイスと、登録したアルゴリズムについてすでに知っていることを集めることから始める。

lspci -nn | grep -i -E "crypt|hifn|soekris"
grep -E "^(name|driver|priority)" /proc/crypto | head -40

PCIの行は、ドライバを探すのに必要なベンダーIDとデバイスIDを与え、/proc/crypto 登録済みの実装をドライバと優先度とともに一覧にする。優先度の値は同じアルゴリズムの実装間の選択を順序づけるもので、アプリケーションがその一つを選ぶこととは同じではない。カードのアルゴリズムがそこに現れなければ、ドライバはそれを登録しておらず、ユーザー空間のどの変更もそれを呼び出さない。カードの画面写真ではなく、IDと実装名を記録する。

VPNがその実装を選ばなければならない

カーネルでの可用性はメニューであり、VPNプロセスがそこから注文した保証ではない。バックエンドが実際に何を使っているかを確認する。

openssl speed -evp aes-256-gcm
openssl engine -t -c

速度のコマンドはライブラリ自身の経路を試し、設定されたままのマシンの基準値を与える。一方、エンジンの一覧はOpenSSLに任意のプロバイダがそもそも利用できるかを示す。独自の暗号ライブラリを使うユーザー空間のVPNはカーネルの実装を完全に迂回するため、登録済みのドライバが無関係でありうる。データチャネルのオフロードはまた別の第三の仕組みで、暗号要求を拡張カードへ送るのではなくパケット処理を変える。四つ目のためにハードウェアを買う前に、この三つのどれが自分の配備を表すのかを確定する。

すでにあるCPUの経路と比べる

現代のプロセッサにはAES命令が搭載され、保守されたライブラリは追加のハードウェアなしでそれを使い、バス転送や余分なコピーを避ける。古いアクセラレータは、印象的な生の暗号数値を報告しながらも、この経路に負けることがある。実際の負荷を測る。同じトラフィック、同じ保護設定で、基準と候補を比べ、CPU負荷とアプリケーションのスループットを同時に記録する。更新と復旧の挙動も判断に含める。保守されないモジュールは、ゲートウェイの寿命全体にわたって保守リスクを高めるからだ。

購入の根拠は、支えられた連鎖と測定された利益である。検出されたカードや、誰かがかつてコンパイルしたモジュールは、保守されたゲートウェイを旧式ハードウェアに依存させる理由にはならない。