FRITZ!Box の VPN は接続するのに何も応答しない：WireGuard か IPSec か

トンネルは接続済みと報告し、アイコンは緑なのに、家庭内 LAN 上の何も応答しない。これは FRITZ!Box のリモートアクセスで最も多い不満であり、ほぼ決してトンネル自体が原因ではない。誤っているのはアドレス設計、サブネットの識別、あるいはクライアントのルートテーブルだ。どれを最終的に追うかは、WireGuard を選んだのか、より古い IPSec Fernzugang を選んだのかで変わり、まず自分が実際にどちらを設定したのかを把握してから始めよう。

トンネルは上がるのに LAN は沈黙したまま

確立したトンネルは、鍵とエンドポイントが正しいことの証明になる。しかし、次のことまでは証明しない。クライアントが、ボックスから経路を向けられる住所を受け取ったこと、あるいはクライアントがどのプレフィックスがトンネルに属するのかを知っていることだ。これは二つの別々の成功であり、印刷機に届くのは二つ目だけである。

まずクライアントのアドレスを、次にそのルートテーブルを確認する。

割り当てられたアドレスが LAN のサブネットの外にあれば、ボックスには戻す経路がない。DHCP の範囲の内側にあれば、ボックスが同じアドレスを家庭内の機器に渡してしまうことがある。どちらも、接続はするが LAN が応答しないトンネルを生む。

各オプションが実際に設定するもの

IPSec のオプションは、一人の利用者向けの設定ファイルを生成し、事前共有鍵とアドレス指定を含める。同じプロファイルを話すクライアントにインポートするが、Windows では通常それがベンダーのツールを意味し、内蔵クライアントではない。WireGuard のオプションは、一つの機器向けに、鍵ペア、トンネル内のアドレス、エンドポイントというピアを生成する。

この違いが運用の形を決める。WireGuard の機器はそれぞれ固有の鍵を持つ独立したピアなので、紛失した端末の失効は一つのピアを削除するだけで済み、他は動き続ける。IPSec は共有秘密か利用者の設定を変えて失効させるため、粗く、それを使うすべての機器に影響する。

どちらの選択肢も廃れていない。遠端で WireGuard を動かせない場所では、IPSec の経路が今も支持される。

死んだトンネルを生む IPSec の項目

四つの値が LAN と一致していなければならず、そのうち三つは壊れたトンネルのように見える形で失敗する。

人を捕まえるのはネットワークアドレスのほうで、サブネットは最初のアドレスで識別され、それは通常ゼロで終わる。そこにホストアドレスを入れると、まったくもっともらしく見えて決して接続しない設定ができあがる。DHCP の範囲が重要なのは別の理由で、トンネルのクライアントは普通その上側で割り当てられるため、サブネット全体を食う範囲では配る余地が残らない。

サブネットの重複も定番だ。参加しようとしている遠隔の LAN が、自分が座っている LAN と同じプレフィックスを使っていれば、経路制御は両者を見分けられず、片側の採番をやり直すのが唯一の本当の解決になる。クライアント側の設定をいくら足しても解決しない。

WireGuard が違う形で失敗する理由

WireGuard には打ち間違える事前共有鍵がないので、失敗はピアの定義のまわりに集まる。LAN のプレフィックスを落とした許可 IP の一覧は、クライアントが LAN 宛ての通信をそこへ送らないため、何も運ばないトンネルを作る。どちらかの側で古い公開鍵を使えば、決して完了しないハンドシェイクになる。エンドポイントの欠落や誤ったポートは、エラーではなく沈黙を生む。

ファイルを再インポートして願うのではなく、両側を項目ごとに突き合わせる。

唯一の共通の失敗はサブネットの衝突だ。WireGuard は自分のローカルと重なるネットワークへ平気でトンネルを張り、そのあとどちらの同一プレフィックスが勝つかをルートテーブルが決める。

外から証明し、それから戻る道を確保する

モバイル回線から試し、LAN の内側からは決して試さない——内側からはトンネルがまったく関与しない経路を試しているだけだからだ。有効にする前に各オプションが使うポートを記録し、そのポートをボックスへ転送する。

生成したファイルは、トンネルなしで到達できる場所に置き、ついでにボックスの外部名も控えておく。

外から一度も試していない設定は計画であって、動くリモートアクセスの経路ではない。LAN のホストは、DNS の失敗が経路の失敗と取り違えられないよう、名前ではなくアドレスで試すこと。