Tailscaleは安全ですか？信頼モデルと注意点

Tailscale は安全ですか？ 短い答え

Tailscale は安全ですか？ 多くの人が懸念する点について言えば、安全です。tailnet を管理する coordination server が、通信を暗号化する private key を保持することはありません。そのため、デバイス間で送受信される内容を読み取ることはできません。Tailscale のセキュリティページにも、次のように明記されています。「Private key がデバイスの外部に出ることはありません。すべての通信は常に end-to-end で暗号化されます。」ただし、重要なのは別の点です。coordination server が侵害された場合や、法的命令に基づく要求を受けた場合でも、パケットの内容を読み取る必要はありません。デバイスが信頼する public key を決定できるため、承認していないデバイスを登録できる可能性があります。

これが信頼モデルの要点です。暗号化はデータを保護し、control plane はメンバーシップを決定します。以下の各セクションでは、信頼する必要がある主体、その主体が実際に実行できる操作、およびそれを制限する制御について説明します。Tailscale 自体が初めての場合は、まずTailscale の概要と mesh の仕組みを確認してください。

コントロールプレーンとデータプレーンは分離されています

Tailscale は WireGuard を基盤とするメッシュ VPN（仮想プライベートネットワーク）です。これは、自分でホストする WireGuard VPSで手動設定するプロトコルと同じです。各デバイスは、WireGuard の鍵ペアをローカルで生成します。Tailscale の動作の仕組みでは、コーディネーションサーバーを「公開鍵用の共有ドロップボックス」と表現し、「秘密鍵がそのノードから外に出ることは決してありません」と説明しています。

データプレーンは、デバイス間で暗号化されたネットワークトラフィックです。ネットワークが許せば、デバイスからデバイスへ直接送信されます。コントロールプレーンは、それ以外のすべてです。tailnet に属するデバイス、各デバイスに対応する公開鍵、アクセスポリシー、DNS 設定、リレー一覧などが含まれます。Tailscale は、ホスト型サービスとしてコントロールプレーンを運用します。データプレーンは、自分のマシン上で運用します。

この2つを分けて考えると、ここで生じるセキュリティ上の疑問にすべて答えられます。暗号化は、データプレーンの性質です。メンバーシップは、コントロールプレーンが決定します。どれほど暗号化しても、どのデバイスがピアとして許可されているかは分かりません。

調整サーバーが侵害された場合、何が可能になるか

通信を復号することはできません。 暗号化を行う鍵はデバイス上で生成され、アップロードされることはありません。そのため、トンネルを開く鍵を奪取または漏えいさせることはできません。これは、後述する中継通信にも当てはまります。

ノードを登録することは可能です。 Tailscale が tailnet lock を発表した際、同社はリスクを次のように説明しました。悪意のあるサーバーは「密かに追加したノードを使って、既存のノードとの間で通信を送受信できる」可能性があります。その場合、「通信が暗号化されていても意味がない。接続相手自体が悪意のあるものだから」です。デバイスがピアを信頼するのは、コントロールプレーンから、その鍵が tailnet に属すると通知されるためです。

デバイスが到達できる対象を変更することは可能です。 アクセスポリシーはコントロールプレーンに保存され、ノードへ配布されます。Tailscale の tailnet lock ホワイトペーパー には、tailnet lock は「新しいノード鍵の配布を停止したり、すべてのノードへのアクセスを拒否するアクセス制御ポリシーを配布したりすることで、侵害されたコントロールプレーンがネットワークの接続性を損なうことを防止しない」と記載されています。

いずれにしても接続メタデータは確認できます。 Tailscale のネットワークフローログには、マシン間のすべての接続について、開始イベントと終了イベントが記録されます。ドキュメントには、これらのログには「クライアントの操作やネットワークトラフィックの内容に関する情報は一切含まれない」と明記されています。したがって、コントロールプレーンは、どのデバイスがどのデバイスと、いつ通信したかを把握できます。通信内容は把握できません。

