WireGuardの設定では、ローカル側とリモート側を区別することが重要です。Private Keyはローカル側、PeerのPublic Keyはリモート側、Endpointはリモートの公開アドレス、Addressはローカルのトンネルアドレスです。すでにWireGuard設定をお持ちの方を対象に、Shadowrocketでの入力方法を説明し、Allowed IPs、ルーティング設定、DNSの3点から「接続を有効にしてもアクセスできない」原因を確認します。
1. 追加前にInterfaceとPeerを区別する
WireGuardの標準的な設定は、通常[Interface]と[Peer]の2つのセクションで構成されます。前者はローカル側の識別情報とトンネルアドレス、後者は接続先を表します。Shadowrocketで設定ファイルと項目の並びが異なる場合も、それぞれの所属に合わせて入力してください。両者の鍵を取り違えないようにしましょう。
お手元のサービス提供元から受け取った設定一式を用意し、現在も有効であることを確認してください。Endpointだけ、またはPublic Keyだけでは接続できません。サーバー側にはローカル側のPrivate Keyに対応するPublic Keyが登録され、割り当てられたトンネルアドレスが許可されている必要があります。この記事では設定の入力と確認方法のみを説明します。接続先、サブスクリプション、サービス、招待コードの提供・販売・推奨は行いません。
要点：所属を確認してから各項目を入力
元の設定にあるInterfaceとPeerをそれぞれ確認してください。鍵がどちらに属するか分からない場合は、接続を繰り返し試すのではなく、設定の提供元に確認しましょう。
2. Add Serverで順番に入力する
以下ではiPhone／iPadのHome画面を例に説明します。Home → + → Add Server → Type → WireGuardと進み、まずローカル側の情報を入力してからPeerを設定します。Endpointがアドレスとポートに分かれている場合や、Peerが独立した編集欄にある場合は、各項目の意味に沿って入力してください。設定全体をアドレス欄に貼り付けないでください。
-
種類を選択
Home画面の右上にある「+」をタップし、Add Serverを開いてTypeをWireGuardに設定します。登録内容を見分けやすい名前でメモし、既存のサーバーと区別できるようにしてください。
-
ローカル側を入力
InterfaceのPrivateKeyをPrivate Keyに、Addressをローカル側のトンネルアドレスに入力します。
10.66.0.2/32のように、アドレスの後ろにあるプレフィックス長も残してください。 -
接続先を入力
Peerに対応する欄を開き、PeerのPublicKeyとEndpointを入力します。アドレスとポートが別々に表示される場合は、ホスト名またはIPアドレスと数値のポート番号を分けて入力してください。
-
オプションを確認
元の設定を参照し、Allowed IPs、Preshared Key、MTU、DNS、Persistent Keepaliveを確認します。記載のない任意項目を、別アカウントの設定からコピーしないでください。
-
保存してテスト
保存後にHomeへ戻り、対象サーバーの左にある丸印をタップして選択してから、接続スイッチをオンにします。初回はシステムの案内に従ってVPN構成の追加を許可し、その後Connectivity Testを実行してください。
サブスクリプションから作成されたサーバーの場合は、元のパラメーターを優先して確認してください。サブスクリプションの更新で項目が再生成され、手動変更が上書きされることがあります。原因を調べる際は、更新前の値を記録しておき、更新後も変更が残っていると思い込まないようにしましょう。通常のサブスクリプションURLをWireGuardのEndpointとして入力することはできません。
3. Private Key・Public Key・Preshared Keyの違い
Private Keyはローカル側の秘密鍵です。InterfaceのPrivateKeyの値を入力してください。公開の掲示板やスクリーンショットに載せないでください。WireGuardのBase64形式の鍵は通常44文字ですが、文字数が合っていても形式が正しい可能性があるというだけで、サーバーに登録された情報と一致するとは限りません。
| 元の設定項目 | 入力先 | 確認ポイント |
|---|---|---|
| Interface / PrivateKey | Private Key | ローカル側の秘密鍵。空白や改行を含めずにすべてコピー |
| Interface / Address | ローカル側のトンネルアドレス | 公開Endpointではありません。CIDRプレフィックスを残す |
| Peer / PublicKey | PeerのPublic Key | リモート側の公開鍵。ローカル側の公開鍵ではありません |
| Peer / PresharedKey | Preshared Key | 任意の事前共有鍵。両端で同じ値が必要 |
| Peer / Endpoint | リモート側のアドレスとポート | 到達可能なリモート側UDPサービスを指定 |
PeerのPublic Keyはリモート側の公開鍵です。ローカル側のPrivate Keyから生成されたローカル側のPublic Keyを入力しないでください。ローカル側のPublic Keyはリモート側がこの端末を識別するために使い、PeerのPublic Keyはローカル側がリモート側を識別するために使います。役割は反対です。
Preshared Keyは追加の事前共有鍵です。元の設定に記載がなければ、通常は空欄にします。一方だけに入力されている場合や、両端の値が異なる場合はハンドシェイクに失敗します。ログインパスワードではなく、サブスクリプショントークンで代用することもできません。
4. EndpointとAllowed IPs：接続先アドレスとルーティングの違い
Endpointは、WireGuardのUDPパケットを受信するリモート側のアドレスです。例として192.0.2.10:51820のように指定します。このアドレスは説明用で、接続には使えません。51820もよく使われるポートの一例であり、必須ではありません。元の設定に記載されたポートを入力し、独自に443へ変更しないでください。
- アドレスとポートが別々の欄に分かれている場合、アドレス欄にはホスト名またはIPアドレスだけを、ポート欄には10進数のポート番号を入力します。
- Endpointにドメイン名を使う場合、接続前にそのドメイン名を名前解決できる必要があります。名前解決に失敗している場合、WireGuardのハンドシェイクはまだ始まっていません。
- アドレスとポートをまとめて記述する場合、IPv6のEndpointではアドレスとポートを区別するために角括弧を使います。例：
[2001:db8::10]:51820。このアドレスも説明用です。 - Addressはトンネル内で使うローカル側のアドレス、Endpointはリモート側の接続先です。相互に置き換えることはできません。
Allowed IPsには、元の設定のAllowedIPsを入力します。Peerに関連付けるトンネル内のIP範囲を指定する項目です。WireGuardはこの値を使って送信先のPeerを選び、受信パケットの送信元アドレスがそのPeerに属するかも確認します。「アクセスを許可するWebサイトのドメイン一覧」ではないため、example.comのような値は入力できません。
0.0.0.0/0
::/0
10.20.0.0/16上の3行は、それぞれすべてのIPv4、すべてのIPv6、特定のIPv4ネットワークを示す範囲の例です。すべてをそのまま入力する必要はありません。既存の設定で10.20.0.0/16だけが許可されている場合、すべてのアドレス範囲に変更しても、リモート側からインターネットへ転送できるようになるわけではありません。リモート側に対応するルート、転送設定、アクセス権限が必要です。
5. MTU・DNS・Persistent Keepaliveの確認順
MTUはトンネルインターフェースが扱えるIPパケットのサイズを決めるもので、帯域幅の上限ではありません。元の設定にMTUが指定されている場合は、まずその値を使います。指定がない場合は初期設定のままにし、最初から何度も変更しないでください。外側のネットワークのカプセル化や経路MTUは環境によって異なるため、ある環境で使えた値がすべてのネットワークに適するとは限りません。
| 項目 | 役割 | 設定の目安 |
|---|---|---|
| MTU | トンネル内のデータパケットサイズを制限 | 小さなリクエストは正常でも大きなリクエストが止まる場合に確認します。たとえば1420から1380に変更し、同じ宛先で再テストします |
| DNS | ドメイン名の名前解決に使うサーバーを指定 | 現在のルートからDNSサーバーに到達できることと、実際に適用されているDNS設定を確認 |
| Persistent Keepalive | 定期的にKeepaliveパケットを送り、NATマッピングの維持を補助 | 元の設定に合わせます。25秒はよくある例で、必須値ではありません |
DNSはWireGuardのハンドシェイクプロトコルの一部ではありません。設定ファイルのDNSは、クライアントや設定ツール側で処理されることがあります。そのため、元のファイルにDNSが記載されているだけで、Shadowrocketが現在その値を使用中とは限りません。サーバー項目のDNSパラメーターとSettings → DNSの設定を確認してください。現在のConfigファイルにDNS設定がある場合は、それがどう適用されるかも確認しましょう。
DNSアドレスが10.66.0.1のようなトンネル内アドレスの場合、Allowed IPsにそのアドレスが含まれ、該当する通信が実際にトンネルへ送られることを確認してください。そうでなければ、Endpointには到達できてトンネルも確立しているように見えるのに、ドメイン名の解決がタイムアウトすることがあります。DNSサーバーだけを変更して、そのサーバーへの到達経路を見落とさないようにしましょう。
- MTUを調整するときは一度に1つの値だけを変更し、再接続後に同じ宛先へ同じ種類のリクエストを送り、改善したか記録します。
- 小さなリクエストは成功するのに大きなファイルが止まる場合、MTUは調査の手がかりの一つです。リモート側の転送設定や接続先サービスが原因の場合もあるため、これだけで断定しないでください。
- Persistent Keepaliveはアイドル時の接続マッピング維持に役立ちますが、公開鍵やポートの誤り、リモート側でのローカル公開鍵の未登録は修正できません。
6. Proxy・Config・Directを切り分けて確認する
Homeの接続スイッチがオンなのは、クライアントの接続処理が有効になっていることを示すだけで、すべての通信がWireGuardを経由するわけではありません。テスト前に保存したサーバーを左の丸印で選択し、Global Routingを確認してください。以下ではShadowrocketのルーティング設定を比較します。プロトコルの速度比較ではありません。
Proxy：ルールの影響を切り分ける
推奨クライアントが処理する通信を一時的に選択中のプロキシ経路へ送り、今回のテストにConfigの振り分けルールが与える影響を抑えます。Allowed IPsの範囲を広げたり、リモート側の転送機能を補ったりするものではありません。
適しているケース：インターネットへの転送に対応したWireGuard設定の初回確認
Config：ルールの適用先を確認
現在有効な設定ファイルに従って通信を振り分けます。まず対象に適用されたルールとポリシーを確認し、WireGuardへ送るべき通信か判断してください。FINALはそれ以前のルールに一致しなかった通信を処理します。
適しているケース：基本的な接続を確認した後、通常のルール振り分けに戻す
Direct：直接接続と比較する
直接接続の経路を使います。この状態でWebページが開いても、WireGuardが機能している証明にはなりません。ただし、現在のネットワークから対象へ直接アクセスできるかを判断する手がかりになります。
適しているケース：ローカルネットワークの問題とトンネル経路の問題を切り分ける
Global RoutingのSceneは、設定されたシーンに応じてルーティングを行います。トラブルシューティングでは表示名だけでなく、実際に適用されるポリシーも確認してください。手動で切断した後に接続が自動で復旧する場合は、Settings → On Demandも確認します。On Demandは必要に応じた接続動作を制御するもので、WireGuardの設定ミスを修正する機能ではありません。
- 現在のGlobal Routing設定を記録し、テストするサーバーを選択して接続を有効にした後、Connectivity Testを実行します。
- 現在のAllowed IPsの範囲に含まれ、アクセスが許可されていると確認できる宛先をテストします。内部ネットワークへのアクセスだけを提供する設定では、内部のサービスをテストしてください。
- ハンドシェイクや通信の記録を確認できる場合は、「ハンドシェイク未完了」と「ハンドシェイク後に通信できない」を区別します。単一の遅延値だけで通信状況を判断することはできません。
- Configに戻して同じ宛先へ再度アクセスし、ルールのポリシー、DNS、接続結果に変化があるか確認します。
7. 入力後によくある問題と対処法
Private Keyを保存できたのに接続できないのはなぜ？
保存できたことは、入力が受け付けられたことを示すだけです。Homeに戻って対象項目を編集し、InterfaceのPrivateKey、PeerのPublicKey、PresharedKeyがそれぞれ正しい欄に入力されているか確認してください。さらに、リモート側に登録されているのが、そのPrivate Keyに対応するローカル側の公開鍵であることも確認します。
Endpointのポートはすべて51820にすればよい？
いいえ。51820はよく使われる値の一例です。すでにお持ちの設定に記載されたUDPポートを使用してください。アドレスとポートの欄が分かれている場合、コロンとポート番号をアドレス欄に入力しないでください。別の信頼できるネットワークでも試すと、現在のネットワークでUDPに到達できるかを切り分けやすくなります。
内部アドレスにはアクセスできるのに、一般のWebページが開かない場合は？
まずAllowed IPsに内部ネットワークの範囲しか含まれていないか確認し、利用中のサービスがインターネットへの転送を提供しているかを確認してください。インターネットにもアクセスできる想定なら、続けてGlobal RoutingとDNSを確認します。とりあえず全アドレス範囲を追加して解決しようとしないでください。
サブスクリプションを更新したら、手動で変更したMTUが元に戻ったのはなぜ？
サブスクリプションの項目は、更新時にリモート側の内容から再生成される場合があります。更新前に記録した値と比較して変更点を確認し、利用中のサービスの設定元で調整してください。手動テスト用の項目を別に作る場合は、更新された項目と取り違えないよう、区別しやすい名前を付けましょう。
確認を終えたら、必要な項目の確認記録だけを残してください。問題を共有する際は、Private Key、Preshared Key、サブスクリプショントークンなどの機密情報を隠します。アドレスやエラーの状態を示す場合も、アカウントを特定できる情報を先に削除してください。「識別鍵 → Endpoint → Allowed IPs → DNS → MTU」の順に一つずつ確認すると、複数項目を同時に変更するより原因を特定しやすくなります。