vpnc の弱い暗号エラー：ゲートウェイのポリシーかデスクトップの修正か

古い vpnc 接続が立ち上がらないとき、二つの修正は同じくらい手早く見えます。古い弱暗号フラグを渡すか、それを代わりに追加するラッパースクリプトを入れるかであり、両者は等価ではありません。一方は一つのプロファイルのポリシーを変え、もう一方はその経路を呼ぶすべてのプログラムの挙動を変えるからです。第一の問いはゲートウェイがまだ弱い提案を出しているかどうか、第二は誰がそれを受け入れてよいかであり、残りはすべてこの二つの答えから導かれます。

影響範囲が大きく異なる二つの修正

プロファイル単位の変更は、一つの接続、一人の所有者、一つの有効期限に触れます。インストール済みバイナリの置き換えは、同僚がまったく別のゲートウェイプロファイルに使っているデスクトップアプレットも含め、マシン上のすべてのフロントエンドに触れます。ラッパーは、半年後にホストをデバッグする人からも変更を隠します。

パッケージ検証が最初の犠牲です。/usr/sbin/vpnc にあるファイルがパッケージと一致しなくなると、日常のセキュリティ更新が調査に変わります。するとアップグレードは、パッケージマネージャーが変更済みファイルをどう扱うかに応じて、ラッパーを黙って上書きするか、適用を拒否します。どちらの結果も接続ログには現れず、だからこそラッパー方式は最初の事故まで魅力的に見えますが、プロファイルの一行は、誰も置き換えたことを覚えていないバイナリよりはるかに見つけやすく、削除しやすいのです。

非推奨のスイッチが実際にすること

vpnc のマニュアル は単一 DES オプションを弱暗号設定の推奨に伴い非推奨とし、データ通信の暗号化をまったく許可しない別のオプションを記載しています。これらは異なる結果を伴う異なる譲歩です。どちらも、現代のゲートウェイに、もはや提供していないものを交渉させることはありません。

修正を選ぶ前に失敗の段階を読みます。拒否された提案と拒否されたパスワードは、似たフロントエンドのメッセージを出しますが、証拠はまったく異なります。

限定的な例外をどこに置くか

組織が限られた期間だけ旧式のピアを意図的に受け入れるなら、例外はそのピアのプロファイルに置き、所有者、レビュー日、サポートされるプロトコルへの移行経路を添えます。それをグローバルな経路から外しておくことが、限定的と呼ぶ所以です。

ゲートウェイの所有者に、ピアがまだ提案するアルゴリズムと、それを置き換えるものを確認してもらいます。クライアントのフラグは、サーバーがもう送らない提案を修復できず、誰も計画しなかったサーバー移行は回避策より長く生き残ります。レビュー日を例外と同じチケットに入れて、譲歩が恒久化せず期限切れになるようにします。

交渉を確認し、緑のアイコンだけを見ない

ダイアログの雰囲気ではなく、段階を特定する証拠を集めます。以下のコマンドは読み取り専用で、最初の二つは実際にどの設定とバージョンが使われているかを示します。

vpnc --version
vpnc --print-config /etc/vpnc/legacy.conf
dpkg -V vpnc
grep -n -E 'weak|1des|no-encryption' /etc/vpnc/legacy.conf

三番目のコマンドは、パッケージと一致しなくなったファイルを報告し、忘れられたラッパーはこうして名乗り出ます。四番目はプロファイルが抱える譲歩を示すので、例外がコピーされたファイルを介して二つ目のプロファイルへ静かに広がることはありません。変更の前と後に両方を実行し、出力はチャットウィンドウではなく接続プロファイルと一緒に保管します。

デバッグ出力は誰かが読むまでチケットの外に置きます。マニュアルは、最高レベルのデバッグがパスワードを含む認証データを吐き出すと警告しているからです。受け入れ基準は、クライアントとゲートウェイの間の承認されたサポート対象の合意であり、ようやく緑になるメニュー項目ではありません。ピアが壊れたアルゴリズムしか提供しないなら、正直な結果は終了日付きの例外か代替プロトコルであり、その判断はゲートウェイを所有する人に属し、判断を記録することが、管理された例外と偶発的なポリシー変更の違いです。