IPsec のスループットが想定より低い？まず有効な SA を確認する
長い変換リストは、あなたの転送を守っているセッションではない。暗号化を疑う前に、ネゴシエートされた SA、ペイロードサイズ、実際に届いたレートを記録しよう。
構成には八つの変換が並んでおり、誰かが最も強いものを読み、スループットの数値がそれに結び付けられる。トンネルはおそらくその変換を選んでおらず、誰かが思い描いた作業負荷も実行していない。ネゴシエートされたのはそのリストの一項目であり、一つのパケットサイズ、一つの方向、一つのビルドにすぎない。それを測れば、アルゴリズムをめぐる議論は始まる前に終わるのが普通だ。
症状：構成が約束する値を下回る数値
長い変換リストは可能性を並べたもので、どの可能性もこのハードウェア上ではなく紙の上で採点される。ネゴシエートされた結果は双方が受け入れた一つの組み合わせであり、互換性のためにどちらかがまだ許す最も弱いものであることもある。その組み合わせが何を達成するかはオフロード状態、パケットサイズ、キューの挙動に依存するので、同じポリシーファイルを持つ二台の機器が大きく異なる結果になることがある。リストはメニューであり、アソシエーションは返ってきた注文だ。
リストを読めば何が選ばれ得たかがわかり、アソシエーションを読めば何が実際に転送を運んでいるかがわかる。スループットの数値が語るのはそれだけだ。リストから始まる調整手順はどれも、書類仕事の増える推測にすぎない。
この転送を運んでいるアソシエーションを記録する
ASA では show crypto ipsec sa 有効なアソシエーションを変換と方向ごとのカウンタとともに一覧表示する。そして コマンドリファレンス 重要なピアと方向を選び、鍵の再ネゴシエーションがアソシエーションを置き換えてカウンタをリセットする—それはまだ信頼していた基準値を静かに無効にする—ことに注意する。出力はテストメモの隣に保存し、次の実行で比較できるようにする。実行ごとにアソシエーション識別子がずれると、以後の比較はすべて意味を失う。
| What to record | Where to read it | What it rules out |
|---|---|---|
| Negotiated transform and SA identifiers | show crypto ipsec sa for that peer and direction | "the configuration picked the wrong algorithm" |
| Offload or accelerator state for that build | platform show commands and interface statistics | "the crypto engine is the ceiling" |
| Payload size and offered rate | the test tool's own settings and summary | "packets per second versus bytes per second" |
| Delivered rate and loss at the receiver | the receiving endpoint, not the sender's counters | "the sender transmitted, so it arrived" |
| Access-link load and drops | underlay interface counters along the path | "the bottleneck lives inside the tunnel" |
五行あれば測定は再現可能になり、どの行も欠けたときに特定の説明を排除する。どれも提案リストの項目ではない、というのも、リストは今あなたのバイトを守っているものを言えないからだ。表を一度埋めれば、次の障害は新しいアルゴリズム論争ではなくデータから始まる。
アクセスリンクの行こそ、人が飛ばす行だ、そして暗号に見える差を最もよく説明するのもその行である。飽和したアンダーレイや経路上のポリサーは、遅いエンジンと同じ形の症状を生む。
制御された負荷で片方向を測る
テストはゲートウェイ自身ではなく、アプリケーションを代表する LAN 端点から実行する—ゲートウェイが生成するプローブは別のローカルポリシーに従うことがあるからだ。二本目のストリームを足す前に片方向を測り、提示レートと受信側が実際に受け取った量の両方を記録する。レート制限した UDP 実行は提示負荷と TCP の輻輳応答を切り分けるが、無制限の UDP 送信は中立的な診断ではない。ペイロード長も記録するべきだ、より大きなデータグラムはパケットレートとカプセル化のオーバーヘッドの両方を変えるからだ。
show crypto ipsec sa peer 203.0.113.9
iperf3 -c 10.20.0.10 -u -b 200M -l 1200 -t 30同じペイロード長と同じ時間で同じテストを二回実行するのは、一度の実行では上限と不出来な一分を区別できないからだ。受信側が送信側の発した数より少ないパケットを報告するなら、その損失があなたの発見であり、暗号エンジンは候補の一つにすぎない。
何かを調整する前に差を説明する
転送ポリシー、キューの破棄、インターフェースエラー、リソース制限を暗号化経路とあわせて確認するのは、レートの不足だけでは CPU を特定できないからだ。会計の層も明示しておく、外側のトンネルバイトにはカプセル化が含まれ、再送は内側と外側のカウンタの関係を動かす。無関係なカウンタをバイト単位で比べると、存在しなかった差を作り出してしまう。
パケットサイズは古い例から写した数値ではなく、独自の制御された比較に値する。TCP MSS は TCP を調整するもので、任意の UDP データグラムには何の影響もない、だから古い文書から持ち込んだ固定の 1350 は何も測っていない。ペイロード長を意図的に変えて、受信側が何を報告するかを見よう。
一つの変数だけ変えて作業負荷は保つ
基準値が狭い帯の中で再現するようになったら、対応している変数を一つ変えて元のアプリケーション作業を再実行する。その一手だけが数値を原因に変え、設定に触れることを正当化する。より都合のよい負荷ではなく、同じ負荷を繰り返す。
合成した数値を大きくするために提案を撤回したり、認証を弱めたり、保護を切ったりしてはいけない。それらの操作はセキュリティ姿勢を変え、その変化の結果を測ることになる—トンネルの能力を測っているのではない。