異なるプロバイダーのVPSをWireGuardで接続する方法

異なるプロバイダーの2台のVPSを1つのシステムとして連携できますか

はい。異なるプロバイダー間で2台のVPSを接続するには、プライベートネットワークを自分で構築します。通常は WireGuard を使い、パブリックインターネット上に暗号化されたオーバーレイネットワークを構成します。各プロバイダーのプライベートネットワークは自社のネットワーク境界で終わるため、プロバイダーが接続を構成してくれることはありません。接続に伴うコストとして、設定では解消できない遅延と、両端で計測される外向き通信の転送量が発生します。また、トンネル内ではパケットのサイズが小さくなるため、ネットワーク障害とは分かりにくい問題が起きることもあります。

通常、別の質問として扱われるのは、誰がマシンを管理するかです。これは マネージド VPS とアンマネージド VPS の違いに関する質問 であり、別の論点です。このページでは相互運用性を扱います。つまり、東京のサーバーと別の国にあるサーバーが1つのプライベートアドレス範囲を共有し、名前で互いを検索し、互いの通信を受け入れ、その他の通信を拒否できるかどうかを説明します。

日本の利用者にとって一般的な構成は、東京または大阪のVPSで国内ユーザー向けのサービスを提供し、海外の安価なVPSでバッチ処理、バックアップ、またはビルド処理を実行する形です。この分担は適しています。一方、同じ2台のサーバーに1つのリクエスト経路を分散すると、通常はうまくいきません。その理由をこのページの以降で説明します。

プロバイダーのプライベートネットワークが自社の境界で止まる理由

プロバイダーのプライベートネットワークは、そのプロバイダーのデータセンター内にある仮想 LAN（local area network）です。2 番目のインターフェースに割り当てられた 10.x.x.x アドレスは、そのプロバイダーのスイッチによってのみルーティングされます。RFC 1918 のプライベートアドレスであり、プライベートアドレスはパブリックインターネット上ではルーティングされません。10.0.0.5 宛てのパケットをインターネットへ送信すると、それを認識するプロバイダー外部の最初のルーターで破棄されます。そのため、2 つのアカウントを接続する設定は、どちらのコントロールパネルにもありません。同じプロバイダー内では事情が異なります。両方のマシンが同じアカウントにある場合は、同じプロバイダーの 2 台のマシン間にある無料のプライベートネットワークが適切な手段です。

プロバイダーをまたぐ通信では、管理できないトランジットネットワークやインターネットエクスチェンジを通過します。平文で送信したデータは、そこで読み取られます。オーバーレイは任意の追加対策ではありません。それが接続手段です。

競合しないアドレスを選ぶ

鍵を生成する前に実施します。両方のマシンで次を実行します。

ip -4 addr show
ip route show
ip -4 addr show docker0 2>/dev/null

すでに使用されている範囲をすべて書き留めます。2 つのプロバイダーが重複する RFC 1918 範囲を割り当てることは珍しくありません。また、Docker はデフォルトで docker0 に 172.17.0.0/16 を使用します。次に、どちらの一覧にも存在しない overlay の範囲を選びます。たとえば 10.83.7.0/24 です。192.168.0.0/24 と 192.168.1.0/24 は避けてください。同じ overlay にラップトップを追加した時点で、自宅のルーターと競合するためです。

重複していてもエラーは発生しません。カーネルが最も具体的に一致する route を選ぶため、誤った結果になります。overlay が 10.0.0.0/24 で、プロバイダーがすでに 2 番目のインターフェースから 10.0.0.0/16 を route している場合、peer 宛てのパケットはプロバイダーのネットワーク経由で送信され、ログに何も残らないまま消えます。

各マシンにその範囲内の固定アドレスを割り当て、記録します。このガイドでは、Tokyo のマシンに 10.83.7.1、海外のマシンに 10.83.7.2 を使用します。

トンネルを構築する: 両方のボックスで WireGuard を設定する

WireGuard にはクライアント役割やサーバー役割はありません。両方のマシンで同じソフトウェアを実行し、それぞれが 1 組の鍵を保持して、相手を peer として登録します。各ボックスで次を実行します。