この一覧で暗号化に関係するのは1項目だけです。残りは、誰がメンバーで、ポリシーが何を許可するかに関するものです。そのため、注意すべき制御は、ノードの登録を管理するものです。

tailnet の信頼の起点は ID プロバイダーです

Tailscale は独自のパスワードデータベースを持ちません。ドキュメントにも、Tailscale のパスワードは存在せず、サインインは ID プロバイダー（IdP）に委任されると明記されています。対象は Apple、Google、GitHub、Microsoft、Okta、OneLogin、またはカスタム OpenID Connect プロバイダーです。

これはセキュリティ上の説明でもあるため、そのように理解してください。Google または Microsoft アカウントにサインインできる人は、あなたの tailnet にもサインインできます。多要素認証（MFA）は、IdP が適用するものに依存します。オフボーディングも、その人が退職したときに IdP が実行する処理に依存します。フィッシングで IdP アカウントを奪われると、そのアカウントは tailnet のアカウントになります。攻撃者は WireGuard を攻撃する必要はありません。デバイスを追加するだけで、そのユーザーに付与されたポリシーをそのまま引き継げます。

盗まれた ID アカウントと、tailnet 内で動作するデバイスの間には、デバイス承認とキーの有効期限という2つの制御があります。Tailnet lock は3つ目の制御であり、アカウントではなくコントロールプレーンを対象とします。

デバイス承認: 人が許可するまで何も参加しない

Tailscale のドキュメントでは、デバイス承認を「Tailscale ネットワーク管理者が、新しいデバイスの Tailscale ネットワークへの参加を許可する前に確認して承認できる」機能と説明しています。Owner、Admin、または IT admin が承認できます。新しいデバイスには、誰かが操作するまで Machines ページに「Needs approval」バッジが表示されます。

この機能を有効にすると、アカウントを盗まれた場合の状況が変わります。攻撃者がサインインしてデバイスを登録しても、そのデバイスは何にもアクセスできないまま待機します。同時に管理コンソールには、認識していないマシンが参加を要求していることを示すバッジが表示されます。自動化も引き続き利用できます。auth key の生成時に事前承認済みとして設定でき、API からデバイスを承認することもできます。

auth key はもう 1 つの侵入経路であるため、認証情報として扱ってください。Tailscale のドキュメントは、危険性の高い種類について明確に警告しています。「再利用可能なキーには十分注意してください。盗まれると非常に危険です。この用途専用に設計された key vault 製品で保管するのが最適です。」2026 年 8 月時点で、ドキュメントに記載されているキーの有効期限は 1 ～ 90 日です。有効期限を指定しない場合は、最長の 90 日が既定値になります。原則として 1 回限りのキーを使用し、短期間だけ存在するマシンには ephemeral を指定してください。再利用可能なキーを使う場合は、シェルスクリプトではなく Ansible Vault で暗号化する か、secrets manager に保管してください。

鍵の有効期限: 他のミスを制限するタイマー

Node の鍵には有効期限があります。これにより、盗難または放置されたデバイスの影響を一時的な問題にできます。Tailscale のドキュメントには、「デフォルトでは、新しいドメインに 180 日の有効期限が設定される」と記載されています。また、「再認証が行われない場合、鍵の有効期限が切れ、そのエンドポイントとの接続およびそのエンドポイントからの接続が機能しなくなる」とも説明されています。デバイスは自分で再認証できます。

tailscale up --force-reauth

この操作について、ドキュメントは「tailnet 接続が停止する可能性があるため、接続が失われた場合にログインする別の手段がない状態で、SSH または RDP 経由でリモート実行してはならない」と警告しています。コンソール接続を開いた状態で実行するか、マシンへ接続する別の経路から実行してください。現在使用しているネットワーク接続を中断することになるためです。

