wg-quick 接続時の DNS 障害：最初に設定エラーを読む

トンネルが上がり、ハンドシェイクが完了し、名前解決が止まる。ピア設定はどこも変わっていない。DNS 行はもともとピア設定の一部ではなく設定ヘルパー側の機能であり、つまり障害は WireGuard の鍵ではなくホストのリゾルバ環境に存在する。

ヘルパーが最初に出力したメッセージを読み、最後のものではなく最初を見れば、道具が無いのかサーバーに届かないのかの違いがはっきりする。

DNS 行はヘルパーの機能である

中核の設定項目が記述するのはピア、鍵、許可アドレスである。名前解決はインターフェースを立ち上げるスクリプトが上から追加するもので、実装ごとにやり方が違う。デスクトップクライアントは自前のサービスで DNS を管理することがあり、ディストリビューションのスクリプトは複数あるリゾルバ用ユーティリティの一つを呼ぶことがあり、コンテナはどちらもしないこともある。設定ファイルからは、どの経路が動いているのか分からない。

だから設定ファイルがプロトコルとして正しくても設定の途中で失敗しうるのは、失敗がプロトコルが見ることのないフックに属しているからだ。

拡張項目を中核の設定に書き、プロトコルの道具が受け付けると期待すると、逆向きに同じ混乱が起きる。二つのパーサは別のファイルを読む。

どちらが動いているかを知ることが最初の診断手順であり、それはたいてい設定ファイルではなく、打ち込んだコマンドのほうに見える。

ヘルパーが出力する最初のエラーを読む

インターフェースを前面で立ち上げ、出力を順に読む。リゾルバ用ユーティリティの欠落、フックの失敗、サーバーに届かないという三つは、同じコマンドをそれぞれ違う地点で止めるが、直し方もそれぞれ違う。

wg-quick up wg0
resolvectl status wg0
ip route get 10.66.0.1

最初のコマンドは設定の進み具合を報告し、二つ目はインターフェースが今どのサーバーを主張しているかを示し、三つ目はリゾルバのアドレスが実際にトンネル経由で届くかを示す。設定されているのに経路の無いリゾルバは設定エラーではなくタイムアウトを生むため、二つの確認は一緒に行う。状態の出力だけを読むと、自信に満ちた誤った結論になる。

設定が完了しても名前解決が失敗するなら、ヘルパーが入れたリゾルバと、以前ネットワークが使っていたリゾルバを比べる。プライベートなリゾルバにはトンネル経由の経路が要り、そのプレフィックスを覆わずに列挙する設定は、あらゆる問い合わせを待たせる。

ホストが実際に持つリゾルバ

現代の Linux ホストはローカルのスタブリゾルバを動かすことが多く、ヘルパーが入れるアドレスはアプリケーションから直接ではなく、そのスタブが使う。生成されたファイルを手で編集すると、次に再接続してヘルパーが書き直すまで動いているように見えることがある。

ディストリビューションが用意した連携を使い、リゾルバの状態は一つの部品だけに持たせる。所有者が二つあると、インターフェースのアドレスの所有者が二つあるのと同じ競合が起き、症状は変更のたびに数分だけ正しく解決するホストになる。

内部名には独自の確認が要る。公開リゾルバは一般的な閲覧を取り戻す一方で、社内の名前をすべて失敗させることがあり、これはトンネルの目的の逆である。DNS が直ったと結論する前に、意図したサーバーへ内部名を問い合わせる。

後片付けは設定と同じくらい重要である

インターフェースを下げ、リゾルバの状態をもう一度調べる。前の設定を戻すヘルパーはホストを使えるままにするが、自分のサーバーを残すヘルパーは次の障害を作り、たいていは何時間も後、トンネルがとうに消えたころに現れる。

古い状態は探せばすぐ分かる。リゾルバの一覧が、もう存在しないインターフェースのアドレスを指していることがあり、検索ドメインが今朝離れたネットワークのまま残っていることもある。どちらも次の接続を不安定にし、どちらもトンネル自身の状態出力には現れない。確認は十秒で済み、次の人の一時間を節約する。

診断と修理は分けて考える。もし 名前の検索だけでなく、あらゆる宛先が失敗するなら、疑うべきは経路と転送であり、DNS 行は注意をそらすものだ。wg-quick のマニュアルは、どの項目を扱い、どれがプロトコルに属するかを記しており、その境界こそが、こうした報告のほとんどへの答えである。