この記事では、利用中のサービスからWireGuard設定を入手済みの方に向けて、ローカルのInterfaceとリモートのPeerを区別し、鍵、トンネルアドレス、Endpoint、AllowedIPs、DNS、MTUの対応関係を解説します。最後にShadowrocketでの追加手順と、問題を切り分ける順序を紹介します。既存の設定値を正しく入力する方法を説明するもので、サーバーに登録されていない設定値を新たに作る内容ではありません。
InterfaceとPeerを区別する
WireGuardはUDPを使う暗号化トンネルプロトコルです。従来のユーザー名とパスワードによるログインではなく、鍵を使って通信相手を識別します。ShadowrocketでWireGuardを選択する場合、クライアント側とサーバー側で対応する設定値が必要です。サーバーアドレスだけでは設定できません。
一般的なWireGuard設定ファイルでは、ローカルのトンネルインターフェースを[Interface]、接続先を[Peer]で表します。ここでいう「ローカル」は現在の端末、「接続先」は通常、利用中のサービスのサーバーです。クライアント設定のPrivateKeyは現在の端末のものです。同じファイルの[Peer]内にあるPublicKeyはサーバーのもので、両者は同じ鍵ペアではありません。
WireGuardのネイティブ設定ファイルとShadowrocketの設定ファイルは別の形式です。前者の[Interface]や[Peer]を、Shadowrocketの[Rule]ルールとしてそのまま使うことはできません。手動で追加する場合は、各値をWireGuardの編集画面にある対応項目へ入力してください。クライアントアプリにネイティブ設定の項目がすべて表示されていなくても、残りの内容を別の項目に任意で入力してよいわけではありません。
鍵の設定項目:PrivateKey・PublicKey・PresharedKey
PrivateKeyはローカルの秘密鍵であり、第三者に知られないよう管理してください。通常はBase64でエンコードされた文字列で、32バイトの鍵は一般に44文字になります。末尾の=も値の一部です。コピーする際は、項目名、引用符、空白、改行を含めないでください。また、URLとしてデコードしないでください。文字数が正しくても、サーバーに登録された鍵と一致するとは限りません。
PublicKeyは接続先の公開鍵で、通信相手の確認に使われます。クライアント自身の公開鍵はクライアントの秘密鍵から導出され、サーバー上の対応するPeerに登録されます。一方、クライアントの編集画面で必要な接続先の公開鍵はサーバーから取得します。クライアント自身の公開鍵を接続先の欄に入力したり、サーバーの公開鍵を秘密鍵の欄に入力したりすると、ハンドシェイクを正常に確立できません。
ローカルのInterface設定
- PrivateKey
- 現在の端末の秘密鍵。サーバーの秘密鍵ではありません。
- Address
- ローカルのトンネルインターフェースに割り当てられたアドレス。プレフィックス長もそのまま維持します。
- DNS
- 設定で指定されたDNSサーバーのアドレス。適用方法はクライアントのDNS設定とあわせて確認してください。
- MTU
- トンネルインターフェースの最大伝送単位。単位はバイトです。
これらはローカルインターフェースの値です。サーバーの公開アドレスと混同しないでください。
リモートPeerの設定
- PublicKey
- サーバーの公開鍵。接続先サーバーのものと一致している必要があります。
- PresharedKey
- 任意の事前共有鍵。有効にする場合は双方で完全に一致させます。
- Endpoint
- サーバーのホストアドレスとUDPポート。
- AllowedIPs
- このPeerに対応するトンネルの宛先アドレス範囲。
これらは接続先の値です。サーバー設定ファイルをそのままクライアント設定として入力しないでください。
PresharedKeyは追加の共通鍵であり、公開鍵と秘密鍵の代わりにはなりません。既存の設定に記載がない場合は、未設定のままにしてください。サーバー側で有効になっている場合、クライアントで設定を省略したり誤った値を入力したりすると、ハンドシェイクに失敗します。「すべての欄を埋める」ために値を作成したり、PrivateKeyをPresharedKeyにもコピーしたりしないでください。
- クライアントの秘密鍵を再生成した場合は、サーバー側の対応するクライアント公開鍵も更新する必要があります。ローカル側だけを変更しても、通常は接続を復旧できません。
- 端末ごとに、それぞれ登録された鍵とトンネルアドレスを使うのが適切です。同じIDを2台の端末で同時に使うと、サーバー側で接続元アドレスが切り替わることがあります。
- 問題を確認するためのスクリーンショットでは、秘密鍵と事前共有鍵をすべて隠してください。鍵を含む設定全体を公開の場に貼り付けないでください。
EndpointとAddress:公開の接続先とトンネルアドレスの違い
Endpointは、トンネルを確立するため最初に接続するサーバーの入口です。たとえば192.0.2.10:51820の場合、192.0.2.10は説明用のアドレス、51820はUDPポートです。Shadowrocketの編集画面でアドレスとポートが別々の欄になっている場合は、それぞれ入力してください。ポート付きの文字列全体をアドレス欄に重複して入力しないでください。アドレスの前にhttps://を付けたり、末尾にウェブページのパスを追加したりする必要はありません。
Endpointにドメイン名を指定する場合は、まず名前解決ができ、そのうえで現在のネットワークから該当するUDPポートに接続できる必要があります。ウェブページを開けることや、TCPポートのテストに成功することは、そのUDP接続先が利用可能である証明にはなりません。IPv6をアドレスとポートの形式でまとめて記述する場合は、[2001:db8::10]:51820のように角括弧を使います。編集画面にアドレス専用の欄がある場合は、その欄の形式に従い、まとめ書きの括弧を機械的に付けないでください。
| 項目 | 記載例 | 混同してはいけない値 |
|---|---|---|
| Endpoint | 192.0.2.10:51820 | ローカルのトンネルAddressは入力できません。 |
| Address | 10.66.0.2/32 | サーバーの公開接続先や自宅のWi-Fiアドレスは入力できません。 |
| AllowedIPs | 0.0.0.0/0, ::/0 | サーバーアドレスの一覧として扱うことはできません。 |
| DNS | 10.66.0.1 | 既存の設定で明示され、トンネル経由で到達可能な場合に限り使用します。 |
Addressは、サーバーからクライアントに割り当てられるトンネル内のアドレスです。IPv4とIPv6の両方が含まれることもあります。/32や/128など、サービスから提供されたプレフィックス長を維持してください。家庭内ネットワークでよく使われる/24を見て、独自に置き換えないでください。アドレスの競合、未登録、またはサーバーで許可された範囲との不一致があると、ハンドシェイク確立後も通信できないことがあります。
AllowedIPs・DNS・MTUの役割
WireGuardでは、AllowedIPsはPeerのトンネルアドレス範囲と関連し、送信先Peerの選択と受信元の検証に使われます。0.0.0.0/0はすべてのIPv4宛先を対象とし、::/0はすべてのIPv6宛先を対象とします。ただし、サーバーがデュアルスタック転送に対応しているとは限らず、Shadowrocketのすべての通信がそのWireGuard接続を通るとも限りません。実際にどの経路を使うかは、クライアントのルーティング設定とルールによって決まります。
DNSはドメイン名をアドレスに変換し、トンネルはデータを転送します。ネイティブ設定のDNSは通常、設定管理ソフトによって適用されるもので、WireGuardのハンドシェイク自体には含まれません。Shadowrocketに手動で設定を移す場合は、現在の設定でDNSがどう指定されているかも確認してください。元のファイルにDNSの行があるだけで、アプリ内の名前解決経路も一致していると判断しないでください。
- ドメイン名だけ失敗する場合:同じ接続先へのアドレス指定では通信でき、ドメイン名の名前解決でエラーになる場合は、まずDNSの応答とDNSサーバーへの到達性を確認します。
- IPv6だけ失敗する場合:IPv6のAddress、
::/0、サーバー側のIPv6転送機能を確認してください。範囲を1つ追加しただけでIPv6全体に対応したと判断しないでください。 - ハンドシェイクは正常でも通信できない場合:トンネルのAddress、AllowedIPs、サーバー側の転送設定を確認してください。まず鍵を何度も入れ替えるのは避けてください。
MTUは、トンネルインターフェースで一度に送信できるIPパケットの最大サイズです。WireGuardでは外側のIP、UDP、暗号化のための領域も必要です。追加のカプセル化がない場合、外側のIPv4で約60バイト、IPv6で約80バイトが必要になります。そのため、経路MTUが1500の場合は1420がよく使われる目安ですが、すべてのネットワークやShadowrocketで固定の既定値というわけではありません。
既存の設定にMTUが明記されている場合は、まずその値を維持してください。小さなリクエストには応答する一方、大きなウェブページの読み込みやアップロードが止まる場合は、元の値を記録してから、たとえば1420から1380に下げて同じリクエストを試すなど、1項目ずつ検証します。これは経路MTUの問題を切り分ける方法であり、特定のネットワークでの実測結果ではありません。値を下げても変化がなければ元に戻し、ほかの要因を確認してください。
Shadowrocketでの追加と動作確認
以下では、HomeからWireGuardを手動で追加する手順を説明します。プラットフォームによって編集画面の項目が分かれていたり、まとめられていたりするため、行数ではなく項目の意味をもとに入力してください。作業前に元の設定を保存し、まず必要最小限の項目で動作を確認してから、ルーティング、DNS、MTUを調整します。一度に多く変更すると、原因を特定しにくくなります。
-
元の設定を確認する
[Interface]と[Peer]を分けて読み、ローカルのPrivateKeyとAddress、サーバーのPublicKeyとEndpointを確認します。PresharedKeyが含まれているかも確認し、記載のない設定値を独自に追加しないでください。 -
プロトコルを選択する
Home → 右上の「+」→ Type → WireGuardの順に開きます。編集中の接続がWireGuardであることを確認してください。これらの値をほかのプロトコルの設定項目に入力することはできません。
-
設定値を入力する
ローカルインターフェースとリモートPeerの対応関係に沿って入力します。Endpointがアドレスとポートの2欄に分かれている場合は、それぞれ入力してください。鍵は省略せずコピーし、Addressのプレフィックス長はそのまま維持します。表示されていない任意項目を、別の欄で代用しないでください。
-
保存して接続先を選択する
保存後にHomeへ戻り、追加した接続を選択します。現在のGlobal Routingの設定を記録してください。Configのルールによる影響を一時的に切り分ける場合は、Proxyを使って1回だけ確認し、テスト後に通常の設定へ戻します。
-
接続を確認して記録する
接続を開始し、システムの指示に従ってVPN構成を許可します。ドメイン名でのアクセス、小さなリクエスト、大きなコンテンツの読み込みをそれぞれ確認し、ネットワークの種類、症状、変更した項目を記録してください。Settings → On Demandで自動接続条件を設定している場合は、手動での切り替えに影響しないよう、切り分け中にあわせて確認します。
サブスクリプションに含まれるWireGuard項目と手動で追加した項目は区別してください。すでに利用中のサブスクリプションを更新すると、リモート管理されている項目が内容に応じて変わることがあります。ローカルでの一時的な変更を、長期的な設定の入手元として扱わないでください。更新後に使えなくなった場合は、Endpoint、PublicKey、Addressが変わっていないかを先に確認し、必要に応じて自身の設定を再読み込みしてください。
Global Routingの設定と問題の切り分け
Shadowrocketでは、プロトコルの設定が正しいことと、実際の通信がその接続を使うことは別の問題です。WireGuardはトンネルの確立方法を定め、Global RoutingとConfig内のルールは通信経路を決定します。あるウェブサイトが開けたからといって、WireGuardが接続できているとは限りません。その通信はDIRECTを使った可能性があります。
Config
おすすめ現在有効な設定のルールに従って経路を選びます。ルールによって通信ごとにDIRECT、プロキシポリシー、REJECTを振り分けられます。どのルールにも一致しない通信はFINALで指定したポリシーに従い、必ずDIRECTになるわけではありません。
適した用途:設定値の検証後、既存のルールに沿って日常的に通信を振り分ける。
Proxy
プロキシ経由の通信に、現在選択中の接続を使用します。Configの通信振り分けルールの影響を一時的に切り分ける際に使えます。対象のWireGuard項目が選択されていることと、現在のネットワークからUDPのEndpointに接続できることを確認してください。
適した用途:問題がWireGuard接続にあるのか、設定ルールにあるのかを短時間で確認する。
Direct
直接接続を使い、現在のネットワークの基準として比較できます。この設定でアクセスに成功しても、WireGuardの鍵、サーバーの接続先、トンネル転送が正常とは限りません。
適した用途:現在のネットワーク自体で同じ接続先にアクセスできるか比較する。
Sceneを使う場合は、現在のシーンで実際にどのルーティング設定が適用されているかを確認してください。シーン名だけでプロトコルの動作を判断することはできません。Configでは、DOMAIN-SUFFIX、IP-CIDR、GEOIPはそれぞれ異なる条件で照合され、FINALは最後のフォールバックです。切り分け時は、ルールファイルにWireGuardという文字列があるかだけでなく、通信がどのポリシーに一致したかを確認してください。
| 確認できた症状 | 最初に確認する項目 | 次に行うこと |
|---|---|---|
| ハンドシェイクが成功した形跡がない | Endpoint、UDPの到達性、双方の鍵、PresharedKey。 | サーバー側の状態を確認できる場合は、ハンドシェイクの記録を確認します。利用可能と分かっている別のネットワークでも比較してください。 |
| ハンドシェイクは確認できるが、リクエストがタイムアウトする | Address、AllowedIPs、サーバー側の転送と戻り経路。 | 割り当てられたトンネルアドレスが現在も有効か確認し、通信が意図したポリシーを通っているか確認してください。 |
| ドメイン名でのアクセスだけ失敗する | DNS応答、DNSサーバーへの到達性、実際に適用されているDNS設定。 | 名前解決のタイムアウト、空の応答、名前解決後の接続失敗を区別してください。 |
| 小さなリクエストは成功するが、大きなデータの読み込みが止まる | 経路MTU、カプセル化のオーバーヘッド、ネットワークのパケットロス。 | 元の値を記録してから、MTUだけを下げてテストします。改善しなければ元の値に戻してください。 |
| ネットワーク切り替え後やアイドル状態の後に使えなくなる | NATマッピング、Endpointへの到達性、自動接続条件。 | 接続を再確立して比較し、Keepalive設定とOn Demandの条件を確認してください。 |
切り分けでは一度に1つの項目だけを変更し、問題を再現できる操作を記録してください。1回の遅延テストだけでは、ハンドシェイク、DNS、実際の通信を確認したことにはなりません。また、接続スイッチがオンでも、サーバーが現在の鍵を受け付けたとは限りません。利用中のサービス提供元に問い合わせる場合は、発生時刻、ネットワークの種類、Endpointのポート、症状を伝えれば十分です。秘密鍵と事前共有鍵を問い合わせとともに公開送信しないでください。