VPNのエントロピーは尽きるのか？entropy_availが本当に示すもの

カーネルの乱択が尽きるという説明は、遅いVPNに対して魅力的であり、人が報告する症状に対してはほぼ常に誤りです。乱択出力を待つホストは特定の瞬間に停止します。多くは起動の初期か、鍵の処理中です。トンネルがすぐに接続してから転送が遅い場合は、むしろスループットを語っています。読んでいる途中の数値を直すためにデーモンを入れる前に、この二つの観測を切り分けてください。

神話が生き残る理由

どちらの問題も実在し、遠目には同じに見えます。起動直後の仮想マシンで開始が止まるのは本当に起こりますし、確立後の遅いトンネルも同じくらい実在します。誤りは、両方の話に暗号がどこかで登場するからといって、二つ目が一つ目のせいだと決めつけることです。暗号化という言葉は、転送する一バイトごとに環境ノイズを一バイト消費するなどとは一言も言っていません。

これらの生成器はそう動きません。暗号ライブラリは種を入れた生成器を保持し、そこから出力を取り出し、独自の方針で再シードします。したがって高価なのは種入れの瞬間であり、定常転送ではありません。

生成器がパケットごとに行うこと

OpenSSL 3 では、既定の生成器階層は構成と状態に応じてシードと再シードを行う DRBG インスタンスから構築されます。OpenVPN 2.6 では、AEAD のデータ経路がパケットの通し番号とセッションごとの暗黙値から nonce を導きます。一方、古い CBC 経路はパケットごとに擬似乱数 IV を取ります。どちらの方式も、一ギガバイトを移すと新しいカーネルノイズを一ギガバイト消費するという規則を支えません。どちらも、種入れが重要になるのは鍵生成とハンドシェイクの場面だという考えを支えます。

CBC の場合は神話に似ていて神話ではないので、名指しする価値があります。パケットごとの IV は、ライブラリ自身の再シード予定に従ってライブラリの生成器から供給され、パケットごとにカーネルを呼ぶことは決してありません。バイトあたりのエントロピーコストを誰かが引用したら、どのライブラリ版とどのコード経路を測ったのか尋ねてください。

待ちが実際に現れる場所

タイムスタンプはセッションではなく段階の周りに置きます。起動、認証、鍵交換、転送です。トンネルが使えるようになる前の待ちは、低い定常レートとは別の苦情であり、乱択を指すのは片方だけです。Linux では通常の getrandom() 要求は、カーネルの乱択源が初期化されるまでブロックすることがあります。だからこの問題の起動時の版は、初期にプールへ供給するものが少ない仮想マシンや組み込みボードで現実になります。

その収集の冒頭に置くべき安価なコマンドが二つあり、表が必要になる前に簡単な問いを片づけます。それらが読むカウンターは帯域の計器ではなくエントロピーの簿記であり、一度のスナップショットでは、プロセスがブロックしているか、どれだけ待ったか、ライブラリがどのインターフェースを呼んでいるかは示せません。復旧後に取ったサンプルは停止を丸ごと見逃すのが普通なので、カーネル版を読みのそばに残してください。

cat /proc/sys/kernel/random/entropy_avail
uname -r

読みに合わせて対処を選ぶ

カーネルが本当に初期化を待っているなら、トンネルではなく、プラットフォームが支えるシード経路を見てください。仮想マシンにはホスト提供の乱択デバイス、たとえば virtio-rng を与えられます。またイメージの準備が重要です。多くのゲストにそのままコピーされた種は独立した初期化ではないからです。起動後にライブラリがシード失敗を報告するなら、カーネル設定を変えるのではなく、その設定された供給元とプロバイダの挙動を調べてください。

ss -tin dst 203.0.113.7
sar -n DEV 1 5

OpenSSL の生成器ドキュメントは、この階層が入力をどう得るか、再シードがいつ起きるかを説明しており、神話よりずっと狭い主張で、その実装にだけ当てはまります。エントロピー用デーモンは万能の速度修理ではなく、カウンターを上げるために導入することは、遅延を示さないまま安全上の前提を変えてしまいます。スループットについてはデータ経路を追ってください。飽和したスレッド、再送、外側の損失、待ち行列の破棄はそれぞれ別の対処を要し、バッファサイズは待ち行列の証拠とともにソケットのバッファリングに働きかけます。