Tailscaleとは？仕組みとWireGuardの接続方法

Tailscale とは

Tailscale は、すべてのトラフィックを自分で運用する 1 つのゲートウェイ経由でルーティングするのではなく、マシン同士を直接接続する VPN です。各ノードで WireGuard が動作するため、パケットはサーバー間を暗号化された状態で転送され、経路上の何者も内容を読み取れません。ホスト型の調整サーバーが接続先の情報交換を処理します。公開鍵を保存して各ノードに配布し、他のノードの接続先を各ノードに通知します。また、作成したアクセスルールも各ノードに配布します。

この分離が設計の全体です。データプレーンはピアツーピアで、ノード間で暗号化されます。コントロールプレーンは Tailscale が代わりに運用するサービスです。信頼に関する扱いにくい問題を含め、Tailscale に関する重要な疑問は、すべてこの 2 つの事実から生じます。すでに VPS 上で WireGuard VPN を手動構築している場合、Tailscale は同じトンネルに鍵の配布とファイアウォール越えを組み込んだものです。

Tailscale はどのように動作しますか？

ノードで構成するプライベートネットワークを tailnet と呼びます。マシンが tailnet に参加すると、次の 4 つの処理が行われます。

1. tailscaled デーモンが起動し、WireGuard の鍵ペアを生成して、状態を /var/lib/tailscale/tailscaled.state に保存します。秘密鍵はそのマシンに残ります。Tailscale は「秘密鍵がそのノードから出ることは決してない」と明確に説明しています。
2. ノードは調整サーバーにログインし、公開鍵と、自身に到達できると判断したアドレスを送信します。Tailscale はこのサーバーを「公開鍵を共有するドロップボックス」と説明しています。
3. 調整サーバーはネットワークマップを返します。このマップには、各ノードの公開鍵、tailnet アドレス、マシン名、およびこのノードから接続を許可されている各ノードの候補エンドポイントが含まれます。
4. 各ノードのペアは、相互間に直接 WireGuard トンネルを構築しようとします。失敗した場合は、リレーを介してパケットを転送します。

各ノードには、100.64.0.0 から 100.127.255.255 までのキャリアグレード NAT 用のアドレス範囲である 100.64.0.0/10 から、固定アドレスが割り当てられます。Tailscale がこの範囲を使用するのは、プロバイダーのインフラストラクチャ用に予約されており、サーバーがすでに使用しているプライベートアドレスと競合することが少ないためです。Linux では、トンネルは tailscale0 という名前のインターフェースとして表示されます。

WireGuard の実装はカーネルモジュールではなく、ユーザー空間の tailscaled に組み込まれています。そのため、sudo modprobe wireguard が Operation not supported で失敗するコンテナ仮想化環境でも Tailscale を起動できます。一方、同じマシン上でのスループットの上限は、カーネル版 WireGuard より低くなります。これは、Tailscale と通常の WireGuard の違いで説明するトレードオフの 1 つです。

現在の接続状況は、次の 2 つのコマンドで確認できます。

tailscale ip -4
tailscale status

tailscale status はノードごとに 1 行を表示します。重要なのは最後の列です。

100.101.102.103  web-1      you@  linux  -
100.101.102.104  db-1       you@  linux  active; direct 198.51.100.24:41641
100.101.102.105  ci-runner  you@  linux  active; relay "fra"

direct の後にアドレスとポートが表示される場合、2 台のマシンが相互への経路を確立しており、トラフィックはピア間で直接転送されています。relay "fra" は、フランクフルトの Tailscale リレーを経由していることを示します。- は、そのノードとのアクティブなセッションが現在ないことを示します。これは正常な状態です。

コーディネーションサーバーから見える情報と見えない情報

コーディネーションサーバーは公開鍵とメタデータを保持します。マシン名、各ノードを所有するユーザーまたはタグ、各ノードの tailnet アドレス、ノードが到達可能な公開アドレス、各ノードが最後にオンラインになった時刻、作成したポリシーファイルを把握しています。これはフリート全体の完全な構成情報です。

秘密鍵は保持しないため、2 台のノード間のトラフィックを復号できません。暗号化は WireGuard ピア間でエンドツーエンドに行われ、コーディネーションサーバーはピアではありません。