サーバーでは、この制御が問題になります。180 日ごとに再認証が必要なマシンは、誰も監視していない午前 3 時に tailnet から切断される可能性があります。そのため、管理者はそのマシンの鍵の有効期限を無効にします。これにより、盗まれた鍵を最終的に無効化するタイマーもなくなります。サーバーにはタグ付きデバイスを使用するほうが適切です。タグは個人ではなくマシンに割り当てられるため、その担当者が退職してもマシンを継続して利用できます。どの方法を選んでも、有効期限を無効にしたマシンの一覧を管理してください。デバイスを削除するまで、それらの鍵は有効なままです。

Tailnet lock: 調整サーバーを信頼チェーンから外す

Tailnet lock は、登録の問題に直接対処します。Tailscale の tailnet lock のドキュメントでは、その仕組みを次のように説明しています。「新しいノードが tailnet に参加するとき、その公開ノードキーには Tailnet Lock キーによる署名が必要です。調整サーバーは、署名済みの公開ノードキーをピアノードに配布します。」既存のデバイスは、ピアを受け入れる前にこの署名を検証します。そのため、コントロールプレーンが独自に生成したノードキーは拒否されます。

tailscale lock status
tailscale lock sign nodekey:1abddef1 tlpub:abcdef12

tailscale lock initでこの機能を有効にし、その時点で署名ノードを指定します。Tailscale では、初期化時に少なくとも2台の署名ノードが必要です。tailnet ごとに指定できる署名ノードは最大20台です。その後は、新しいデバイスごとに署名ノードのいずれかによる署名が必要になります。これは実際の運用負担です。スマートフォンを追加する場合も、ノートパソコンでコマンドを実行する必要があります。

制限事項はドキュメントに記載されています。機能の説明よりも、こちらのほうが重要です。

• 無効化用 Secret を失うと、復旧できません。ドキュメントには「無効化用 Secret を失い、Tailscale support にそのうち1つを提供していない場合、tailnet は復旧できません」と記載されています。
• 署名キーは自分で所有するデバイスに保存されるため、そのデバイスのセキュリティ状態を引き継ぎます。ドキュメントにも明記されています。「デバイスが侵害されると、キーを取得される可能性があります。」
• 2つの制御機能を同時に使用することはできません。Tailscale では、tailnet lock と device approval は相互排他的とされています。そのため、一方を有効にすると、もう一方を使用できなくなります。
• これは初回使用時の信頼（TOFU）です。初期設定は引き続きコントロールプレーンを経由します。信頼の起点が自分のネットワーク内へ移るのは、その最初の手順が完了した後です。

Tailnet lock はメンバーシップを保護します。可用性は保護しません。ホワイトペーパーにもその点が明記されています。

リレー接続ではネットワークトラフィックが露出しますか？

いいえ。2 台のデバイスが直接到達できない場合、ネットワークトラフィックは DERP サーバー（Designated Encrypted Relay for Packets）にフォールバックします。Tailscale のドキュメントでは、この性質が明確に説明されています。「Tailscale の秘密鍵は、生成したローカルデバイスから外部に出ることがないため、DERP サーバーがネットワークトラフィックを復号することは不可能です。DERP サーバーは、すでに暗号化されたネットワークトラフィックを一方のデバイスからもう一方のデバイスへ、その内容を確認せずに転送します。」

ただし、リレーを使用すると通信速度は低下し、メタデータは観測されます。観測されるのは、暗号化された 2 つのエンドポイントと、その間を通過する通信のタイミングおよび量です。実際にどの種類の接続を使用しているかを確認します。

tailscale status
tailscale netcheck

tailscale status は各ピアを、直接接続の場合は direct 203.0.113.10:41641、リレー接続の場合は relay とリレー名に続く形式で表示し、その後にバイトカウンターを表示します。ピアがリレーに接続されたままになる場合、通常は UDP がどこかでブロックされているか、両端が厳格な NAT（network address translation）の背後にあるため、両端で直接経路を確立できなかったことを示します。tailscale netcheck は、そのマシンから UDP が機能するかどうか、NAT がポートをどのようにマッピングしているか、最寄りのリレーまでの遅延を報告します。これにより、2 つの原因のどちらに該当するかを判断できます。

