サーバーの DNS レコードが移動した後、トンネルはトラフィックを流さなくなりましたが、同じマシンから名前は正しく解決されます。この二つの事実は矛盾していません。WireGuard の設定はエンドポイントを保持し、ツールはその設定を適用する瞬間に名前を解決するため、稼働中のインターフェースは何時間も前に取得したアドレスを使い続けられます。鍵を交換したりトンネルの範囲に触れたりする前に、インターフェースが何を使っているかを確認してください。

名前は一度だけ解決され、継続的には解決されない

WireGuard の基本設定はエンドポイントをアドレスとポートとして受け取り、インターフェースを立ち上げるツールがその時点でホスト名を解決します。基本プロトコルには DNS を定期的に問い合わせる仕組みはなく、クライアントアプリケーションが独自の更新動作を上に追加することがあります。解決されたアドレス、アドレスファミリー、ポートを名前の横に記録すれば、その隙間が見えます。その記録がなければ、インターフェースが別の場所と通信している間も設定は正しく見えます。

真正な自動更新が一つだけあり、DNS 更新に似ていてそうではないので知っておく価値があります。正しく認証されたトラフィックが新しいアドレスから届くと、ピアのエンドポイントは移動することがあり、これは名前解決ではなくローミングです。ピアに追従するため、古いエンドポイントが一度も接続したことのない無関係な新しいサーバーを発見することはできません。

レコードと使用中のアドレスを比較する

クライアントが使うリゾルバーで文書化された名前を問い合わせ、次にインターフェースがどのエンドポイントを保持しているかを尋ねます:この二つの答えが、このページの残りを決める比較です。

dig +short vpn.example.net
wg show wg0 endpoints
wg show wg0 latest-handshakes

この行が使う show サブコマンドはwg(8) のマニュアルに記載されています。アドレスだけでなくアドレスファミリーも比較してください。IPv6 の項目を得たレコードは、IPv4 アドレスが変わったレコードとは別の比較になるからです。エンドポイントがレコードと異なるなら、インターフェースは古い情報で動いており、名前が問題だったことはありません。両者が一致していてトンネルが依然として失敗するなら、プロファイルではなくリスナーとルールへ進んでください。

ハンドシェイクのタイムスタンプがそのブロックにあるのは、エンドポイントだけではピアに到達できるか分からないからです。正しいエンドポイントの隣にある古いタイムスタンプは経路の問題であり、解決の問題ではなく、この区別が次に触る場所を変えます。

インターフェースのマネージャー経由で再起動する

エンドポイントが古いと確認できたら、インターフェースを所有する仕組みを通じて更新してください。稼働中の設定を直接編集するのではなく、wg-quick で起動したインターフェースなら停止して起動、systemd ユニットなら再起動、マネージャーが所有するインターフェースならそのマネージャーでの変更です——実行時の編集は次回の適用で上書きされるためです:

wg-quick down wg0 && wg-quick up wg0
systemctl restart wg-quick@wg0

次に、代替のリスナーとその身元が意図したサービスであることを確認してください。DNS の移動は身元の変更ではないので、検証していない鍵を信頼する機会にしてはいけません。インターフェースが新しいアドレスを報告してもハンドシェイクが起きないなら、障害は新しいネットワーク経路かリスナーへ移っており、それは同じ障害の再発ではなく前進です。

まずハンドシェイク、次にデータ経路

チェックリストを選ぶ前に、二つの結果を分けてください。アプリケーションが失敗する状況でハンドシェイクが成功するのはデータ経路の問題です。ルート、許可されたプレフィックス、トンネル内の DNS などです。ハンドシェイクがまったく起きないのは、エンドポイントでの到達性や身元の問題です。二つを混ぜると、誰も再現できない報告書と、無関係な三つの編集を含む変更履歴ができあがります。

名前、解決されたアドレス、使用中のエンドポイント、ハンドシェイクが完了したかどうかを記録してください。この四つの事実が、この障害が繰り返し問いかける疑問に答え、次の発生を二分間の確認に変えます。名前の保守とクライアントの導入は別の作業のままです。レコードを直しても導入は行われず、インターフェースを再起動しても依然として誤ったレコードは直りません。

関連記事