コーディネーションサーバーが実行できるのは、鍵を配布することです。ホスティング型でも自分で運用するものでも、すべてのコーディネーションサーバーは、tailnet に属する公開鍵を各ノードへ通知する役割を信頼されています。これが後述する脅威モデルの要点であり、自分でホストするオープンソースのコーディネーションサーバーである Headscale が存在する理由です。

異なるファイアウォールの背後にある 2 台のサーバーが直接通信する方法

NAT（ネットワークアドレス変換）により、多数のマシンで 1 つのパブリックアドレスを共有できます。通常、VPS には専用のパブリックアドレスがあります。しかし、tailnet に追加したい他のマシンには、専用のパブリックアドレスがないことがよくあります。たとえば、自宅のサーバー、オフィスネットワーク上のビルドランナー、変更できないプロバイダーのファイアウォールの背後にあるマシンなどです。

Tailscale は、STUN（NAT traversal 用のセッションユーティリティ）と ICE の標準に基づく技術を使用して経路を見つけます。各ノードは STUN サーバーに小さな UDP パケットを送信し、そのソケットにルーターが割り当てたパブリックアドレスとポートを取得します。両方のノードが候補を coordination server に報告し、coordination server が相手側へ渡します。その後、両方のノードが同時に相手へパケットを送信し始めます。各ルーターは先に送信パケットを確認するため、マッピングを作成し、同じアドレスから到着した応答を受け入れます。どちらの側にも受信ファイアウォールルールは必要ありません。

使用するポートは決まっています。直接接続する WireGuard トンネルは UDP を使用し、送信元ポートのデフォルト値は 41641 です。STUN は UDP 3478 を使用して Tailscale の relay servers と通信します。control connection と中継データは TCP 443 の HTTPS を使用します。ほとんどの場合、受信ポートを開く必要はありません。ただし、NAT の動作が複雑なネットワークでは、UDP 41641 の受信を許可すると直接接続しやすくなります。

tailscale netcheck

そのレポートの 2 行を確認してください。UDP: true は UDP がマシンから送信されることを示し、UDP: false はこのノードからのすべての接続が中継されることを示します。MappingVariesByDestIP: true は、ルーターが宛先ごとに異なるパブリックポートを割り当てることを示します。そのため、前述のアドレス予測は機能せず、通常これらのノードは中継接続のままになります。

Tailscale が DERP リレーを使用する場合

DERP（designated encrypted relay for packets）はフォールバックとして使用されます。Tailscale は複数のリージョンでリレーを運用しており、TCP 443 で接続できます。直接経路を確立できないノードは、そのリレーを経由して WireGuard パケットを送信します。

パケットは暗号化されたままです。Tailscale は次のように明記しています。「DERP サーバーが通信を復号する方法は決してありません。DERP サーバーは、暗号化済みの通信を一方のノードから別のノードへそのまま転送するだけです。」リレーから見えるのは暗号文と、どのノードがどのノードと通信しているかです。

ほとんどの接続では、最初のパケットもリレーを経由します。直接経路の確立には少し時間がかかるため、セッションはリレー経由で開始され、2 つのノードが互いの経路を見つけると、その場で直接接続へ切り替わることがよくあります。この切り替えは確認できます。

tailscale ping db-1

最初の応答は via DERP(fra) で返り、その後の行で via 198.51.100.24:41641 のような状態が報告されます。この変化が、直接トンネルへの切り替えです。変化しない場合は、両端で tailscale netcheck を実行します。リレー経由の経路でも通信は継続できます。ただし、すべてのパケットが別のマシンを経由するため、迂回が発生し、遅延が増えます。

VPS を tailnet に追加する

インストールスクリプトは Ubuntu と Debian に対応しています。

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

sudo tailscale up は URL を出力します。その URL を開いて認証すると、ノードが管理コンソールに表示されます。次に再起動後もデーモンが復帰することを確認してください。この手順は省略されがちです。

sudo systemctl is-enabled tailscaled
tailscale status

is-enabled は enabled を出力し、tailscale status には新しいノードとその 100.x アドレスが表示されます。スクリプトで構築したサーバーでは、対話式の URL は使えません。管理コンソールで認証キーを生成し、このマシンの種類を示すタグとともに渡します。