sudo apt update && sudo apt install -y wireguard
sudo install -d -m 700 /etc/wireguard
sudo sh -c 'umask 077; wg genkey > /etc/wireguard/host.key'
sudo sh -c 'wg pubkey < /etc/wireguard/host.key > /etc/wireguard/host.pub'
sudo chmod 600 /etc/wireguard/host.key
sudo cat /etc/wireguard/host.pub

東京のボックスでは、ここでの公開アドレスが 203.0.113.10 なので、/etc/wireguard/wg0.conf を記述します。

[Interface]
Address = 10.83.7.1/24
ListenPort = 51820
PrivateKey = <contents of host.key on the Tokyo box>

[Peer]
PublicKey = <contents of host.pub on the overseas box>
AllowedIPs = 10.83.7.2/32
Endpoint = 198.51.100.20:51820
PersistentKeepalive = 25

海外のボックスでは、ここでの公開アドレスが 198.51.100.20 なので、同じファイルに次を記述します。

[Interface]
Address = 10.83.7.2/24
ListenPort = 51820
PrivateKey = <contents of host.key on the overseas box>

[Peer]
PublicKey = <contents of host.pub on the Tokyo box>
AllowedIPs = 10.83.7.1/32
Endpoint = 203.0.113.10:51820
PersistentKeepalive = 25

両方で sudo chmod 600 /etc/wireguard/wg0.conf を実行します。AllowedIPs がアクセスモデル全体を定義します。送信時にパケットをどの peer へ送るか、受信時にその peer からどの送信元アドレスを受け入れるかを決めます。WireGuard が公開鍵をアドレス範囲に関連付ける仕組みである Cryptokey routing は、3 台目のマシンを追加する前に一度読んでおくとよいでしょう。2 台のボックスを対等に接続するのではなく、1 台で多数のクライアントを提供する場合は、WireGuard サーバー完全ガイドを参照してください。

両端が公開アドレスを持つ場合、PersistentKeepalive = 25 は必須ではありません。それでも設定してください。多くのプロバイダーはインスタンスの前段にステートフルファイアウォールを配置しています。その UDP エントリは 1、2 分通信がないと期限切れになるため、アイドル状態の後に送信した最初のパケットが破棄され、リンクの復旧が遅いように見えることがあります。

起動して確認します。

sudo systemctl enable --now wg-quick@wg0
sudo wg show
ping -c 3 10.83.7.2

wg show には、数秒前の latest handshake と、両方向の転送カウンターが 0 ではない値で表示されるはずです。ハンドシェイク行がない peer では、パケットが到達していません。プロバイダー独自のネットワークファイアウォールで UDP 51820 を許可してください。これは多くの管理パネルで ufw とは別の制御です。その後、受信側のボックスで sudo tcpdump -ni any udp port 51820 を実行し、パケットがそもそも到達しているか確認します。

トンネルを保護し、公開インターフェースは公開しない

このリンクの目的は、サービスが公開アドレスで待ち受けないようにすることです。各サービスを overlay アドレスにバインドします。PostgreSQL では、postgresql.conf 内の listen_addresses = '10.83.7.1' を設定します。その他の多くのデーモンでは、bind または address の行を設定します。

次に、トンネルインターフェース上でのみポートを開きます。

sudo ufw allow from 198.51.100.20 to any port 51820 proto udp
sudo ufw allow in on wg0 to any port 5432 proto tcp
sudo ufw enable

最初のルールが、このリンクに必要な唯一の公開です。対象は 1 つのアドレスに限定されています。2 つ目のルールは、インターネットからのパケットには決して一致しません。パケットが wg0 上に現れるのは、WireGuard が復号し、その送信元が対象ピアの AllowedIPs と一致することを確認した後だからです。これらのルールに慣れていない場合は、VPS の ufw ファイアウォールの基本で、デフォルトポリシーとルールの順序を説明しています。

overlay にバインドすると、これに直接起因する問題が 1 つ発生します。wg0 が存在する前にサービスを起動すると、そのアドレスはまだマシン上にないため、バインドに失敗します。PostgreSQL は次のように明確に報告します。

could not bind IPv4 address "10.83.7.1": Cannot assign requested address

最も簡単な解決策は、まだ存在しないアドレスへのバインドを許可することです。

echo 'net.ipv4.ip_nonlocal_bind = 1' | sudo tee /etc/sysctl.d/99-overlay.conf
sudo sysctl --system

