DNS レコードは正しく、代替機も健全なのに、一部のクライアントは何時間も古いアドレスに接続し続けます。解決はするが決して応答しない名前に、数台が即座に失敗します。どちらの結果も一つの隙間から生まれます:ホスト名は、クライアントが何を引くかを変えるのであって、いつ引くかや、応答が届いたときに何を信頼するかは変えません。

症状:正しいレコード、古いトンネル

名前を保存するプロファイルは、その名前を解決し続けるクライアントではありません。大半は、設定の適用時やトンネル起動時に一度だけ解決し、セッションが終わるまでそのアドレスを使い回します。その上に長い TTL が重なるからこそ、切り替えは DNS の編集ではなく再接続を軸に計画する必要があります。

どちらの挙動も欠陥ではなく、だからこそ症状は紛らわしくなります。クライアントは以前に得た応答で動いており、サーバー側にはそれがどの応答だったかを示すものがありません。再接続を保守ウィンドウに組み込み、利用者に何が見えるかを伝えるか、そうでなければウィンドウを問い合わせ対応に費やすことになります。同じ報告が列をなすのがいつもの結果です。

誰が名前を管理し、クライアントは何を検証するか

ゾーンの管理権が移行の速さを決めます。ログインできるレジストラにレコードを置き、他に誰が変更できるかを書き留めておきます。

信頼は名前に従いません。TLS ベースのクライアントは証明書の識別情報やピン留めした名前を確認できますが、WireGuard はピアの公開鍵を認証し、ホスト名は完全に無視します。この違いが、DNS の編集で足りるのか、すべてのプロファイルに新しい指紋が必要なのかを決めます。レコードの変更が、誰も承認していないエンドポイントを認可してはなりません。

管理用と復旧用のアクセスは、公開クライアント名から切り離しておきます。ホスティングアカウントを失っても、クライアントを転送するレコードまで失うべきではありません。復旧経路は、離れるプロバイダーに依存しない場所に保管します。

各クライアントが名前を読み直すタイミング

解決のタイミングはクライアントごとの性質なので、切り替えウィンドウを約束する前に、実際に配布する実装を確認します。wg-quick はインターフェース起動時にエンドポイントを解決し、トンネルが再起動するまでそのアドレスを保持します。OpenVPN クライアントは接続時に名前を引き、再接続時に再び参照するかはそのオプション次第です。

ClientWhen it resolvesWhat it verifies
wg-quickAt interface start, cached for the sessionPeer public key, not the name
OpenVPN 2.6On connect, possibly again on reconnectCertificate identity or pinned name
Mobile clientsMay hold the answer across sleep or a network changePlatform trust store, same certificates

モバイルクライアントはいつもの驚きで、スリープやネットワーク変更をまたいで解決済みのアドレスを保持することがあるからです。A と AAAA のレコードは、代替機が両方のファミリーで応答する場合にだけ公開します。片方のファミリーで応答するアドレスは、もう片方について何も証明せず、死んだ AAAA レコードは、試行のたびにタイムアウトを追加します。対応する各クライアントの解決挙動を文書化し、人々が実際に使う端末で試験します。

再接続はほとんどのクライアントで利用者の操作であり、サーバーが強制することはできません。その手順を保守メモに入れ、起きたときに利用者に何が見えるかを一行添えます。

証拠に基づいて切り替え、それから古いエンドポイントを退役させる

切り替えの前に、代替機で各層を証明します:リスナーが応答し、ファイアウォールがポートを通し、ルートが正しく戻り、名前が新しいアドレスに解決され、既知の識別情報が受け入れられることです。接続を受け付けるリスナーは、ハンドシェイクを完了するリスナーとは同じではないので、ポートではなくハンドシェイクを試験します。現在の失効リストは設定のそばに置きます——復元したバックアップはピアリストを元のまま再作成し、すでに閉じたアクセスを再び開いてしまうからです。どの識別情報で試験したかを記録します——「動く」は誰も再現できる証拠ではないからです。

getent hosts vpn.example.com
ss -lunp | grep 51820
wg show wg0 latest-handshakes

移行中は、同じ識別情報について両方のエンドポイントの接続試行を監視します。古いアドレスに対して認証を続けるクライアントは、決して動かなかったプロファイルかキャッシュされた応答です。古いエンドポイントは日付を決めた計画で退役させます——一つの識別情報を受け付けるサービスが二つあると、扉が二つ開いたままになるからです。

切り替えの試験は、新しいエンドポイント経由のアプリケーションセッションであり、ping ではありません。そのセッションが動き、古いエンドポイントが完全な再接続サイクルで認可された試行を一件も記録しなければ、移行は完了です。

関連記事