出口ノードは送信元を移動しますが、送信元自体をなくすわけではありません

出口ノードは、デバイスのパブリックインターネットトラフィックを、tailnet 上の別のデバイス経由でルーティングします。デフォルトルート 0.0.0.0/0 と ::/0 を使用します。Linux では、サービスを提供するマシンが出口ノードであることを広告し、各クライアントが使用を選択します。

sudo tailscale set --advertise-exit-node
sudo tailscale set --exit-node=100.101.102.103
sudo tailscale set --exit-node=100.101.102.103 --exit-node-allow-lan-access=true
sudo tailscale set --exit-node=

出口ノードは、admin console で Owner、Admin、または Network admin の承認を受ける必要があります。また、クライアントが使用する前に、ポリシーで autogroup:internet を許可する必要があります。どちらも意図的な手順です。承認されていないマシンが、tailnet 全体の出口として密かに使われることはありません。

次に、信頼性について確認します。トラフィックは、laptop から出口ノードまで暗号化されます。その後、そのマシンから通常のインターネットトラフィックとして送信され、出口ノードの IP アドレスを使用します。そのため、出口ノードの運用者は接続先を確認できます。出口ノードの hosting provider と上流ネットワークも同様です。監視される場所を移動しただけで、監視自体をなくしたわけではありません。接続先を自分で管理できる場合は有効な選択です。そのため、自分の VPS で出口ノードを運用することには意味があります。接続先を管理できない場合は、適切な選択とはいえません。

デフォルトポリシーはフラットネットワーク

新しい tailnet は、通信を許可する設定で提供されます。Tailscale のアクセス制御ドキュメントでは、デフォルトのポリシーファイルについて「tailnet 内のすべてのデバイス間の通信を有効にする」と説明しています。すべてのデバイスが、すべてのポートで他のすべてのデバイスへ到達できます。これはフラットネットワークです。通信をトンネル内に移したことで、外部からの攻撃には有効ですが、感染した laptop からの通信は防げません。

tailnet のポリシーファイルで制限します。このファイルでは、アクセス制御リスト (ACL) または新しい grants を使用できます。どちらもコメントを記述できる JSON 方言で記述します。

{
  "acls": [
    {"action": "accept", "src": ["group:eng"], "dst": ["tag:prod:22"]},
    {"action": "accept", "src": ["autogroup:member"], "dst": ["autogroup:internet:*"]}
  ]
}

このポリシーでは、1 つのグループが本番サーバー上の SSH に接続でき、メンバーが exit node を使用できます。それ以外の通信は、ルールに記載しないことで拒否されます。Tailscale は、利用可能なルール対象をプランごとに示しています。tags や autogroups を前提に設計する前に、その内容を確認してください。また、無料プランに実際に含まれる機能も確認してください。個人用 phone など、着信接続を一切受け付けないデバイスでは、tailscale set --shields-up により client 側で着信接続をブロックできます。

Headscale でコントロールプレーンをセルフホストすると何が変わるか

Headscale は「Tailscale のコントロールサーバーをオープンソースでセルフホストできる実装」です。README でも、その範囲を正直に示しています。「対象範囲は限定的で、個人利用または小規模なオープンソース組織に適した、単一の Tailscale ネットワーク（tailnet）を実装します」。機能一覧には、ACL と grants、サブネットルーター、exit node、組み込み DERP サーバー、Tailscale SSH、Taildrop が含まれます。この限定的な範囲が問題になる場合は、NetBird もセルフホスト可能なコントロールプレーンを提供する別のメッシュです。自分の VPS で NetBird サーバーを運用することで、同じ登録先の選択を自分が所有するハードウェアに移せます。