もう 1 つの方法は、sudo systemctl edit postgresql と After=wg-quick@wg0.service の行を使い、トンネルの後に unit を起動するよう順序を指定することです。sysctl の方法のほうが簡単です。また、サービスを実行したままインターフェースを再起動しても有効です。順序を指定する方法には、この性質がありません。

リージョン間のレイテンシがアプリケーションに与える影響

ラウンドトリップ時間（RTT）が下限になります。現在の CPU では、パケットごとの暗号化にかかる時間は 1 ミリ秒を大きく下回るため、トンネル自体が体感上の遅延になるわけではありません。距離が原因です。光ファイバー中の光速は毎秒約 200,000 km ですが、実際の経路は直線ではありません。そのため RTT は地理的な距離と、2 つのプロバイダー間で選択される経路によって決まります。

[
  {
    "label": "Tokyo to Osaka",
    "rtt_ms": 8,
    "seconds_for_200_queries": 1.6
  },
  {
    "label": "Tokyo to Singapore",
    "rtt_ms": 70,
    "seconds_for_200_queries": 14
  },
  {
    "label": "Tokyo to US West",
    "rtt_ms": 100,
    "seconds_for_200_queries": 20
  },
  {
    "label": "Tokyo to Frankfurt",
    "rtt_ms": 235,
    "seconds_for_200_queries": 47
  }
]

これは接続性の高い経路で一般に公表されている代表値であり、2 台のサーバー間を測定した値ではありません。数値を前提に設計する前に、自分の環境で測定してください。

国内のホップで 8 ms であれば、ユーザーは遅延を意識しません。東京から米国西海岸まで 100 ms かかる場合は意識され、東京から Frankfurt まで 235 ms かかる場合は、問題の性質が変わります。多くの人が驚くのは、レイテンシが積み重なる点です。オブジェクトリレーショナルマッパーを使って構築されたアプリケーションでは、200 回のデータベースクエリを順番に実行することがあります。各クエリで 1 回の RTT が発生するため、クエリが 1 バイトも処理しない段階で、国内リンクでは 1.6 秒、Frankfurt リンクでは 47 秒かかります。

スループットも同じ原因の影響を受けます。TCP ストリームで転送中の未確認応答データを保持できるウィンドウは 1 つだけなので、上限はウィンドウサイズを RTT で割った値になります。Linux は net.ipv4.tcp_rmem の最大値までウィンドウを自動的に拡大しますが、経路が長いとパケット損失によってウィンドウが縮小し、回復にも時間がかかります。1 本の rsync ストリームで大きなバックアップをコピーすると、同じコピーを 8 本の並列ストリームに分割した場合より大幅に遅くなります。

送信課金は両端で発生する

ほぼすべてのプロバイダーは送信データを従量課金し、受信データを無料にしています。トンネルでは双方向にトラフィックが流れるため、Tokyo のサーバーが送信するデータは Tokyo のプロバイダーから課金され、overseas のサーバーが送信するデータは overseas のプロバイダーから課金されます。2026 年 9 月時点でも、これが一般的な仕組みです。ただし、ホストによって無料枠と超過料金は桁違いに異なるため、両方のアカウントを確認してください。

見落としやすい点が 2 つあります。バックアップとレプリケーションのトラフィックは送信側で全量が課金されます。そのため、Tokyo から毎晩取得する 50 GB のデータベースダンプは、overseas 側ではなく、毎晩 Tokyo の無料枠を 50 GB 消費します。また、WireGuard のパケットごとのオーバーヘッドも課金対象のトラフィックです。1500 byte のパケットを最大サイズで送る場合は約 4 パーセントなので、通常は気になりません。しかし、100 byte のペイロードを送る通信量の多いプロトコルでは、各パケットが回線上で 160 byte になるため、オーバーヘッドはペイロードの 60 パーセントに達します。

ここでの設計は単純です。リクエストごとではなく、スケジュールしたバッチ単位でデータを移動し、送信前に圧縮します。通信量の多い処理は、リンクの片側に寄せてください。

MTU とフラグメンテーションの問題は、小さな転送ではなく大きな転送を妨げます

