VPNの低スループットはエントロピーの問題か?通常は違う
乱数を待つ起動時の停止と遅いトンネルは別の障害です。シードやバッファを変える前に、どちらかを測定してください。
トンネルを通るスループットの低下と、乱数を待って止まったままのマシンは、まったく異なる体験を生みますが、同じ苦情として記録されます。一方は、何かが動き出す前の間として現れます。もう一方は、動き続け、見ている間ずっとデータをゆっくり運ぶ接続として現れます。どちらなのかを判断するには十分間あれば足り、一週間分の推測を省けます。
似て見える二つの症状
新しい起動の後、接続を一つも受け付ける前に固まるサービスは、何かを待っています。素早く確立した後に期待される速度のほんの一部で転送するトンネルは、別の何かによって制限されています。暗号化という言葉がどちらの話にも現れるため、両者は一緒にされます。設定ファイルに触れる前に、両者を切り分けてください。
起動、認証、鍵の再交渉、そして転送そのものの周りにタイムスタンプを置きます。トンネルが使えるようになるまでの長い遅延は低い定常速度ではなく、両者を一つの数値に平均すると証拠が壊れます。
systemd-analyze blame | head -10 journalctl -u [email protected] -o short-precise | head -40 cat /proc/sys/kernel/random/entropy_avail
最初の二つのコマンドは起動時の処理を時間軸に置きます。三つ目はカーネルのエントロピー会計値を出力し、これは単一のデータ点としては有用ですが、帯域幅の計測器としては役に立ちません。
乱数の待ちが実際にどう見えるか
安全な乱数バイトの要求は、カーネルが乱数源を初期化するまでブロックすることがあります。これは起動の早い段階の仮想マシンや小型の組み込みボードで最も重要で、環境ノイズがほとんど集まっていないときです。そこから、暗号化されたすべてのバイトが新しいエントロピーを消費するという結論は導けません。
現代の生成器は一度シードした後、決定論的な構成から出力を生成し、独自のスケジュールで再シードします。大量転送はプールをバイト単位で枯渇させませんので、遅い転送中の低いプール値は原因について何も証明しません。
strace -f -e trace=getrandom -p $(pidof openvpn) 2>&1 | head -20 dmesg | grep -i 'random\|crng'
最初のコマンドは、見ている間にプロセスが乱数の呼び出しで止まっているかどうかを示します。二つ目はカーネル自身の初期化メッセージを示し、起動初期の停止がそこで見えるようになります。
カーネルのバージョンと、サービスが実際にリンクしているライブラリを記録してください。動作は実装間でもリリース間でも異なり、復旧後に取ったトレースは通常は停止をまったく捉えていません。
持続する遅さが実際にどう見えるか
全体を通して遅く転送するトンネルは、データ経路によって制限されています。飽和した一つのスレッド、外側のパケット損失、再送、満杯のソケットキューはそれぞれそのパターンを生み、それぞれに独自の修正があります。集計されたCPU率は一つの忙しいスレッドを隠し、これが最もよくある誤読です。総負荷を見る前に、スレッドごとの時間を見てください。
比較可能な基準で両方向を測定し、アプリケーション自身の報告ではなくインターフェースのカウンターを監視してください。
ss -tin dst 203.0.113.10 nstat -az | grep -i 'drop\|retrans' ethtool -S eth0 | grep -i 'drop\|error'
最初のコマンドは一つのピアのキューと輻輳の状態を示します。二つ目と三つ目はスタックとインターフェースでのドロップと再送を報告し、原因が通常最初に現れるのはそこです。
測定したボトルネックに合った修正を選ぶ
証拠が起動初期の初期化を指すなら、仮想マシンではホストが提供する乱数デバイスを含むこともあるプラットフォーム対応のシード経路を見てください。多数のゲストにそのままコピーされたシードイメージは、独立した初期化の代わりにはなりません。
証拠がデータ経路を指すなら、カウンターが示すものを調整してください。バッファサイズはキューがあふれるときに役立ち、一つのスレッドが飽和しているときには何もしません。カウンターを上げるためにエントロピーデーモンを導入することはスループットの修理ではなく、グラフを良く見せるためにシードの前提を変えることはセキュリティ特性を数値と引き換えにします。
同じ測定が同じ条件で改善したときにだけ、変更を受け入れてください。カウンターが大きくなることは結果ではなく、測定された待ち時間が短くなること、または原因が特定された速い転送が結果です。