変わるのは、不正なノードを登録できる当事者です。Headscale では、鍵のディレクトリとポリシーが自分のサーバー上に置かれます。第三者がデバイスの公開鍵一覧を保持することはなく、第三者に公開鍵の引き渡しや署名を強制されることもありません。

変わらないのはデータプレーンです。同じ WireGuard と同じエンドツーエンド暗号化を使用し、直接経路を確立できない場合は同じリレーへのフォールバックが発生します。一方で、Tailscale が担っていた運用作業も引き継ぎます。稼働状況の監視、パッチ適用、バックアップ、そしてサーバーの物理的なセキュリティです。Headscale ホストが侵害されると、攻撃者はコーディネーションサーバーが侵害された場合と同じ権限を得ます。つまり、ノードを登録し、ポリシーを配布できます。Tailnet lock は Headscale の機能一覧にないため、このリスクに対する補完的な対策は利用できません。所有権の問題が判断の決め手になる場合は、Headscale でコントロールプレーンをセルフホストする方法でセットアップを説明します。

Tailscale が防御する対象

• 外部公開された待ち受けポート。 tailnet アドレスにバインドしたサービスにはインターネットから到達できないため、ポート 22 を対象にすべての VPS をスキャンするツールからは見えません。例外は自分で有効にした場合です。Funnel は tailnet のサービスを意図的にオープンなインターネットへ公開するため、どちらかのコマンドを実行する前に、serve と funnel の違いを把握しておく価値があります。ホストのファイアウォールは引き続き有効にしてください。公開された Docker ポートは独自のルールを書き込み、パブリックインターフェース上で ufw を迂回するためです。
• 公開されたログインへのパスワード推測。 ポートがトンネル内部でのみ応答するなら、総当たりを試みる対象がありません。これは公開ポートにレート制限を設定するより強固な状態です。ただし、公開し続ける必要があるホストでは、Ubuntu 24.04 での fail2banも引き続き有効にする価値があります。
• 経路上の信頼できないネットワーク。 マシン間のトラフィックは、カフェのネットワークや共有プロバイダー LAN を経由する場合でもエンドツーエンドで暗号化されます。リレー経由になった場合も暗号化されたままです。
• 手作業で管理する鍵の配布。 WireGuard の設定にピアを手作業で追加するたびに、アドレスを重複させたり、誤った鍵を貼り付けたりする可能性があります。メッシュがその管理を代行する点が、実用面で見た WireGuard と Tailscale の違いの大部分です。

Tailscale が保護できない対象

• 侵害されたエンドポイント。 tailnet はデバイスを信頼します。承認済みのノート PC にマルウェアが侵入すると、そのユーザーに許可されたトンネル、tailnet アドレス、およびアクセス権を取得されます。これは最大の弱点であり、どの VPN でも解消できません。
• 悪意のある、または不注意な管理者。 ポリシーファイルを編集できる人は、あらゆる対象へのアクセスを自分に付与できます。また、Owner の identity account を乗っ取った人も同じことができます。コードをレビューする場合と同じ方法で、ポリシーの変更をレビューしてください。
• トラフィック分析。 ISP（internet service provider）には、エンドポイントへ送信される暗号化された UDP と、そのタイミングおよび通信量が見えます。Tailscale のフローログには、どの peer がいつ通信したかが記録されます。どちらも内容は確認できませんが、接続したという事実は隠れません。そのため、この用途のツールを選ぶ前に Tor と VPN の違い を読んでください。
• すでに紛失したデバイス。 Key expiry は、デフォルトでは 180 day の遅い対策です。管理コンソールでデバイスを削除する方が速いため、必要になる前にそのボタンの場所を確認しておいてください。

自分の tailnet を確認する

