著者 WireGuard・Tailscale・Headscaleの違いと選び方
WireGuardは10台のネットワークに1台追加すると10個の設定ファイル編集が必要です。Tailscaleは調整サーバーでNAT越えと鍵配布を自動化し、Headscaleはその運用を自分で担います。VPS向けの選び方を整理します。
WireGuard と Tailscale の比較：簡潔な回答
WireGuard と Tailscale の比較は、2 つのプロトコルから選ぶ話ではありません。Tailscale は WireGuard そのものだからです。Tailscale は同じ暗号化と同じトンネルを使用し、さらにコントロールプレーンを追加します。これは公開鍵を交換し、アドレスを割り当て、NAT（network address translation）越えを実現し、アクセスポリシーを適用する調整サーバーです。どの程度の調整機能を自分で運用するかを選ぶことになります。
正直な答えは 3 つあります。1 台のサーバーに少数のクライアントが接続する構成なら、通常の WireGuard を使います。すべてのマシンから他のすべてのマシンへ、維持する設定ファイルなしで到達したいなら、Tailscale を使います。そのメッシュ構成を使いつつ、第三者にノード一覧を保持させたくないなら、Headscale を使います。
コントロールプレーンで実現できること
標準の WireGuard にはディスカバリー機能がありません。各ピアは、公開鍵、AllowedIPs 行、そしてそのピアに到達可能な場合は Endpoint を手動で記述するテキストブロックです。10 台のネットワークに 1 台追加する場合、双方が相手の鍵を必要とするため、10 個の設定ファイルを編集する必要があります。そのため、ほとんどすべてのセルフホスト型 WireGuard 構成はハブアンドスポークになります。公開 IP を持つ 1 台のサーバーと、そのサーバーとのみ通信するクライアントで構成します。
コントロールプレーンを使うと、編集作業が不要になります。各ノードは 1 回登録すると、100.64.0.0/10 CGNAT (carrier grade NAT) 範囲のアドレスを受け取り、通信を許可されたノードの公開鍵を通知されます。トンネルは 2 つのピア間の直接的な WireGuard 接続のままであり、トラフィックが調整サーバーを経由することはありません。サーバーが保持するのはメタデータです。存在するノード、その公開鍵、通信を許可される相手を管理します。
具体的には、次の 3 つが実現します。
NAT traversal。 2 台のノート PC がそれぞれ別の家庭用ルーターの背後にある場合、両者の間に公開 IP はありません。Tailscale は STUN (session traversal utilities for NAT) を使って双方の外部アドレスとポートを検出します。続いて双方が同時にパケットを送信するため、各ルーターは先に送信フローを認識し、応答を受け入れます。これに失敗すると、トラフィックは DERP リレーにフォールバックします。DERP リレーは Tailscale が運用する暗号化リレーです。リレーが鍵を保持することはないため、リレー経由でもデータはエンドツーエンドで暗号化されます。tailscale status を実行すると、各ピアの行に direct または relay と表示されます。tailscale netcheck を実行すると、最寄りのリレーと、ネットワークが UDP を使用できるかどうかを確認できます。
有効期限付きの鍵ローテーション。 WireGuard の鍵には有効期限がありません。3 年前に発行した鍵は、ピアのブロックを手動で削除しない限り、永久に機能します。一方、Tailscale ではノード鍵に有効期限を設定します。2026 年 10 月時点で、新しい tailnet のデフォルトの有効期限は 180 日です。再認証していないマシンは接続できなくなります。サーバーやサブネットルーターなど、ログインできる人がいないデバイスでは、デバイス単位で有効期限を無効にできます。
ルーティングではなくポリシー。 標準の WireGuard では、AllowedIPs がルーティングテーブルとアクセス制御リストを兼ねています。そのため、「alice はデータベースに到達できる」という条件を IP 範囲で表す必要があります。Tailscale では、ユーザー、グループ、タグをルール内で指定する独立したポリシーファイルを使用します。たとえば、tag:laptop がポート 5432 の tag:db にのみ到達でき、それ以外には到達できないというルールを定義できます。このルールは、マシンのアドレスが変更されても維持されます。
コントロールプレーンのコスト
コーディネーションサーバーはネットワークを把握しています。すべてのノードの公開鍵、ノード名、割り当てたアドレス、ポリシーを保持します。ホスト型 Tailscale を利用する場合、そのサーバーは自分で管理できない企業の管理下にあります。WireGuard の秘密鍵は自分のマシンに残るため、パケットの内容をその企業が読み取ることはできません。ただし、ネットワークの構成は把握されます。また、接続できるかどうかは、そのサービスが稼働していることと、アカウントが正常な状態であることに依存します。侵害されたコーディネーションサーバーや盗まれた ID アカウントが、保持している情報を使って実際に何をできるのかを踏まえて、その影響の大きさを判断する必要があります。詳しくは、Tailscale の信頼モデルを詳しく確認してください。
見落としやすい2つ目のコストもあります。Tailscale はすべてのマシンでデーモンとして動作するため、すべてのマシンで継続的にパッチを適用する必要があるソフトウェアが増えます。Ubuntu 24.04 の標準 WireGuard はディストリビューションに含まれるカーネルモジュールで、カーネルとともに更新されます。
3つ目のコストは料金です。2026年10月現在、Personal プランは最大6ユーザーまでユーザーデバイス数無制限で無料です。Standard はユーザー1人あたり月額 $8、Premium はユーザー1人あたり月額 $18 です。家庭での利用は無料のままです。10人のチームでは無料になりません。この上限を超えるかどうかは、基本的にデバイス数ではなくシート数で決まります。ただし、サーバーなどのタグ付きデバイスには別の上限があります。すべてのプランにタグ付きリソース50個が含まれ、2026年10月現在、料金ページには超過分1個あたり月額 $1 と記載されています。7人目のユーザーを招待したり、51台目のサーバーにタグを付けたりする前に、無料プランで実際に利用できる範囲を確認してください。
プレーンな WireGuard が適している場合
トポロジーが実質的にハブアンドスポーク構成であれば、プレーンな WireGuard を選択します。パブリック IP を持つ 1 台の VPS に 3 台または 4 台のデバイスが接続し、デバイス同士が通信する必要がない構成です。設定は 1 画面に収まり、更新が必要な daemon も、失う可能性のあるアカウントもありません。サーバーとの間に外部サービスが入ることもありません。
また、他のすべての仕組みの基盤となる層を理解したい場合にも適しています。VPS で WireGuard VPN をセルフホストするでは、鍵の生成、wg0.conf、IP forwarding、NAT、ハンドシェイクの失敗について説明します。鍵とハンドシェイクはすべての tailnet の下層でも動作しており、tailnet のノードが subnet router または exit node として動作すると、IP forwarding が再び必要になります。古い選択肢も検討している場合は、WireGuard と OpenVPN の比較で OpenVPN が優位性を保つ 4 つのケースを説明しています。
インストールは短い手順で完了します。
sudo apt update && sudo apt install -y wireguard
sudo modprobe wireguard && echo okすべてのデバイスが他のすべてのデバイスに接続する必要がある場合、プレーンな WireGuard は扱いにくくなります。N 台のノードによるフルメッシュには、N × (N - 1) 個の peer ブロックが必要です。6 台のデバイスでは 30 個のブロックを手作業で同期する必要があり、重複した AllowedIPs エントリが、先にそのエントリを持っていた peer から気付かれないままトラフィックを奪います。どこにもエラーは出力されません。
Tailscale が適したケース
マシンの接続場所が変わる場合は、Tailscale を選びます。ホテルのネットワークに接続するノート PC、モバイルデータ通信を使うスマートフォン、管理できないルーターの背後にあるホームサーバーなどです。これらは、どちら側にも Endpoint に設定できる安定した公開エンドポイントがないため、通常の WireGuard では適切に処理できません。
クライアントは、公式インストーラーから 1 つのコマンドでインストールできます。
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale statustailscale up は URL を出力します。その URL を開いてログインすると、マシンが参加します。デーモンが調整サーバーへ発信接続し、その接続を維持するため、コピーする鍵も開放する受信ポートもありません。そのため、ファイアウォールをまったく管理できないネットワークでも Tailscale ノードを動作させられます。
その後、主に 2 つの設定で実用的な機能を利用できます。サブネットルーターを使うと、LAN 全体をネットワークに広告できるため、すべてのデバイスにクライアントをインストールする必要がありません。
echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf
sudo tailscale set --advertise-routes=192.0.2.0/24この経路は、管理コンソールで承認するまで無効です。これは意図した動作です。ノードが単独でネットワークに経路を注入することはできません。Linux クライアントでは sudo tailscale set --accept-routes も必要です。Linux は広告された経路をデフォルトでは受け入れないためです。そのため、サーバー側で承認済みに見える経路でも、設定するまで Linux ノート PC では機能しません。この構成を使用する場合は、VPS でサブネットルーターを実行するで、経路を中途半端に有効にしないための承認手順と転送設定を順に説明しています。
Exit node を使用すると、クライアントの通常のインターネットトラフィック、つまり別の tailnet デバイスや承認済みのサブネット経路宛てではないすべての通信を 1 台のマシン経由で送信できます。これは、一般に「VPN」と呼ばれるフルトンネル動作です。Linux では、広告する前に上記と同じ IP 転送設定が必要です。
sudo tailscale set --advertise-exit-nodeこのフラグは簡単な部分です。VPS を Exit node にするでは、管理コンソールで経路を承認し、その後に DNS と IPv6 の動作を修正する手順を説明しています。これらを修正しないと、トラフィックが誤った経路から送信されます。アクセスしたい対象がネットワーク全体ではなく 1 つの Web サービスであれば、serve と funnelを使って、単一のローカルポートの前段に HTTPS を配置できます。tailnet 内だけに限定することも、公開インターネットに開放することもできます。
Headscale が適している場合
Headscale は協調サーバーのオープンソース実装であり、自分で所有する VPS 上で実行できます。公式の Tailscale クライアントは、ホスト型サービスではなく Headscale を接続先として指定します。
sudo tailscale up --login-server https://headscale.example.comデータパスに関する点は変わりません。引き続き WireGuard を使用し、ネットワークが許せばピア間で直接通信します。変わるのは、ノード一覧、暗号鍵、ポリシーが自分で所有するディスク上の SQLite ファイルに保存される点です。外部の第三者がネットワーク構成を確認したり、アカウントを無効にしたり、ユーザー単位で課金したりすることはありません。
ただし、運用作業は増えます。自分で公開 HTTPS サービスを運用するため、DNS 名、証明書、WebSocket のアップグレードを正しく転送するリバースプロキシが必要です。可用性も自分で維持する必要があります。協調サーバーが停止すると、新しいノードを登録できず、既存のノードも変更を取得できません。Headscale はまだバージョン 1.0 未満であり、マイナーリリースでも互換性を損なう変更が含まれているため、アップグレードの前に必ず変更履歴を確認してください。自分で Tailscale の制御サーバーとして Headscale を運用するでは、インストール、config.yaml、preauth key、開放するポートについて説明しています。
注意すべき点が 1 つあります。Headscale には、Tailscale のグローバルなリレーネットワークは付属しません。2 台のピアが直接接続できない場合は、自分のサーバーで組み込みリレーを有効にするか、設定で別のリレーを指定する必要があります。このリレーは、世界中に展開されたフリートではなく、1 つのリージョンにある 1 台のサーバーです。地球の反対側にいるピアでは、この違いが遅延として現れます。自分でこの構成を組み立てたくない場合は、NetBird をセルフホストする方法もあります。クイックスタートを使うと、管理、シグナル、リレーの各サービスを 1 台の VPS でまとめて起動できるためです。ただし、NetBird は Headscale のような Tailscale のドロップインサーバーではありません。独自のクライアントとポリシーモデルを使用するため、Headscale の代わりに選ぶ前に、アクセスルールとリレーにおける NetBird と Tailscale の違いを確認してください。
1 回で判断する方法
互いに接続する必要があるマシンの数を確認します。すべてのマシンがサーバーとの通信だけを行うなら、同じ結果を得るために必要なソフトウェアが少ない plain WireGuard が適しています。
マシンに安定したパブリックアドレスがあるか確認します。大半が管理していない NAT の背後にあるなら、制御プレーンを使うのが適しています。NAT 越しのホールパンチングが難しい部分であり、その仕組みを自前で再構築する価値はありません。
ネットワークの構成を誰に知られてよいか確認します。外部企業を含めたくない場合、またはユーザー数が多く、ユーザー単位の課金が負担になる場合は、Headscale を運用し、制御サーバーも自分で管理することを受け入れます。課金が移行を後押ししている場合は、移行を決める前に計算してください。実際に規模に応じてチームが支払う金額は、運用するマシンの数よりもアカウントを持つ人数に大きく左右されます。ただし、タグ付きサーバーが各プランに含まれる 50 台を超えるまではその傾向が続きます。この2つの数が近いことはほとんどありません。
考えを変えても、大きな費用はかかりません。3つともデータプレーンに同じプロトコルを使うため、plain WireGuard から調整されたメッシュへ移行する場合は再設計ではなくクライアントのインストールで済みます。Tailscale から Headscale へ移行する場合も、各ノードを別のログインサーバーに対して再登録するだけです。
3 つの方法では得られないもの
3 つともファイアウォールではありません。トンネルはどのパケットを通すかを決めるものであり、どのサービスが待ち受けるかは決めません。トンネル経由で到達できるサーバーは、開放したポートであればインターネットからも到達できます。そのため、VPS 上の UFW ファイアウォールルールを引き続き適用してください。Tailscale のポリシーファイルは、他のノードから到達できる対象を限定しますが、パブリックインターフェースには影響しません。
3 つともサービス単位の認証機能ではなく、接続後にユーザーが実行した操作の監査証跡も提供しません。3 つすべてを通信経路として扱い、ログイン時の確認はアプリケーション側に実装してください。
FAQ
Tailscale は追加手順のある WireGuard にすぎませんか？
Tailscale はデータパスに WireGuard プロトコルを使用するため、暗号化とトンネルは同じです。追加されるのは、鍵交換、アドレス割り当て、STUN と DERP リレーによる NAT トラバーサル、鍵の有効期限、IP 範囲ではなくユーザーを指定するポリシーファイルなどの調整機能です。これらは通常の WireGuard では利用者が管理します。マシンがネットワーク間を移動するようになると、特に管理が難しくなる部分です。
通信は Tailscale のサーバーを経由しますか？
通常は経由しません。調整サーバーがピアを相互に認識させると、ピア同士が直接接続し、tailscale status はそのピア行の direct を示します。直接経路を確立できない場合、通信は DERP リレーにフォールバックし、その行には relay と表示されます。それでも、リレーが運ぶのは暗号化されたパケットであり、WireGuard の秘密鍵を保持することはありません。そのため、内容を読み取ることはできません。tailscale netcheck を実行すると、直接接続に必要な UDP がネットワークでブロックされているか確認できます。
Headscale を公式の Tailscale アプリで使用できますか？
はい。Headscale は同じ制御プロトコルを使用するため、公式クライアントは sudo tailscale up --login-server https://headscale.example.com で参加できます。デスクトップアプリとモバイルアプリでは、カスタムログインサーバーを指定することもできます。ただし、設定場所はプラットフォームごとに異なり、特定のバージョンが必要になる可能性が高いのはモバイルアプリです。ネットワーク全体を移行する前に、1 台のスマートフォンでテストしてください。
Tailscale または Headscale でポートを開く必要はありますか？
Tailscale クライアントは、調整サーバーへ外向きに接続し、その接続を維持するため、受信ポートを必要としません。自己ホスト型の Headscale サーバーでは受信ポートが必要です。制御プロトコルには 443、HTTP-01 証明書チャレンジを使用する場合は 80、組み込みリレーを有効にする場合に限り 3478/udp が必要です。通常 51820 の UDP リッスンポートを使用する通常の WireGuard では、サーバーと、プロバイダーが別途提供するネットワークファイアウォールの両方で、そのポートを開く必要があります。
3 つのうち、最も高速なのはどれですか？
3 つとも WireGuard でパケットを転送するため、スループットは同じです。違いが現れるのは、接続の確立処理と経路品質です。正しく設定した Endpoint の通常の WireGuard は、毎回直接接続します。Tailscale と Headscale はほとんどの場合に直接接続しますが、ネットワークがホールパンチングをブロックするとリレーにフォールバックし、リレー経路では遅延が増加します。tailscale ping <node> で、経路が直接接続かリレー経由かを確認できます。また、トンネル経由で iperf3 を実行して測定することもできます。直接経路なのにその値が回線速度を大幅に下回る場合、問題の原因は 3 つの方式の選択ではありません。通常の原因はパス MTU の不一致です。これは制御プレーンの有無にかかわらず、同じように発生します。