MTU (maximum transmission unit) は、インターフェースが送信できる最大パケットサイズです。WireGuard は、パケットを外側の IP ヘッダー、UDP ヘッダー、独自のメッセージヘッダー、認証タグでカプセル化します。

[
  {
    "label": "1500 byte path, IPv4 outer",
    "overhead_bytes": 60,
    "tunnel_mtu": 1440
  },
  {
    "label": "1500 byte path, IPv6 outer",
    "overhead_bytes": 80,
    "tunnel_mtu": 1420
  },
  {
    "label": "1492 byte path, IPv4 outer",
    "overhead_bytes": 60,
    "tunnel_mtu": 1432
  },
  {
    "label": "1400 byte path, IPv4 outer",
    "overhead_bytes": 60,
    "tunnel_mtu": 1340
  }
]

IPv4 ではオーバーヘッドが 60 bytes あるため、通常の 1500 byte の経路では、トンネル内部に 1440 bytes 残ります。IPv6 では 80 bytes です。wg-quick は常に大きい方の値を差し引くため、デフォルトでインターフェースを 1420 に設定します。これは最適値ではなく、安全側の設定です。2 つのプロバイダー間にあるいずれかのホップが 1500 bytes 未満しか運べない場合、必要な値はさらに小さくなります。1400 byte の経路では、トンネル内部に残るのは 1340 bytes だけです。

この症状には明確な特徴があり、毎回混乱を招きます。ping は動作します。SSH 接続は確立し、入力も正常に感じられます。しかし apt update が停止したり、大きな HTTPS レスポンスがヘッダー受信後に停止したり、ファイルコピーが数 kilobytes 後に止まったりします。小さなパケットは通過しますが、大きなパケットは通過しません。カーネルは、ICMP (internet control message protocol) の「fragmentation needed」メッセージから制限値を学習するはずです。しかし、多くのネットワークは ICMP を破棄するため、送信側は制限値を学習できず、到達できないパケットの再送を繰り返します。

実際の制限値を手動で確認します。次のコマンドは、ICMP ヘッダー 8 bytes と IP ヘッダー 20 bytes を加えるとちょうど 1500 になる、1472 byte のペイロードを送信します。フラグメンテーションは禁止しています。

ping -M do -s 1472 -c 2 198.51.100.20

失敗する場合は差を半分にして、1372、次に 1272 で試します。自分のインターフェース上の制限値は、すぐに確認できます。

ping: local error: message too long, mtu=1500

経路のさらに先にある制限値は、次のように確認できます。メッセージ内の数値が求めていた値です。

From 192.0.2.1 icmp_seq=1 Frag needed and DF set (mtu = 1400)

成功した最大のペイロードに 28 を加えて path MTU を求め、そこから 60 を引きます。その結果を、両方のボックスの [Interface] セクションに設定します。

MTU = 1340

sudo systemctl restart wg-quick@wg0 で再起動し、ping -M do -s 1312 -c 2 10.83.7.2 を使ってトンネル内でもテストを繰り返します。2 つのトンネルアドレスだけでなくサブネット全体をリンク経由でルーティングする場合は、転送経路に TCP MSS (maximum segment size) clamping を追加してください。ボックスの背後にあるマシンは、通常、自分でトンネルの MTU を学習できないためです。

内部 DNS で 2 台のボックスが相互に名前解決できるようにする

アプリケーションの設定にオーバーレイアドレスを直接記述しないでください。マシンに名前を付けます。2 台であれば、各マシンの /etc/hosts に設定する方法が率直で、これ自体に障害要因はありません。

10.83.7.1 tokyo.internal tokyo
10.83.7.2 batch.internal batch

自分が所有するサフィックス、または明確にプライベートなサフィックスを使用してください。将来、実在するトップレベルドメインになる可能性があるサフィックスを勝手に作らないでください。そうなると、その日から内部名が他者のサーバーへ解決され始めます。マシンが 4 台または 5 台を超えたら、1 台で dnsmasq を実行し、そのマシンのオーバーレイアドレスにバインドします。他のマシンからは /etc/systemd/resolved.conf.d/ の drop-in を使用して、その DNS サーバーを参照させます。このリゾルバーは依存先になります。そのマシンが停止すると、他のマシンでの名前解決も停止するため、フォールバックとして /etc/hosts のエントリを残してください。リゾルバーやレコードタイプが初めての場合は、DNS の概要と名前解決の仕組みで要点を短く確認できます。

