WireGuardとTailscaleとHeadscaleの違いと選び方

WireGuard と Tailscale の比較: 簡単な結論

WireGuard と Tailscale の比較は、2 つのプロトコルから選ぶ話ではありません。Tailscale は WireGuard そのものです。Tailscale は同じ暗号化方式と同じトンネルを使用し、さらにコントロールプレーンを追加します。コントロールプレーンは、公開鍵を交換し、アドレスを割り当て、NAT（network address translation）越しに通信経路を確立し、アクセス制御ポリシーを適用する調整サーバーです。どの程度の調整機能を自分で運用するかを選ぶことになります。

率直な答えは 3 つあります。1 台のサーバーに少数のクライアントが接続する構成なら、通常の WireGuard を使います。すべてのマシンから他のすべてのマシンへ接続でき、維持する設定ファイルをなくしたいなら、Tailscale を使います。そのメッシュ構成が必要で、ノード一覧を第三者に保持させたくないなら、Headscale を使います。

コントロールプレーンが実際にもたらすもの

Plain WireGuard にはサービスディスカバリ機能がありません。各ピアは、公開鍵、AllowedIPs 行、到達可能なピアであれば Endpoint を手作業で記述したテキストブロックです。10 台のネットワークに 1 台追加する場合、両側で相手の鍵が必要になるため、10 個の設定ファイルを編集する必要があります。そのため、ほとんどの自己ホスト型 WireGuard 構成はハブアンドスポークになります。公開 IP を持つ 1 台のサーバーと、そのサーバーとのみ通信するクライアントで構成します。

コントロールプレーンを使うと、編集作業が不要になります。各ノードは 1 回登録すると、100.64.0.0/10 CGNAT (carrier grade NAT) のアドレス範囲からアドレスを受け取り、通信を許可されたノードの公開鍵を取得します。トンネルは引き続き 2 つのピア間の直接的な WireGuard 接続であり、ネットワークトラフィックが調整サーバーを経由することはありません。サーバーが保持するのはメタデータです。存在するノード、その公開鍵、相互の通信を許可された組み合わせを管理します。

そこから、具体的に 3 つの機能が得られます。

NAT トラバーサル。 2 台のノート PC が 2 台の家庭用ルーターの背後にある場合、両者の間に公開 IP はありません。Tailscale は STUN (session traversal utilities for NAT) を使用して双方の外部アドレスとポートを検出します。続いて双方が同時にパケットを送信するため、各ルーターは最初に送信フローを認識し、その応答を受け入れます。これに失敗すると、トラフィックは DERP リレーにフォールバックします。これは Tailscale が運用する暗号化リレーです。リレーが鍵を保持しないため、リレー経由でもデータはエンドツーエンドで暗号化されたままです。tailscale status を実行すると、各ピア行に direct または relay と表示されます。tailscale netcheck を実行すると、最寄りのリレーと、ネットワークで UDP が利用可能かどうかを確認できます。

有効期限付きの鍵ローテーション。 WireGuard の鍵には有効期限がありません。3 年前に発行した鍵は、ピアブロックを手作業で削除しない限り永久に機能します。一方、Tailscale ではノード鍵に有効期限を設定します。2026 年 7 月時点で、新しい tailnet のデフォルトの有効期限は 180 日です。再認証していないマシンは接続できなくなります。サーバーやサブネットルーターのように、ログインできる担当者がいないデバイスでは、デバイス単位で有効期限を無効にできます。

ルーティングではなくポリシー。 Plain WireGuard では、AllowedIPs がルーティングテーブルとアクセス制御リストを兼ねています。そのため、「alice はデータベースに到達できる」という許可を IP 範囲で表す必要があります。Tailscale では、ユーザー、グループ、タグを指定する個別のポリシーファイルを使用します。例えば、tag:laptop がポート 5432 の tag:db にだけ到達でき、それ以外には到達できないというルールを設定できます。このルールは、マシンに新しいアドレスが割り当てられても維持されます。

コントロールプレーンにかかるコスト

コーディネーションサーバーはネットワークを把握しています。すべてのノードの公開鍵、ノード名、割り当てたアドレス、ポリシーを保持します。ホスト型 Tailscale を使う場合、そのサーバーは管理下にない企業のものです。WireGuard の秘密鍵は各マシンに残るため、企業側がパケットを読み取ることはできません。しかし、ネットワークの構成は企業側から見えます。また、接続できるかどうかは、そのサービスが稼働していることと、アカウントが有効な状態にあることに依存します。この点をどの程度重視するかは、コーディネーションサーバーが侵害された場合や、認証情報のアカウントを盗まれた場合に、保持している情報を使って実際に何ができるかで決まります。詳しくはTailscale の信頼モデル全体を読む価値があります。

見落としやすい2つ目のコストもあります。Tailscale はすべてのマシンでデーモンとして動作するため、すべてのマシンでパッチを適用し続けるソフトウェアが増えます。Ubuntu 24.04 の標準 WireGuard はディストリビューションに含まれるカーネルモジュールであり、カーネルとともに更新されます。

3つ目のコストは料金です。2026年7月時点で、Personal プランは最大6ユーザーまでデバイス数無制限で無料です。Standard はユーザー1人あたり月額 $8、Premium はユーザー1人あたり月額 $18 です。世帯で使う場合は無料のままです。10人のチームでは無料になりません。この境界を超えるかどうかはデバイス数ではなくシート数で決まります。7人目のユーザーを招待する前に、無料プランに実際に含まれる内容を確認してください。

