ログのP_CONTROL_HARD_RESET_CLIENT_V2はエラーなのか

この行は数秒ごとに繰り返され、すべての原因のように見える。control hard reset という名のパケットが、どこにも到達しないクライアントから届く。これはエラーではない。新しいセッションの最初のメッセージであり、繰り返しはその先で別の何かが失敗している症状である。ラベルが何を言っているのかと、その後に接続が何をしたのかを切り分けることが、診断のすべてだ。

オペコードはプロトコル内の位置を示す

OpenVPN は複数種のパケットを一つのソケット上で多重化し、オペコードは受信側にどの種類かを伝える。hard-resetパケットはセッションを開き、制御パケットはハンドシェイクの材料を運び、確認応答は受信を確認し、データパケットはトンネルのペイロードを運ぶ。先頭バイトを読めば、そのやり取りのどこにパケットが属するかが分かり、上流のパケット定義 が各系列を明示している。

言えるのはそこまでだ。初期クライアントリセットと記されたパケットは、そのパケットが観測点に届いたこと、相手がセッションを始めたいことを証明する。クライアントがあなたの証明書を信頼したこと、認証情報が受理されたこと、データチャネルが使えるようになったことは証明しない。

V2という接尾辞はそのパケット系列のプロトコル世代の印であり、製品のバージョンでも、インストールする設定でもない。名前にトンネルのリセット、サービスの再起動、キャッシュの消去といった意味は含まれていない。

その瞬間にクライアントが実際にしていること

クライアントはセッション識別子を開き、両端が以降の制御トラフィックをそれに紐づける。制御チャネル保護が設定されていれば、その最初のパケットはすでにHMACを運び、受信側は残りのやり取りに手間をかける価値があるかを判断できる。検証できない受信側はパケットを黙って捨てる。だからこそ、誤った共有鍵はクライアントが虚空に向かって話しているように見える。

利用者に見える変化はまだ何も起きていない。証明書は検証されておらず、ユーザー名も提示されておらず、トンネルアドレスも割り当てられていない。リセットはハンドシェイクの前置きであり、この時点で接続を判断するのは早すぎる。

待機中の再接続ループで興味深いのは間隔だ。一定周期で再試行しても進展しないクライアントは、たいてい進む前に拒否されており、理由はパケット名ではなく相手側のログにある。

リセットの後ろに隠れている本当の失敗

二つのログを並べて読み、リセットではない最初のイベントを探す。クライアント側では証明書検証の失敗が具体的な理由とともに記録される。期限切れ、名前の不一致、未知の発行者である。サーバー側では認証情報の拒否が独自の理由を伴う認証失敗として記録される。どちらも、サーバーが新しい試行を繰り返し眺めるだけの記録よりはるかに具体的だ。

各ログを個別に読むのではなく、一つの試行をタイムスタンプで突き合わせる。同じ失敗が両側に、異なる表現と異なる深刻度で現れるからだ。諦めた側はたいてい理由を述べている。

どちらも拒否を報告せず、それでもやり取りが止まるなら、境界は信頼ではなく到達性だ。戻り方向を落とすファイアウォール、対応付けが失効するネットワークアドレス変換装置、大きなハンドシェイクパケットを落とすMTUの問題は、いずれも認証エラーを一切出さずに停止したやり取りを生む。

grep -nE 'VERIFY|AUTH_FAILED|TLS Error|SIGUSR1' /var/log/openvpn*.log

その検索はそれ自体が診断ではないが、プロトコルの語彙から実際の障害分類へ一歩で移ることができる。

検証を外すのが間違った反射である理由

リセットが現れ続けるとき、最も速そうに見える対処は証明書検証を切るか制御チャネル保護を外して何かをつなぐことだ。それは診断できる失敗を診断できない失敗に交換し、拒否するために作られた相手を受け入れる状態で配備を放置する。

代わりに、実際に失敗した境界を変える。信頼の問題は認証局とそれを参照するプロファイルに属する。時刻の問題は時計に属する。認証情報の問題はそれを拒否した認証バックエンドに属し、到達できない相手は二つのホストの間の経路に属する。

オペコードがサポートの会話で役立つのは一点だけだ。相手が試すところまで進んだことを教えてくれる。その後に何が起きたかが知るべきことであり、最初の具体的な拒否を記録したログに書かれている。そこから始めれば、リセットの行は原因のように見えなくなり、タイムスタンプのように見え始める。