1. デバイスで tailscale status を実行し、ピア一覧を確認します。名前を特定できないマシンが表示される状態こそ、デバイス承認で防ぐ対象です。
2. tailscale lock status を実行して tailnet lock が有効か確認し、新しいデバイスごとに署名するコストに見合うかを tailnet について判断します。
3. 管理コンソールを開き、キーの有効期限が無効になっているすべてのマシンと、現在も存在するすべての再利用可能な認証キーを記録します。どちらも有効期限のない認証情報です。
4. ポリシーファイルを確認します。デフォルトのままの場合、すべてのデバイスがすべてのポートで相互に接続できるため、1 台の感染したノート PC から全デバイスに到達できます。

Tailscale が評価されているのはデータプレーンです。その設計では、運用者がネットワークトラフィックを読み取る手段が排除されています。その主張はベンダーの文書どおりに受け止めたうえで、自分で管理する部分を監査します。対象は、ID アカウント、承認設定、有効期限の一覧、ポリシーファイルです。Tailscale のセキュリティページには、SOC 2 Type II 認証と Latacora との継続的なセキュリティ活動が記載されています。これは Tailscale のプロセスに関する証拠であり、あなたの構成に関する声明ではありません。

FAQ

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

いいえ。通信はデバイス上で生成された WireGuard の暗号鍵で暗号化されます。Tailscale のセキュリティページにも、「Private keys never leave the device. All traffic is end-to-end encrypted, always.」と記載されています。DERP リレーへフォールバックする接続も同様です。リレーは「blindly forwards already-encrypted traffic from one device to another」だけであり、復号に使える鍵を保持しません。Tailscale のインフラストラクチャが確認できるのはメタデータです。存在するデバイス、どのデバイス同士がいつ接続したか、といった情報です。

Tailscale の調整サーバーが侵害された場合、実際に何ができますか？

ノードを登録できます。Tailscale 自身の tailnet lock に関する告知では、秘密裏に追加されたノードが「send or receive traffic to your existing nodes」できるリスクが説明されています。この場合、暗号化では防げません。「because the peer itself would be malicious」だからです。侵害されたコントロールプレーンは、デバイスから到達できる対象を変更するポリシーを配布することもできます。また、tailnet lock のホワイトペーパーでは、新しいノード鍵の配布に失敗して接続性を損なう可能性も説明されています。一方、既存のデバイス間の通信を復号することはできません。これらのデバイスの秘密鍵を保持したことがないためです。

exit node は ISP から閲覧先を隠せますか？

自宅やカフェの ISP など、接続元のネットワークから閲覧先を隠せます。デバイスから出る通信がすべて、exit node 宛ての暗号化通信になるためです。ただし、匿名にはなりません。閲覧先は exit node からも見えます。exit node のホスティングプロバイダーと上流ネットワークからも見えます。また、アクセス先のサイトからは exit node の IP アドレスが見えます。監視者を別の相手に替えただけなので、実際に信頼できる相手を選んでください。

Headscale は Tailscale の調整サーバーより安全ですか？

単純に安全性が高いというより、異なる信頼先を選ぶことになります。Headscale では鍵のディレクトリとポリシーを自分で管理するため、外部の第三者がデバイスを自分の tailnet に登録するよう強制されることはありません。一方で、そのサーバーの運用を自分で担います。パッチ適用、可用性、バックアップ、ホスト自体のセキュリティが必要です。Headscale ホストが侵害されると、攻撃者は侵害された調整サーバーと同じ登録権限を得られます。また、Headscale の機能一覧には tailnet lock が含まれていません。そのため、ホストを適切に保護してください。

tailnet に参加している VPS にもファイアウォールは必要ですか？

はい。公開ネットワークインターフェースは引き続き存在します。0.0.0.0 にバインドされたサービスは、Tailscale が動作しているかどうかにかかわらずインターネットから到達可能です。サービスは tailnet のアドレスにバインドし、公開インターフェースではデフォルト拒否ポリシーを維持してください。公開しているコンテナポートも確認してください。Docker は独自のルールを挿入するため、閉じていると思っていたポートが公開されることがあります。