sudo tailscale up --auth-key=tskey-auth-REPLACE-ME --advertise-tags=tag:server

タグ付きノードは、コマンドを実行したユーザーではなくタグに所有されます。そのため、そのユーザーのアカウントが削除された後も動作します。先にポリシーファイルの tagOwners でタグを宣言する必要があります。宣言していない場合、コマンドは拒否されます。タグ付けは、プラン上でのマシンの扱いも変えます。タグ付きリソースはユーザー自身のデバイスとは別に料金が計算されるためです。無料プランで実際に利用できる範囲では、これらの制限について説明しています。

複数のマシンを管理する場合は、2 つの設定が重要です。ノードキーはデフォルトで 180 日後に期限切れになります（2026 年 8 月時点）。キーが期限切れになると、再度ログインするまで「指定されたエンドポイントとの接続が停止します」。そのため、無人運用のサーバーでは、管理コンソールで対象マシンの行を開き、Disable Key Expiry を選択します。2022 年 10 月 20 日以降に作成された tailnet では、MagicDNS がデフォルトで有効です。MagicDNS により、各ノードには db-1.yak-bebop.ts.net のような名前が付与され、100.100.100.100 のスタブリゾルバーで解決されます。アドレスではなく名前を使用してください。ノードを再構築するとアドレスは変わりますが、名前は維持されるためです。

apt またはリポジトリでインストールに失敗する場合は、Ubuntu でよくある Tailscale のインストールエラーで対処方法を確認してください。

localhost にバインドされたサービスへの接続

ここで tailnet が役立ちます。一方で、つまずきやすい箇所でもあります。tailnet に参加しただけでは、loopback サービスに接続できません。

ss -tlnp | grep 3000

この出力が 127.0.0.1:3000 なら、そのソケットは宛先が 127.0.0.1 のパケットだけを受け付けています。別のノードからのリクエストは、このノードの 100.x アドレス宛てに到着します。そのため、kernel はそのリクエストを受け付けるリスナーを見つけられず、TCP reset を返します。クライアントには Connection refused と表示されます。トンネルには問題ありません。問題はリスナーにあります。

確実な解決方法は 2 つあります。1 つ目は、サービスをノードの tailnet アドレスにバインドする方法です。これにより、プロキシを介さずにパブリックインターフェイスからサービスを隔離できます。--bind 100.101.102.104 または設定内の同等のオプションを指定し、コンテナの場合はポートを -p 100.101.102.104:3000:3000 として公開します。2 つ目は、サービスを loopback 上に残したまま、Tailscale を前段に置く方法です。

tailscale serve 3000

これにより、リクエストは http://127.0.0.1:3000 にプロキシされます。tailnet の HTTPS 証明書を有効にすると、tailnet 内で ts.net という名前による HTTPS サービスとして利用できます。接続は自分のノードだけに限定されます。同じ構成をパブリックに提供する機能が Funnel です。どちらを使うべきかは、Tailscale serve と funnel の使い分けで説明しています。

関連する 2 つの用途には、それぞれ専用のページがあります。Tailscale がインストールされていないプライベートネットワーク全体に接続するには、VPS 上の subnet router が必要です。ノードの外向きインターネットトラフィックを別のノード経由で送信するには、exit node を使用します。

不要になったポートを閉じる

すべての管理者が tailnet 経由でサーバーに接続できるようになったら、公開ポート 22 は不要です。これが実際の効果です。閉じたポートはブルートフォース攻撃の対象にならず、ログに攻撃試行が記録され続けることもありません。

手順の順序が重要です。まず tailnet 経由のアクセスを追加し、2 つ目のセッションからその経路でログインできることを確認します。その後で、公開ルールだけを削除します。

sudo ufw allow in on tailscale0
sudo ufw status verbose

その後、公開 SSH ルールを削除し、MagicDNS 名を使用して再接続します。ufw allow in on tailscale0 が実際に行うことに注意してください。これはトンネル経由で到着するすべての通信を信頼するため、ufw の代わりに Tailscale のポリシーファイルがアクセス制御を担います。この点を考慮してポリシーを記述してください。

コンテナを運用している場合は注意が必要です。公開された Docker ポートは独自の NAT ルールを追加し、ufw を迂回するため、ufw deny では閉じられません。仕組みについては ufw を迂回する Docker の公開ポート を参照してください。前述のように tailnet アドレスへ公開すれば、この問題を回避できます。

