クライアント更新後にVPNが切れる？ネゴシエーションを比較しよう

更新はプロファイルを解析しトンネルをネゴシエートするコンポーネントを置き換えます。アップグレード後の最初の失敗は特定の変更についての証拠であり、そのリリースへの判決ではありません。そのエラーをバージョンとタイムスタンプとともに保存することが、何かを再インストールする前にできる最も価値ある手順です。

こうした切断のほとんどは二つの仕組みで説明できます。それらを切り分けることが作業です。

ネゴシエーションの何が変わったのか

OpenVPNはデータチャネルの暗号を単一のディレクティブから取るのではなくネゴシエートし、そのネゴシエーションを制御するオプションの意味はリリースごとに変わってきました。古いクライアント向けに書かれたプロファイルは接続できても、その後データチャネルで合意できず、明確な設定エラーではなく切断として現れます。新しいリリースは旧来の挙動を厳格化したり廃止したりし、まだ移行していないピア向けの互換モードを同梱します。そのためアップグレードは、ファイルの中身を一切変えずに動作中のプロファイルを壊せます。

クライアント側の影響は非対称です。制御チャネルは確立し、認証は成功し、その後にトンネルが落ちます。これはプロファイルが拒否されたのではなく、ネゴシエーションの不一致を示す特徴です。

サーバーについて推測する前に、インストール済みのバージョンを読んでください。その文字列は誰にもアクセスを求めずに確認できるローカルの事実です。

プロファイルは解析できても別の意味になる

解析を通過するディレクティブが、作者の意図どおりに今も動いているとは限りません。オプションは互換性のために受け入れられて無視されたり、改名されたり、以前より狭いケースにだけ適用されたりします。何もエラーを出さないため、プロファイルは正しく見えるのに、その下の挙動は変わっています。この静けさが、こうした回帰を高くつくものにします。

どの行が実際にネゴシエーション結果の責任を負うのかを問い、いま実行しているバージョンのドキュメントと照らし合わせてください。その比較は短く、修正とロールバックの分かれ目はそこにあります。

openvpn --version | head -n 2
openvpn --show-ciphers | head -n 10
grep -nE '^(cipher|data-ciphers|ncp-|tls-)' office.ovpn

プラットフォームも同時に動いた

クライアントのリリースが単独で来ることはまれです。オペレーティングシステムの更新、いまや明示的な許可を求める権限プロンプト、あるいは端末に適用された管理ポリシーが同じ週に重なり、クライアントのせいにされる失敗を生むことがあります。モバイルプラットフォームは独自の層を加えます。アプリがシステムにトンネルを要求し、そのトンネルが何をルーティングできるかをシステムが決めるからです。

それらの変更をタイムラインに別々に記録してください。認証は成功するのにルートや名前解決が失敗する場合、興味深い段階はハンドシェイクの後であり、証明書検証を弱めてもそこには届きません。

報告のきっかけとなった事象を再試験する

簡略化した版ではなく元の順序を再現してください。最初の接続、失敗したアプリケーション、ネットワーク変更後の通常の再接続です。試験条件では立ち上がるのに再接続の経路で落ちるトンネルは直っておらず、その差はふつう本当の欠陥がどこにあるかを示します。再接続の手順を省いた報告は、まだ開いているバグを閉じてしまいます。

全面的にロールバックするのではなく、検証済みの経路で事業者のサポート対象プロファイルやベンダーの修正を入手してください。広範なダウングレードは更新がもたらしたセキュリティ修正も元に戻し、その取引が機能する接続一つに見合うことはめったにありません。