ハイパーバイザーを共有しなくなったため、時刻を同期する

同じプロバイダーの 2 台の VPS は、準仮想化クロックを通じて同じ物理ホストから時刻を取得することが多いため、特別な設定をしなくても相互に時刻が一致します。異なる 2 社のプロバイダーにある VPS は、何も共有しません。それぞれ独立して時刻がずれます。仮想マシンは、停止した vCPU がタイマー割り込みを取り逃すため、物理マシンより大きくずれます。

時刻のずれは、時計の問題に見えない障害として現れます。時計が遅れているマシンでは、TLS (transport layer security) の検証が「certificate is not yet valid」というエラーで失敗します。一方のマシンで発行した JWT (JSON web token) は、nbf クレームが未来の時刻を示すため、もう一方のマシンで拒否されます。2 台のマシンのログ行が誤った順序で混在し、インシデントの時系列が事実と異なります。両方に chrony をインストールします。

sudo apt install -y chrony
chronyc tracking
chronyc sources -v

chronyc tracking は、現在のオフセットを示す System time 行を出力します。1 ミリ秒未満なら正常です。1 秒を超える場合は、後回しにせず直ちに対処します。日本のマシンでは、近隣のソースを使うと経路を短縮できます。/etc/chrony/chrony.conf に server ntp.nict.jp iburst を追加します。ntp.nict.jp は、日本の国立研究開発法人情報通信研究機構が運用する公開サービスです。海外のマシンにも同じ理由で近隣のソースを指定し、その後 sudo systemctl restart chrony を実行します。続いて chronyc sources -v を再度確認し、^* が付いたソースがあることを確認します。

管理する鍵、または依存する調整サービス

上記の構成には、第三者は関与しません。2 つの秘密鍵を自分で管理し、両方のサーバーが稼働している限り接続は機能します。代わりに、管理作業が必要です。新しいマシンを追加するたびに、他のすべてのマシンの [Peer] ブロックを編集する必要があります。鍵のローテーションも、手動で実施する作業として覚えておかなければなりません。マシンが 2 台または 3 台なら問題ありません。しかし 15 台になると、重複するアドレスや古いピアが発生し始めます。

Tailscale と NetBird は、この管理作業を調整サーバーに移します。どちらもデータプレーンとして WireGuard を使用し、その上に鍵の配布、アドレス割り当て、NAT（ネットワークアドレス変換）トラバーサル、アクセスルールを追加します。Headscale は、Tailscale クライアント向けに自分でホストできるオープンソースの調整サーバーです。通信は引き続き 2 台のサーバー間を直接流れ、調整サーバーが通信を暗号化する鍵を保持することはありません。ただし、調整サーバーに到達できない間は、新しいピアを参加させることも、鍵をローテーションすることもできません。WireGuard を自分で運用するか、調整サーバーに任せるかの違いは、主に 1 年後に何台のマシンを運用しているかで決まります。海外のサーバーから国内のサーバーの背後にあるプライベートネットワーク全体へ、単一のアドレスではなく接続したい場合は、プライベートネットワークの範囲を広告するサブネットルーターが必要です。手動で構成する場合は、転送を行うサーバー上で AllowedIPs エントリと net.ipv4.ip_forward = 1 を一致させる必要があります。

プロバイダー間で分割すべきでないワークロード

リンクをまたぐと成立しなくなる処理があり、チューニングでは解決できません。プライマリが同期レプリカからの確認応答を待つデータベースでは、書き込みのたびに RTT 全体が追加されます。遠隔地のデータベースをアプリケーションが照会すると、照会ごとに 1 RTT が発生します。上のグラフでは、この遅延が秒単位で示されています。100 ms の経路上で NFS（network file system）のようなネットワークファイルシステムを使うと、実用になりません。メタデータ操作では小さな往復が多数発生し、そのすべてをユーザーが待つ必要があるためです。etcd のようなクラスタ調整サービスでは、ハートビートが欠落すると新しいリーダーの選出が始まります。経路が長い、または遅延が変動するだけで、この状態が発生します。

