サーバーのパブリックアドレスへの SSH が動かなくなる一方でトンネルが上がる場合、サーバーが接続を拒否しているように見えます。Windows ではより可能性が高い原因はローカル側であり、フルトンネルの AllowedIPs が /0 だと、トンネル自身の通信とごくわずかなものだけを許可する制限的なファイアウォール規則が有効になります。そのアドレスに届く暗号化パケットは、同じアドレスへの別の TCP 接続が出てよいかどうかについては何も語りません。

ピア一覧に触れる前に、エンドポイントのパブリックアドレスとその内側のトンネルアドレスを切り分けてください。AllowedIPs を編集して直そうとする試みはほとんどが、ルートを正しくするのではなくポリシーを弱くします。

ルーティングの許可とファイアウォールの許可は別物

ルートはパケットをどこへ送るかを決め、ファイアウォール規則はそれを送ってよいかどうかを決めます。したがってエンドポイントのパブリック IP にルートを足しても、フィルターが依然として遮断できる経路ができるだけで、この症状が生む混乱はまさにそこにあります。Windows ではフィルターは実装の一部であり追加物ではないため、どのルート項目もそれを変えません。この二つの判断は他の環境でも別々ですが、既定値は異なります。

そのためエンドポイントへの traceroute は成功しても SSH の試行は失敗することがあります。前者は例外を持つサービスが運び、後者は運びません。

Windows で /0 が何をするか

許可アドレスが IPv4 空間全体を覆うピアが一つだけあると、WireGuard for Windows は制限的なファイアウォール姿勢を適用し、そうしなければトンネルの外へ出る通信を遮断します。トンネルサービス自身の通信が許可されるのは、そうでなければ VPN が機能しないからです。同じパブリックアドレスへの別のアプリケーションにそのような許可が与えられないのは、例外がアドレスではなく通信に属するからです。 Windows のネットワークに関する覚書 は、この挙動とエディター内の関連する設定について説明しています。

これらの規則が kill switch という言葉の背後にある仕組みです。有効になるのは構成の形によってであり、そう名付けられたチェックボックスによるものではありません。

例外は保護モデルを変える

/0 を二つの半既定プレフィックスに置き換えることは、制限的な意味論なしに広いルーティングを保つための文書化された方法であり、短い表記ではなく別の保護モデルです。許可プレフィックスからエンドポイントのアドレスを差し引くのはもう一つの一般的な回避策で、一覧を長くし、どの規則が有効になるかも変えます。どちらも局所的な効果にとどまる局所的な編集ではありません。どちらも、直していた接続だけでなく、マシン上のすべてのフローの境界を動かします。

直接のパブリック SSH が本当に必要な場合、プロファイルの所有者は外側のルートとそのファイアウォール許可の両方を設計し、トンネルが落ちたときに無関係な通信がどうなるかを決める必要があります。IPv4 と IPv6 を別々に確認することも、規則がファミリーごとに表現されるため、その一部です。管理セッションを一つ救うために加えた広いバイパスは、通常そのセッション以上のものを露出します。

選んだ管理経路をテストする

まず管理をトンネルの内側に通すのか外側に通すのかを決め、そのうえで両方同時ではなくその選択だけをテストします。以下のコマンドはクライアントのアドレス、ピアの状態、各ターゲットへの接続を確認します。トンネルが上がっている間に Windows クライアントから実行してください。

ipconfig | findstr /i "WireGuard IPv4"
wg show
ssh -v [email protected]
Test-NetConnection 203.0.113.9 -Port 22

内側のアドレスへの SSH が成功すれば、トンネルが管理通信を運んでおり、サーバー自身のファイアウォールがピアの範囲からそれを受け入れていることが分かります。両方のターゲットで失敗する場合は、Windows のルーティングではなくサーバー側か鍵の問題です。内側が動いて外側が動かないなら、 ローカルのファイアウォール姿勢 が設計どおりに働いているだけです。プロファイルを編集する前に、三つの結果をこの順で読んでください。

管理経路、使用したアドレス、トンネルが落ちているときの挙動を記録してください。その記録が、次の人が五分を節約するためにバイパスを広げるのを止めます。

関連記事