Tailscale が保護するものと、保護しないもの

この点は明確にしておく必要があります。マーケティング上の説明では、両者の違いが曖昧になりがちです。

保護されるもの: 2 つのノード間のトラフィックは WireGuard によりエンドツーエンドで暗号化されるため、途中のリレーは内容を読み取れません。秘密鍵が、生成したマシンの外に出ることもありません。ノードでインバウンドの公開ポートを開く必要がないため、インターネットから 22 や 5432 をスキャンされることもありません。ノード間のアクセスは、アドレスを知っている人ではなく、ポリシーファイルによって決まります。

保護されないもの: コーディネーションサーバーは、デバイスの構成情報を把握します。このメタデータ自体が機密情報です。マシン名、所有者、アドレス、オンラインになった時刻から、インフラの構成が分かるためです。また、コーディネーションサーバーは鍵も配布するため、こちらのほうが重大なリスクです。Tailscale は次のように明言しています。「Tailscale が悪意を持ち、ネットワークに新しいノードをひそかに追加した場合、Tailscale は既存のノードとの間で平文のトラフィックを送受信できる可能性があります。」シングルサインオンプロバイダーも同じ信頼経路に含まれます。そこで ID を発行できる人は、ノードを追加できるためです。また、侵害されたノードは tailnet 内のピアです。そのノードが次に到達できる範囲は、ポリシーで許可されている範囲になります。これが許容できるリスクかどうかは、誰から防御するのかによって異なります。完全な信頼モデルでは、盗まれた ID アカウントで実際に何ができるかを含め、これらのケースを順に説明しています。

鍵の配布リスクには、2 つの対策があります。1 つ目は tailnet lock です。これは、既存の信頼済みノードが新しいノードに暗号学的な署名を付けるまで、他のノードがその新しいノードを受け入れないようにします。有効な署名なしでノードを追加するコントロールプレーンは無視されます。管理コンソールは、署名ノード用の正確な tailscale lock init 行を生成します。各ノードは、自分が確認した内容を検証できます。

tailscale lock status

すべてのノードが、同じ信頼済み署名鍵の集合を報告する必要があります。2 つ目の対策は、コントロールプレーンを自分で運用することです。セルフホスト型 Headscale コーディネーションサーバーは、同じクライアントに対して同じプロトコルで通信します。これにより、デバイスの構成情報と鍵の配布を、自分が所有するハードウェア上に移せます。そのサーバーの稼働時間も、自分で維持することになります。まだこの方式に決めず、セルフホスト型のコントロールプレーンを比較している場合は、NetBird は、サーバーを 1 台の VPS 上で最初から最後まで自分で運用する別のメッシュ VPN です。

初日に変更すべきデフォルト設定が 1 つあります。新しい tailnet は、デフォルトでは許容的な設定です。「デフォルトの tailnet ポリシーファイルでは、tailnet 内のすべてのデバイス間の通信が有効になります。」acls セクションを追加すると、モデルはデフォルト拒否に切り替わり、自分で定義したルールだけが通過します。

{
  "tagOwners": {
    "tag:server": ["autogroup:admin"]
  },
  "acls": [
    {"action": "accept", "src": ["autogroup:member"], "dst": ["tag:server:22"]}
  ]
}

このポリシーでは、tailnet のメンバーはタグ付きサーバーの SSH にアクセスできますが、それ以外にはアクセスできません。ワイルドカードを残さず、サービスごとにルールを追加してください。ワイルドカードを使うと、盗まれたラップトップの鍵からデータベースに到達できてしまうためです。

失敗パターンと表示される文字列

tailscale status は常に relay と表示されます。 2 台のノード間に直接経路が確立されていません。両端で tailscale netcheck を実行します。UDP: false は外向きの UDP がブロックされていることを示すため、リレー経由でしか通信できません。MappingVariesByDestIP: true は厳格な NAT が間にあることを示します。管理下にある側で受信 UDP 41641 を許可すると、多くの場合は解決します。

数か月間動作していたノードが消えました。 ノードキーがデフォルトの 180 日で期限切れになっています。管理コンソールではマシンが期限切れとして表示され、マシン上で sudo tailscale up を実行すると復旧します。再発を防ぐため、サーバーではキーの有効期限を無効にします。