適切に分割できる処理には、非同期であるという共通点があります。一方が他方を待ち続けることがありません。バッチ処理、夜間バックアップ、CI（continuous integration）のビルドランナー、ログ転送、メディアのトランスコード、ジョブを取得するキューワーカーは、長いリンクにも耐えられます。各ワークアイテムに、ワーカーが必要とする情報がすべて含まれるためです。これは、ユーザー向けに Tokyo のサーバーを置き、重い処理用に海外の安価なサーバーを置く構成に適しています。海外の安価なサーバーは x86 ではなく ARM であることが多いため、購入前に バッチワークロードが ARM で適切に動作するか を確認する価値があります。依存するすべてのコンテナイメージが、そのアーキテクチャー向けに用意されている必要があるためです。

ユーザー向けサービスとそのデータベースは、リンクの同じ側に配置してください。処理をバッチ単位で反対側へ送り、完了したら遠隔側から結果を返させます。

FAQ

プロバイダーのプライベートネットワークを使って、別のプロバイダーにあるサーバーへ接続できますか？

いいえ。プロバイダーのプライベートネットワークは、そのプロバイダー自身のデータセンター内でのみルーティングされます。また、そのネットワーク上の 10.x.x.x アドレスは RFC 1918 のプライベートアドレスであり、インターネット上のルーターは転送しません。プロバイダーの外部からそのアドレスへ送信したパケットは、最初に受信したルーターで破棄されます。2 つのプロバイダーを接続するには、インターネット上に暗号化されたオーバーレイネットワークを自分で構築します。通常は、両方のサーバーで WireGuard を実行し、それぞれに相手を peer として登録します。

2 台の VPS 間で WireGuard トンネルを使用すると、どの程度の遅延が追加されますか？

WireGuard 自体による遅延は、ほとんどありません。現在の CPU であれば、パケットごとの暗号化と復号にかかる時間は 1 ミリ秒未満です。測定される遅延の大部分は、2 つのデータセンター間の距離と、プロバイダーが選択する経路によるものです。トンネル経由で ping -c 100 を実行して確認し、1 回の測定値ではなく平均値と偏差を読み取ってください。トンネル経由の RTT が 2 つのパブリックアドレス間の RTT より大幅に悪い場合は、WireGuard の設定ではなく、CPU 飽和やパケット損失を調べます。

ping は動作するのに、トンネル経由の大容量転送が停止するのはなぜですか？

経路に対してパケットが大きすぎるのに、送信元へ通知されないためです。WireGuard は IPv4 に 60 バイトを追加するため、1500 バイトの経路でトンネル内部に運べるデータは最大 1440 バイトです。2 つのプロバイダー間の経路にこれより小さい MTU の区間があると、サイズ超過のパケットは破棄されます。さらに、ICMP をブロックするネットワークでは、「fragmentation needed」メッセージが送信元に届かないため、送信元は永久に再送を続けます。ping -M do -s 1472 <peer public address> で正常に動作するサイズを見つけ、通過するまで小さくしてください。その後、両方のサーバーの [Interface] セクションで MTU を設定します。

トンネルのトラフィックについて、両方のプロバイダーで egress 料金が発生しますか？

通常は、はい。各プロバイダーは自社のサーバーから外部へ送信される通信量を計測し、受信トラフィックは通常無料とします。そのため、双方向の通信は各端で 1 回ずつ課金されます。WireGuard のパケットごとのオーバーヘッドも課金対象となります。多数の小さなパケットを送る場合は、少数の大きなパケットを送る場合より影響が大きくなります。毎晩の同期を計画する前に、両方のアカウントで含まれる転送量と超過料金を確認してください。2026 年 9 月時点では、これらの料金はホストによって大きく異なります。

アプリケーションを一方のプロバイダーで実行し、データベースを別のプロバイダーで実行すべきですか？

ユーザーが結果を待つ処理であれば、避けてください。クエリごとに 1 回のラウンドトリップが必要です。そのため、1 ページで 200 個のクエリを発行すると、各クエリが処理を開始する前に 200 回のラウンドトリップが発生します。大陸間のリンクでは、これだけで数秒かかります。アプリケーションとデータベースは同じ側に配置してください。もう一方には、待ち合わせが発生しない処理を送ります。バックアップ、バッチジョブ、ログ転送、ビルドランナーなどが該当します。