ShadowrocketのWireGuard設定方法｜PrivateKey・Endpoint・AllowedIPsを解説

1. 追加前にInterfaceとPeerを区別する

ShadowrocketのWireGuard設定は、サーバーアドレスだけでは完了しません。一般的なWireGuard設定は[Interface]と[Peer]に分かれます。前者には端末自身の鍵とトンネルアドレス、後者には接続先の公開鍵、Endpoint、許可するアドレス範囲を設定します。2つの項目の鍵を取り違えると、アドレスとポートが正しくても認証できません。

この記事は、利用するサービスまたは自分で構築した接続先と、その設定情報をすでにお持ちであることを前提としています。追加前に、必要な項目がそろい、互いに対応していることを確認してください。Endpointだけでは設定は完成せず、端末自身のPrivateKeyと接続先のPublicKeyも必要です。Shadowrocketは買い切りの商用アプリです。アプリの購入に通信サービスの利用料金は含まれず、購入してもWireGuardの接続先が自動で用意されるわけではありません。

2. HomeからWireGuardを追加し、元の設定を確認する

手動で追加するには、Home → 右上の「+」→ Type → WireGuardの順に進みます。プロトコルを選んでから入力し、WireGuardのパラメータを別のプロトコルのフォームに入力しないようにしてください。以下ではWireGuard設定ファイルの標準的な項目名に沿って説明します。アプリのフォームではEndpointがアドレスとポートに分かれている場合があります。項目の表示は現在のアプリに従ってください。

1. 設定情報を整理する

   元の設定を保存し、InterfaceのPrivateKeyとAddress、PeerのPublicKey、Endpoint、AllowedIPsをそれぞれ確認します。PresharedKeyがある場合も記録しますが、公開メモやスクリーンショットには載せないでください。

2. プロトコルを選ぶ

   Home →「+」→ Type → WireGuardの順に進みます。パラメータを入力する前にTypeを確認してください。設定ファイル全体をサーバーアドレス欄に貼り付けないでください。

3. Endpointを入力する

   Endpointのホスト名とポートをそれぞれ対応する欄に入力します。たとえば192.0.2.10:51820の場合、ホストは192.0.2.10、ポートは51820です。このドキュメントの例示用アドレスは、実際の接続先として使用できません。

4. 鍵とアドレスを入力する

   端末自身のPrivateKey、接続先のPublicKey、割り当て済みのAddressを入力し、元の設定に従ってAllowedIPsと任意のパラメータを設定します。鍵に引用符や項目名、改行を含めないでください。

5. 保存して接続を確認する

   保存後、Homeに戻って設定を選択し、Global Routingを確認してから接続を開始します。初回にシステムのVPN構成追加の許可が表示された場合は、対象アプリを確認して画面の案内に従ってください。アクセスが許可されていることが分かっている宛先にリクエストを送り、接続結果を確認します。

3. PrivateKeyとPublicKey：長さが正しくても、組み合わせが正しいとは限らない

PrivateKeyは端末自身の認証に使います。対応する端末側のPublicKeyは、接続先のPeer設定に登録する必要があります。Shadowrocketに入力するPeerのPublicKeyは、接続先のものです。双方が相手に秘密鍵を渡すのではなく、それぞれが自分の秘密鍵を保持し、相手の公開鍵を使って接続先を識別します。

上記の長さは、明らかなコピー時の誤りを確認するための目安です。鍵が有効で、同じ接続に対応していることを証明するものではありません。末尾の=はBase64のパディングである可能性があるため、むやみに削除しないでください。チャットの書式設定で加わった空白、引用符、改行は鍵に含まれません。見た目が似た文字を使って、欠けた内容を手入力で補うことも避けてください。

• 端末自身の公開鍵を誤って使用：PeerのPublicKeyに端末自身の公開鍵を入力した場合は、接続を何度も作り直すのではなく、元の設定から接続先の公開鍵を確認してください。
• 端末自身の秘密鍵だけを変更：新しいPrivateKeyからは別の端末側PublicKeyが生成されるため、接続先にも新しい公開鍵を登録する必要があります。更新されていないと、鍵が一致しません。
• 事前共有鍵の入力漏れ：元の設定でPresharedKeyが有効な場合、双方の公開鍵と秘密鍵だけでは不十分です。値が一致しない場合も認証できません。
• 複数の端末で同じ接続情報を使用：複数の端末で同じ接続情報を同時に使うと、接続先が受信した認証データに応じてEndpointを更新し、端末間で接続が競合することがあります。設定管理者に依頼して、Peerとトンネルアドレスを端末ごとに割り当ててもらってください。

4. Endpoint、Address、AllowedIPsの役割

Endpointは通信を開始するときにアクセスする外部の接続先、Addressはトンネル内で端末が使用するアドレスです。両者を取り違えないでください。たとえば接続先の公開Endpointのポートが51820でも、端末のAddressに同じポートを含める必要はありません。WireGuardはUDPを使います。接続先でTCPだけが許可されている場合、同じポート番号を入力してもUDPで通信できるようにはなりません。

