WireGuard はモバイルデータでは動くが、同じ Wi-Fi では動かない
LAN の内側からルーターのパブリックアドレスへのリクエストは、モバイルデータからのものとは別の経路を通ります。まず外側で試し、それからローカルの経路を選びます。
トンネルはモバイルデータでは立ち上がるのに、自宅では同じプロファイル、同じピアキー、途中の設定変更もないまま接続中で止まります。違いは経路にあり、LAN の内側からルーターのパブリックアドレスへ送るリクエストは、インターネットから届くリクエストと同じ旅ではありません。家庭用ゲートウェイの多くは、戻り経路を実装していないか、特定のプロトコルに限って実装しています。そのため、キーについては何も変わっていないのに、症状は壊れたキーのように見えます。キー、ポートフォワード、クライアントプロファイルに触る前に、どちらの経路が失敗したのかを確定してください。
ひとつのアドレス、二つの異なる経路
外側からは、パケットがルーターのパブリックアドレスに届き、ポートフォワード規則がそれを内部ホストの WireGuard リスナーへ渡します。内側からは、クライアントが同じパブリックアドレスにダイヤルするため、パケットはクライアントを出てルーターに届き、こんどは LAN へ向けて折り返さなければなりません。二つの経路が分かれるのはこの折り返しの地点で、ルーターは同じインターフェースから出て再び同じインターフェースに入るフローを変換しなければならないからです。多くの実装は変換せずにそのフローを落とし、クライアントは送られなかったハンドシェイクを待ち続けます。
この挙動は通常 NAT ループバックまたはヘアピンと呼ばれ、WireGuard ではなくルーター側の性質で、RFC 4787 はゲートウェイが対応してもしなくてもよい変換のケースを定めています。WireGuard 自身は、自分のインターフェースに届いたパケットしか見ないため、経路について何の意見も持ちません。ルーターがフローを落とすと、デーモンには何も届かず、クライアントはハンドシェイクのタイムアウトを報告し、サーバーログは空のままになります。したがって空のログは、パケットがどこで止まったかを示す手がかりであり、サーバーが落ちている証拠ではありません。再インストールしても何も変わらない理由もここにあります。
逆も同じくらい重要で、LAN のアドレスからのハンドシェイク試行を示すサーバーログは、パケットが届いて経路が正常であることの証明であり、調査はキーと許可アドレスへ移ります。ログは、見たかったものではなく、それが証明するものとして読んでください。
何かを変える前に再現する
同じ端末と同じプロファイルで、許可された外部ネットワークから試し、次に何も変えずに LAN の内側で同じ試験を繰り返します。外側で完了したハンドシェイクと、内側で端末から出ないクライアントは、推測ではなくその状態を再現します。両方の試行が同じプロファイルを使わなければ、比較は何も証明しません。
次に、この端末でエンドポイント名が何に解決されるかを見ます。次の三つのコマンドは、クライアントが実際にどのアドレスへダイヤルしたかも示します：
wg show wg0 endpoints
dig +short vpn.example.net A
resolvectl query vpn.example.net最初のコマンドは、インターフェースが現在使っているエンドポイントを報告し、残りの二つは、このマシンで名前が何に解決されるかを示します。サーバーと同じネットワークにいながらパブリックアドレスへダイヤルするクライアントは、ヘアピンの経路を通っています。LAN のアドレスへダイヤルするクライアントはそうではなく、そちらでの失敗は別の調査に属します。この区別が、次の節が当てはまるかどうかを決めます。
近くのサーバーへ到達するための対応方法
もっともきれいなのはスプリットホライズンの答えで、パブリック名が、インターネット向けにはパブリックアドレスに、内側のクライアント向けにはサーバーの LAN アドレスに解決されます。プロファイルはエンドポイント名を一つ保ち、リゾルバーが経路を選びます。これには内部 DNS 応答の制御が必要で、家庭用ルーターはたいていそれを提供し、組織は意図的に用意できます。その制御がなければ、残る選択肢はルーターの機能か二つ目のプロファイルです。
ルーターの機能はリフレクションで、ゲートウェイが内側から外側へのフローを変換し、再び内側へ送り返します。機能する場所ではクライアント側の変更は不要で、機能しない場所ではどのクライアント設定も救いません。ルーターの機能一覧を読むのではなく、内側からの試行中にサーバーログを見て試してください。
プロファイルをプライベートアドレスに書き換えるのは診断であって、設計ではありません。サーバーが LAN で応答することを証明しますが、ノートパソコンが家を出た瞬間に同じプロファイルは壊れます。
| Approach | What it depends on | Where it fails |
|---|---|---|
| Split-horizon name | Control of the internal DNS answer | Clients that resolve through a server outside the zone |
| Router reflection | Gateway support for hairpin translation | Routers that drop the flow silently |
| Private address in the profile | Nothing beyond the LAN | Every network except the one at home |
家の外でもプロファイルを使えるままにしておく
どの経路を選んでも、身元の確認には手を触れないでください。エンドポイントのアドレスはピアの身元ではなく、アドレスが変わったからといって、たまたま応答する無関係な公開鍵を受け入れる理由にはなりません。WireGuard は鍵で認証するので、間違ったホストはハンドシェイクに失敗し、予期しない何かへのアクセスを与えることはありません。
パブリックアドレスが移ると、名前を役に立たせ続けるのはダイナミック DNS であり、変更がどれだけ早く反映されるかはクライアントの更新動作が決めます。アドレス変更のあとは、LAN の場合では検証できないのだから、外側からそれを試してください。レコードの寿命を過ぎても古い応答をキャッシュし続けるリゾルバーに注意してください。前のアドレスを指したままの名前は、落ちたサーバーとまったく同じに見えます。
プロファイルが使う名前と、境界の両側でそれが何に解決されるかを書き留めてください。誰も記録していないルーター機能に依存するプロファイルは、次のファームウェア更新を待つサポート案件です。そのメモは、内側での失敗が既知のヘアピンのケースなのか、新しい何かなのかを次の人に伝えるものでもあります。