プロファイルの三行はどれも圧縮を無効にするように見えますが、実際にそうしているのは一行だけです。違いが重要になるのは、黙らせたい警告が症状にすぎず、方針こそが相手側がまだ圧縮できるかどうかを決めるからです。変更後に各設定が何を許すかという一つの軸で比較すれば、曖昧さの大半は消えます。どれを選ぶかは、移行中か定着後かによって変わります。

設定ファイルでは似て見える三つの方針

各設定は別の問いに答えます。allow-compression no は圧縮されたペイロードを即座に拒否し、allow-compression asym は届くものを展開するだけで出ていくものは決して圧縮せず、古い comp-lzo no は相手側の push で圧縮を有効にする余地を残します。サーバーが上書きできない方針は最初の一つだけです。

名前が似すぎてレビュー担当者を誤らせるため、選ぶ前に三つを表に書き出してください。そのうち二つは受信パケットに対して今も展開コードを実行しており、セキュリティの議論はまさにその点を扱っています。三つ目は方向を制限するのではなく能力そのものを取り除きます。変更記録に圧縮が無効と書かれているなら、その文を満たす行はちょうど一つです。

調査の発端になった警告は目的ではありません。寛容な方針を残したまま警告を黙らせると、きれいなログと変わらない露出が得られるだけです。

SettingWhat it permitsWhen it is the right answer
allow-compression noNo compressed payloads, and no compression framing under offloadBoth ends can be changed now
allow-compression asymDecompress inbound onlyA dated migration while peers catch up
comp-lzo noOff locally, still pushable by a peerLegacy compatibility you can still justify

古い LZO 設定における no の意味

非推奨の LZO 設定では、no はローカル側の圧縮を無効にしますが、方針が許す場所で相手側が有効にすることを禁じません。この非対称性のため、プロファイルを厳密な拒否へ移すと、単一サーバーの実験室テストでは決して明らかにならない形で挙動が変わります。

セキュリティ上の懸念は絶対ではなく条件付きです。攻撃者が選んだ平文を秘密の隣に置き、圧縮が暗号化トラフィックのサイズをどう変えるかを観察できるとき、情報の経路が存在します。LZO から LZ4 への切り替えはアルゴリズムとフレーミングを変えるだけで、その仕組みは変わりません。

つまり正直な枠組みは、いま何が推奨されているかではなく、何を許す用意があるかに関わります。厳密な拒否だけが相手側の協力に依存しない選択肢です。

受信のみは移行状態であり、到達点ではありません

非対称な受け入れは、一方が圧縮をやめても他方がまだそれを期待しているために存在します。それは橋であり、橋には終了日と所有者が必要です。方針がまさにそのトラフィックを許しているため、どのピアがまだ圧縮トラフィックを送っているかを記録してください。その一覧がなければ、移行状態は惰性で恒久的な設定になります。

クライアントは自分のファイルを編集しても、互換性のないサーバーに古いフレーミングを放棄させられません。push の方向はサーバーで決まるので、移行が実際に終わるのはサーバー設定とクライアントごとのファイルです。

スタブモードはフレーミングを保ちながら圧縮処理そのものを省きますが、古い設定の直接の代替ではありません。どれかに決める前に、まだ支援が必要な最も古いピアに対して試してください。

データチャネルの offload が答えを変える場所

データチャネルの offload はパケット処理をカーネルへ移し、圧縮フレーミングに依存するプロファイルはその経路に合わないことがあります。失敗はいつも大きな音を立てるわけではなく、クライアントは接続し、その後テストしたトンネルとは違う振る舞いをします。

接続が成功するかどうかだけでなく、変更の前後でどちらの実装が有効か確認してください。offload 経路が圧縮フレーミングを拒否する場合、厳密な拒否の方針と offload 配備は一致しますが、寛容な方針と offload 配備は一致しません。

正しく見えるファイルが黙って使われていないファイルになるのはまさにそこなので、その組み合わせは独自のテストに値します。ネゴシエートされた状態は、ログに見えるのがどちらか一方だけである以上、プロファイルに記録した意図と比べるべきです。

方針を選び、ネゴシエート結果を検証する

両端を変えられるなら厳密な拒否を、まだなら非対称な受け入れを、完全な圧縮は露出が許容される理由を説明できるときにだけ選んでください。そしてファイルの記述ではなく、ネゴシエートされた内容を検証します。静かなログは、配備しようとした方針と一致するときだけ証拠になります。

決定は適用対象のプロファイルの隣に、日付とまだ除外されているピアとともに残してください。半年たつと、そのメモが意図的な例外と日付を誰も言えない事故との差になります。プロファイルと同じリポジトリに書けば、次の編集者が指示より先に理由を見られます。

関連記事