WireGuardのプロトコル層では、AllowedIPsは送信データをどのPeerに送るか選ぶ際に使われ、そのPeerから受信したデータの送信元アドレスの検証にも使われます。Webサイトのドメイン一覧ではないため、example.comのような値は指定できず、DOMAIN-SUFFIXルールに直接入力することもできません。IPv4のデフォルト範囲だけが指定され、IPv6の範囲が含まれていない場合、IPv6の宛先も対象だと判断しないでください。

• Endpointにドメイン名を使う場合、接続先へハンドシェイクの通信を送るには、事前にそのドメイン名を名前解決できる必要があります。
• Addressのプレフィックス長は、慣例だけで変更しないでください。/32と/24では、指定するアドレス範囲が異なります。
• AllowedIPsを広げても、接続先にもともと設定されていない転送機能やアクセス権が追加されるわけではありません。まず接続先で許可されている用途を確認してください。

5. Global RoutingとWireGuardは別の階層の設定

Shadowrocketはまず独自の通信ポリシーに従ってリクエストの経路を決め、その後WireGuardの設定が、その接続経由での通信を制御します。Global RoutingのProxy、Direct、Config、SceneをAllowedIPsと同じものとして扱わないでください。Proxyはプロキシ経由、Directは直接接続、Configは設定ルールに基づく処理、Sceneは設定済みのシーンに基づく処理です。実際の動作は、選択したポリシーと設定内容によって異なります。

初回の動作確認では、影響範囲を把握したうえで一時的にProxyを使い、テスト対象のWireGuard接続を選択すると、ルールによる振り分けの影響を減らして確認できます。確認後は元の設定に戻してください。Configでは、WireGuardが正常でもリクエストがDIRECTに一致すると、AllowedIPsにデフォルト範囲を設定してあるだけでは、そのPeer経由に切り替わりません。

DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

以下はルールキーワードの例であり、WireGuardの設定や、既存のConfigを書き換える指示ではありません。DOMAIN-SUFFIXはドメインのサフィックス、GEOIPはIPの地域データ、IP-CIDRはIPアドレス範囲に基づいて照合します。FINALは、それ以前のルールに一致しなかったリクエストを受け取ります。例のPROXYはプロキシポリシーを示します。実際に使う際は、ルール末尾の文字だけで判断せず、設定内でそのポリシーがどこを指しているか確認してください。

6. MTUとPersistentKeepaliveを調整する際の注意点

MTUは、トンネルインターフェースから送信するIPパケットのサイズを制御します。WireGuardではカプセル化に外側のIPやUDPなどのヘッダー分が必要なため、下位回線のMTUをそのままトンネルに設定できるとは限りません。1420は問題切り分けでよく使われる参考値ですが、すべての経路に適した固定値ではありません。まずは既存の設定値か、アプリのデフォルト設定を使用してください。

1. まず基本の接続を確認：ハンドシェイクが確立していない場合は、MTUを最初の原因と考えるのではなく、Endpoint、UDP通信、鍵を確認してください。
2. 再現する症状を記録：小さなリクエストは成功する一方、大きなレスポンスが何度も途中で止まる場合は、経路のMTU、パケットロス、関連するネットワーク制限を調べる手掛かりになります。ただし、この症状だけで原因を特定できるわけではありません。
3. 一度に変更するのは1項目だけ：設定管理者が許可する範囲で、1420と1380をそれぞれ試して比較できます。毎回保存して再接続し、同じ宛先に同じリクエストを送って確認してください。元の値も記録し、必要に応じて戻せるようにします。
4. 際限なく値を小さくしない：小さくして改善しない場合は、値を下げ続けるのではなく、DNS、ルーティング、接続先の状態を確認してください。IPv6を使用する場合は、そのリンクのMTU制約も考慮する必要があります。

PersistentKeepaliveは、NATマッピングを維持しやすくするため、一定間隔でKeepaliveデータを送信します。25秒はよく使われる設定例であり、プロトコル上必須ではありません。0は定期的なKeepaliveを無効にする値です。しばらく通信がないと応答が戻らなくなる場合の切り分けには役立ちますが、公開鍵の誤り、到達できないポート、許可されていない宛先ネットワークは解決できません。

• 設定ファイルの単位は秒です。25秒をミリ秒として入力しないでください。
• すべてのネットワークで同じ間隔のKeepaliveが必要とは限りません。設定管理者の指定と実際のテスト結果に基づいて判断してください。
• モバイル回線の切り替え後は再テストしてください。Keepaliveを設定しても、ネットワークアドレスの変更中にすべてのリクエストが途切れず成功するとは限りません。

7. 設定を何度も作り直すのではなく、症状に応じて切り分ける

各回で変更する項目は1つだけにし、テストしたネットワーク、Global Routingの状態、アクセス先、結果を記録してください。Homeに表示される遅延や接続テストの結果が示すのは、該当するテスト項目の状態だけです。テスト方法によって確認できる範囲は異なるため、遅延の数値だけで鍵、DNS、AllowedIPs、すべての通信が正常だとは判断できません。