OpenVPN パケットの HMAC 認証に失敗：どの層か

同じ言葉で報告される二つの失敗だが共通点はほとんどない。一つは認証タグが検証されなかったパケット、もう一つは資格情報を拒否された人である。前者を後者として扱うと、決して問題ではなかったパスワードを探すことになる。

メッセージは層を名指ししており、有用な作業はあらゆる材料を差し替える前にどの層かを決めることだ。候補を並べて比べるのが、違いを見る最短の方法である。

一語を共有する二つの失敗

パケット認証エラーは通信の処理中に、受信したパケットのタグまたはダイジェストが受信側の計算値と一致しなかったときに発生する。アカウント拒否はログイン交換を解析した後に起こり、パケットではなく利用者を名指しする。三つ目のメッセージは受信パケットに HMAC が見つからないというもので、そこではパケットが期待された認証要素をまったく伴わずに届いているため、また別である。ログの接頭辞全体を読めば三つのどれかが分かるが、チケットにエラーを貼り付ける際、その接頭辞はたいてい最初に削除される。

この区別で修理の内容が変わる。一つはチャネル設定の一致を、もう一つはアカウント状態を、三つ目は到達したリスナーと合わないプロファイルを求める。

実行中のプロセスが実際に読み込んだものを比較する

ディスク上の正しいファイルは、それが編集される前に起動したプロセスについて何も証明しない。選択されたプロファイル、接続先のエンドポイント、変更後にサービスが再読み込みされたかどうかを確認する。別のインスタンスや別のサービスが古いファイルの想定とは違う形で待ち受けていることがあるため、エンドポイントがそのプロファイルのものかも確かめる。

同じ配布元から対応プロファイルを再エクスポートするのは、設定されていると信じているものとクライアントが実際に送るものとのずれが消えるため、安価な比較である。新しい鍵素材の生成はずっと大きな一歩であり、両端が一緒に採用して初めて役に立つ。片側だけをローカルで置き換えれば、取り除こうとした不一致を再び作ることになる。

制御チャネルとデータチャネルを比較する

二つの仕組みは接続の異なる部分を認証し、別々に設定される。2.6 オプションリファレンスに記述されているとおりで、tls-authは制御チャネルのパケットに HMAC を加え、二つのピアで逆でなければならない方向引数を取る。tls-cryptは代わりに共有鍵で制御チャネルを保護する。どちらもデータチャネル自身の完全性検査ではないが、AEAD のデータ暗号ではその検査が暗号に組み込まれているため、別個のauthダイジェストは非 AEAD 暗号のようには使われない。

つまり、動作している非 AEAD 環境からコピーしたauth行は AEAD では無関係になり得るし、AEAD 環境でもtls-auth鍵やその方向が誤っていれば制御チャネルで失敗し得る。各設定は記憶にある構成ではなく、ピアと比べること。

手放す性質と修正を比較する

パケット認証を無効にすれば警告は静まり、不一致を見つけた検査も消えるが、それはプロファイルを修理することと同じではない。どの性質を手放すのか、それなしで設計が成り立つのかを問うべきだ。

何かを変える前に両端で最初の関連イベントを読み、その後はそれが名指しする不一致だけを変える。

次の試行が証明書やログインのエラーまで進むなら、パケット層が合意して接続が次へ進んだということであり、後退ではなく前進だ。変化を生んだ設定を記録しておけば、次の人は謎ではなく説明を引き継げる。