ハンドシェイクは成功、インターネットは不通: Windows 11 で最初に直すべきこと

Windows 11 では、ハンドシェイクが新しく成立していてもブラウザーが何も開けない場面がよくあります。ハンドシェイクはピアとの UDP のやり取りが完了したことだけを示します。Windows が入れた経路、使っているリゾルバー、そして 出口が何かを転送しているかどうかについては何も語りません。

四つの条件で、どの層が失敗したかが決まります。順番に確かめれば数分で済みますが、鍵を書き直すのは時間がかかるうえ何も変わりません。

鍵に触る前に層を決める

三つの宛先をこの順で確かめます。まずトンネル側のアドレス、次に番号で指定する公開 IP、最後にホスト名です。どこで連鎖が切れるかが層の名前になります。最初の段階で失敗すれば経路、二番目なら転送か NAT、三番目なら名前解決です。

この順序が方法のすべてです。DNS の不具合を壊れたトンネルと誤診するのを防ぎますが、それがここで最も多い誤りです。

wg show
Find-NetRoute -RemoteIPAddress 1.1.1.1
Resolve-DnsName example.com -Server 1.1.1.1

ハンドシェイク時刻が空の場合

ハンドシェイク時刻が空なら、暗号化されたやり取りは一度も完了していません。したがって不具合は経路より手前にあります。まずエンドポイントのアドレスとポート、次にネットワークが UDP を絞り込んでいないかを見ます。WireGuard の通信を落とすホスティング事業者はまさにこれを起こしますし、古いプロファイルからエンドポイントをコピーしたクライアントも同じです。

出ていくバイトはあるのに入ってくるバイトが無い場合は別です。これは NAT か、通信を誤った場所へ戻すファイアウォールを示します。

経路が物理アダプターに負ける場合

フルトンネルでは、ピアのセクションが使う予定の宛先を覆っている必要があります。Windows は全宛先の規則を設定していても、物理アダプターの既定経路を残すことがあります。全宛先の規則を 0.0.0.0/1 と 128.0.0.0/1 に分割すると、検索に勝つより具体的な二つのプレフィックスができます。この分割は文書化された回避策であり、好みではありません。

route print か公開アドレスの検索で確認します。選ばれるインターフェースはトンネルのアダプターであるべきです。物理側がまだ勝つなら、サーバーに触る前にピアの範囲を直します。

アドレスは通り名前が通らない場合

WireGuard は IP パケットを運ぶだけで、DNS については何も決めません。インターフェースのセクションに DNS = の行を置くか、Windows 側でアダプターを設定します。それが無いと、アドレスへの ping は通るのにホスト名はすべて失敗し、利用者はこれをインターネット不通として報告します。

接続後に Windows が実際に使うサーバーを確認します。物理アダプターに残ったリゾルバーは、一部の名前は解決し他は解決しないという部分的な失敗を説明します。二つ目を上に足すのではなく、それを消します。

Windows マシンが出口の場合

Internet Connection Sharing は有効にするとアドレス指定を書き換えるため、共有アダプターが別の範囲へ移ることがあります。元のアドレスを指したままのクライアントは、それで動かなくなります。レジストリ値 ScopeAddress と StandaloneDHCPAddress がその範囲を制御し、再起動後に設定が戻ることがあります。

Windows 固有の衝突はもう二つ見ておく価値があります。Routing and Remote Access サービスがトンネルを妨げることがあります。誤ったアーキテクチャ向けに作られたインストーラーは、アーキテクチャに一切触れないメッセージで失敗します。

テストが名指しした層を直し、同じ三つの宛先をもう一度実行します。ホスト名のテストを直す一方でトンネルのアドレスを壊す変更は、誤った層に適用されています。