プレーンな WireGuard が適している場合

トポロジーが実際にハブアンドスポーク型である場合は、プレーンな WireGuard を選択します。パブリック IP を持つ VPS が 1 台あり、3 台または 4 台のデバイスがそこへ接続し、それらのデバイス同士が通信する必要がない構成です。設定は 1 画面に収まり、更新が必要なデーモンも、失う可能性のあるアカウントもありません。外部サービスが自分とサーバーの間に入ることもありません。

すべての基盤となるレイヤーを理解したい場合にも適しています。VPS で WireGuard VPN をセルフホストするでは、鍵の生成、wg0.conf、IP 転送、NAT、ハンドシェイクの失敗について説明します。これらの仕組みは、tailnet の下層でもすべて動作しています。従来の選択肢も比較検討している場合は、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、モバイルデータ通信を使うスマートフォン、管理権限のないルーターの背後にあるホームサーバーなどです。これらは、通常の WireGuard では扱いにくいケースです。双方に、Endpoint に設定できる安定したパブリックエンドポイントがないためです。

クライアントは、公式インストーラーから次の1コマンドでインストールできます。

curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale status

tailscale 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 でサブネットルーターを実行する で、半端な状態のルートを避けるための承認手順と転送設定を順に説明しています。

出口ノードを使うと、クライアントのすべてのネットワークトラフィックを1台のマシン経由で送信できます。これは、一般に「VPN」で想定されるフルトンネル動作です。

sudo tailscale set --advertise-exit-node

このフラグの設定自体は簡単です。続く作業については、VPS を出口ノードにする で説明しています。管理コンソールでルートを承認し、その後、トラフィックが誤った経路から送信されないよう DNS と IPv6 の動作を修正します。到達したい対象がネットワーク全体ではなく1つの Web サービスなら、serve と funnel を使って、単一のローカルポートの前段に HTTPS を配置できます。tailnet 内だけで公開することも、パブリックインターネットに公開することも可能です。

Headscale が適した選択肢となる場合

Headscale は coordination server のオープンソース実装で、所有する VPS 上で実行できます。公式の Tailscale クライアントは、ホスト型サービスではなく Headscale を接続先として指定します。

sudo tailscale up --login-server https://headscale.example.com

データパスは変わりません。引き続き WireGuard を使用し、ネットワークが許せばピア間で直接通信します。変わるのは、ノード一覧、暗号鍵、ポリシーが、所有するディスク上の SQLite ファイルに保存される点です。外部の第三者にネットワーク構成を見られたり、アカウントを無効化されたり、ユーザー数に応じて課金されたりすることはありません。

ただし、運用作業が必要になります。公開 HTTPS サービスを運用するため、DNS 名、証明書、WebSocket のアップグレードを正しく中継するリバースプロキシが必要です。可用性も自分で管理します。coordination server が停止すると、新しいノードを登録できず、既存のノードも変更を取得できません。Headscale はまだ version 1.0 未満で、マイナーリリースでも互換性を損なう変更が含まれてきました。そのため、アップグレードの前に必ず changelog を確認してください。Headscale を独自の Tailscale control server として運用する では、インストール、config.yaml、preauth keys、開放するポートについて説明しています。

見落とされやすい注意点があります。Headscale には Tailscale のグローバルな relay network が付属しません。2 つのピアが直接接続できない場合は、自分のサーバーで組み込み relay を有効にするか、別の relay を設定で指定します。この relay は世界中に分散した fleet ではなく、1 つのリージョンにある単一のサーバーです。地球の反対側にいるピアでは、この違いが通信性能に現れます。この部分を自分で構築したくない場合は、NetBird を self-hosting する という別の方法があります。NetBird の quickstart では、management、signal、relay の各サービスを 1 台の VPS 上でまとめて起動できます。

一度で判断する方法

相互に接続する必要があるマシンの台数を確認します。すべてのマシンがサーバーとのみ通信する構成であれば、同じ結果を得るために必要なソフトウェアが少ない plain WireGuard が適しています。

マシンに安定したパブリックアドレスがあるか確認します。大半が管理していない NAT の背後にある場合は、control plane が必要です。難しいのは NAT 越えであり、この機能を自前で再構築する価値はありません。

ネットワーク構成を把握できる対象を確認します。外部企業に知られることを避けたい場合や、ユーザー数が多く、ユーザー単位の課金が負担になる場合は、Headscale を運用します。その場合は、自分で control server を管理する必要があります。課金が移行を促す主な理由であれば、移行を決める前に計算してください。実際に同じ規模のチームが支払う金額は、運用するマシン数ではなく、アカウントを持つ人数で決まるためです。この2つの数は、ほとんどの場合一致しません。

判断は簡単に変えられます。3つの構成はすべて同じプロトコルを data plane に使用するため、plain WireGuard から協調型メッシュへ移行する場合は、設計をやり直すのではなくクライアントをインストールします。Tailscale から Headscale へ移行する場合も、各ノードを別の login server に対して再登録するだけです。

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 をネットワークがブロックしているか確認できます。

公式の Tailscale アプリで Headscale を使用できますか？

はい。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 の不一致です。これは制御プレーンの有無にかかわらず同じように発生します。