ピアは一覧に表示されますが、接続がタイムアウトします。 接続性は確保されており、ポリシーがトラフィックを拒否しています。acls セクションで、この送信元、宛先、ポートを対象とするルールを確認します。拒否されたパケットは応答されずに破棄されるため、Connection refused ではなくタイムアウトになります。

MagicDNS の名前を解決できません。 ping db-1 は失敗しますが、ping 100.101.102.104 は成功します。何らかの処理によって /etc/resolv.conf が置き換えられたため、クエリが 100.100.100.100 のスタブリゾルバーに到達していません。cat /etc/resolv.conf で 100.100.100.100 を確認し、そのファイルを書き込むマシン上の他の処理も調べます。これは WireGuard トンネル内で DNS が機能しない 場合と同じ種類の問題です。

tailscale up がタグを拒否します。 ポリシーファイルの tagOwners にそのタグが宣言されていません。そこに追加してから、コマンドを再度実行します。

FAQ

Tailscale は VPN ですか、それともメッシュネットワークですか？

どちらの表現も正しく、異なる層を説明しています。トンネルには WireGuard を使用するため、VPN です。各ノードは、通信する相手ごとに中央サーバーを経由せず直接トンネルを構築するため、トポロジーはメッシュです。コーディネーションサーバーはデータパスではなくコントロールパスに位置します。そのため、コーディネーションサーバーに到達できなくなっても、既存のトンネルによる通信は継続します。停止するのは、障害中の新しいノードの参加と、鍵やポリシーの変更の反映です。

Tailscale は通信内容を読み取れますか？

通信内容は読み取れません。WireGuard によりノード間でエンドツーエンド暗号化され、秘密鍵がノードの外へ出ることはありません。DERP リレーも、復号できないパケットを転送するだけです。ただし、Tailscale はメタデータを確認できます。対象には、マシン名、所有者、公開鍵、エンドポイントアドレス、各ノードのオンライン状態の時刻が含まれます。また、Tailscale は鍵も配布するため、侵害されたコーディネーションサーバーが、フリートから信頼されるノードを挿入しようとする可能性があります。Tailnet lock は、独自の信頼済みノードによる署名を要求することでこれを防ぎます。Headscale を使えば、ホスト型のコントロールプレーンを構成から外せます。

Tailscale 用にファイアウォールのポートを開く必要はありますか？

インバウンド通信については、ほとんどありません。Tailscale の公式ガイダンスでは、「ほとんどの場合、ファイアウォールのポートを開く必要はありません」とされています。アウトバウンド通信では、ノードにコーディネーションサーバーおよびリレーへの TCP 443 と、STUN 用の UDP 3478 が必要です。直接トンネルでは、デフォルトで 41641 の送信元ポートを使用する UDP が使われます。インバウンドで UDP 41641 を許可するかどうかは任意です。許可すると、接続が難しいネットワークで直接接続を確立しやすくなるだけです。

他のノードからポート 3000 のサービスに接続できないのはなぜですか？

まず ss -tlnp でバインドアドレスを確認します。127.0.0.1:3000 で待ち受けているリスナーは、ノードの 100.x tailnet アドレス宛てに到着した接続を拒否します。このソケットはループバック宛ての接続だけを受け付けるため、クライアントには Connection refused が表示されます。サービスを tailnet アドレスにバインドするか、tailscale serve 3000 を実行してプロキシします。リスナーがすでに 0.0.0.0 で待ち受けていて、接続が拒否されずタイムアウトする場合は、バインドアドレスではなく、ポリシールールまたはホストのファイアウォールが原因です。

Tailscale のコーディネーションサーバーではなく Headscale を実行すべきですか？

デバイスグラフまたは鍵の配布を自分で管理するインフラに置く必要がある場合や、外部サービスに依存せず tailnet を動作させる必要がある場合は、Headscale を実行します。クライアントとプロトコルは同じです。その代わり、コーディネーションサーバーを自分で運用する必要があります。また、その障害中は新しいノードが参加できず、ポリシーの変更も適用されません。小規模なフリートでは、tailnet lock を有効にしたホスト型コントロールプレーンのほうが、通常は適切な選択です。