Tailscale アーキテクチャ

Tailscaleは、WireGuardの上に、デバイスアイデンティティ、鍵の配布、アクセスポリシー、アドレスとDNSの管理、および利用可能な転送経路の自動検出機能を提供します。その仕組みを最も理解しやすい方法は、「ノートブックが会社のサーバーのHTTPSサービスにアクセスする」というシナリオを追跡することです。まず相手是谁（誰か）を確認し、接続が許可されているかどうかを確認し、次に暗号化されたパケットがどのように到達するかを決定し、最後にアプリケーション認証とビジネス操作を行います。

制御面とデータ面

調整サービスは、ログインアイデンティティ、ノードの公開鍵、およびネットワーク構成を関連付け、必要な情報をクライアントに配布します。ビジネスパケットの通常の転送には、パケットごとに調整サービスに問い合わせる必要はありません。クライアントは取得した状態に基づいて、暗号化、ルーティング、フィルタリングを行います。集中型の調整とピアツーピア通信は矛盾しません。

データ転送には3つのパスがあります：ノード間のダイレクト UDP、DERP リレー、tailnet 内の Peer Relay です。これらはすべてノード間の WireGuard 暗号文を運ぶことができるため、「ユーザーデータは調整サービスを経由しない」という記述は成立しますが、さらに「ユーザーデータは決してどのセントラルサーバーも経由しない」と書くことはできません。接続タイプ

メッシュ（Mesh）は、ノードがポリシーに基づいて相互のカバレッジネットワーク接続を確立できることを示しており、すべてのデバイスが起動時にすべてのペアごとのアクティブセッションを維持し続けることを要求するものではありません。100台のデバイスには4,950組の潜在的な組み合わせがあります。ただし、各クライアントが2台のサーバーにアクセスしている場合のみ、実際のアクティブな関係はビジネスによって決定されます。公開鍵の配布、パスの検出、およびビジネストラフィックは、同じ種類のオーバーヘッドではありません。

アイデンティティ：ログイン資格情報はトンネルの秘密鍵ではない

ネットワークに参加する際、デバイスはローカルで鍵を生成します。ユーザーはアイデンティティプロバイダーを使用してログインするか、auth key を使用して非対話型の登録を行います。制御面はアイデンティティとデバイス、ノードの公開鍵を関連付け、設定に基づいて情報を配布します。ノードの秘密鍵はエンドポイントに留まり、他のピアや管理サーバーに送信してはいけません。Tailscale アイデンティティ

タグ付きサーバーはタグアイデンティティとしてポリシーに参加します。サーバーにタグを付けることが単にユーザー名に表示用の注釈を追加するだけだと単純に考えてはいけません。タグ付与権限自体も管理する必要があり、そうでないとデバイスに高権限のタグを付与でき、アクセス可能なリソースを変更してしまう可能性があります。アイデンティティとタグ

エンドツーエンドの暗号化は依然として、「取得した公開鍵が確かに信頼すべきノードに属していること」に依存しています。Tailnet Lock は、ノードの公開鍵の受け入れ条件に、信頼されたノードによる署名を追加することで、制御面による不正なノードの挿入リスクを低減します。ただし、エンドポイントが侵害されている、アプリケーションの権限が大きすぎる、または利用可能なすべてのネットワークパスがブロックされているという問題には対処しません。Tailnet Lock 白書

パスの確立：利用可能なパスが先で、ダイレクト接続を継続的に追求する

一般的な確立プロセスは、まず DERP を通じて利用可能なリレーチャネルを取得し、同時に検出情報と候補アドレスの交換を行います。ダイレクト接続が成功すると、ダイレクト UDP に切り替わります。ダイレクト接続が確立できない場合、条件を満たすクライアントは利用可能な Peer Relay を使用でき、そうでない場合は DERP を継続して使用します。ここで、「期待されるパスの優先順位」と「最初の数据包が実際に通るパス」を区別する必要があります。リレーを、すべての探査が完全に終了した後に現れる最後のステップとして記述してはいけません。接続確立のタイミング

NAT 透過には、アドレスマッピングとインバウンドフィルタリングの両方の条件を同時に満たす必要があります。STUN は外部マッピングを観察するのに役立ちますが、任意のオープンなインバウンドをローカルマシンに作成するわけではありません。両端の探査は、ゲートウェイが戻りトラフィックを許可する状態を作成するのを促しますが、複雑な NAT、マルチレイヤーのゲートウェイ、および UDP の制限により、ダイレクト接続が失敗する可能性があります。ポートマッピングプロトコルが助けになっても、デバイスがファイアウォールの制約を受けないパブリック IP を取得したことを意味するわけではありません。基本メカニズムについてはポートと NAT を参照してください。

DERP は暗号化されたビジネスパケットの転送に加えて、DISCO 検出メッセージも運ぶため、「DERP にアクセスした」こと自体が、現在のすべてのビジネスがリレーを経由していることを証明するものではありません。クライアントは DERP マップを保存し、適切なリレーリージョンを選択します。リージョン間の距離とリンクの条件が実際のパフォーマンスに影響します。DERP サーバー

Peer Relay は、tailnet 内でリレーとして構成されたデバイスであり、適切なクライアントバージョン、到達可能なリレー用 UDP ポート、および対応する使用権限が必要です。パブリックネットワーク上に位置する通常のノードが1つあるだけでは、すべてのピアが自動的にそれをリレーとして扱うことはありません。Peer Relay

リレー遅延の見積もり

A から B へのダイレクトな片道伝播が 20 ms、R を経由する場合、A→R が 15 ms、R→B が 35 ms と仮定し、戻り経路が対称でキューイングを無視するとします。ダイレクト接続の RTT は 40 ms、リレーは 100 ms です。これは与えられたパスに対する教育的な予算であり、DERP や Peer Relay の固定パフォーマンスではありません。実際のスループットは、パケット損失、輻輳、CPU、帯域幅、および外層転送の影響を受けます。

nodes = 100
assert nodes * (nodes - 1) // 2 == 4950
paths_ms = {'direct': [20], 'relay': [15, 35]}
rtt_ms = {name: 2 * sum(hops) for name, hops in paths_ms.items()}
assert rtt_ms == {'direct': 40, 'relay': 100}
# 直列の3つのリクエスト往復；ハンドシェイク、計算、キューイング、または大規模オブジェクトの転送は含まない。
assert 3 * (rtt_ms['relay'] - rtt_ms['direct']) == 180
print('潜在的接続数と与えられたパスの遅延予算が通過')

認可：ネットワーク接続とビジネス許可は分けて理解する

現在の Tailscale ドキュメントでは、ネットワーク層とアプリケーション層の能力を grants で記述し、ACL は引き続きサポートされています。ネットワーク層の認可は、「エンジニアリンググループが web タグ付きデバイスへの TCP 443 に接続できる」と表現できます。これは、自動的にそのユーザーを Web アプリケーションの管理者にするものではありません。Grants、ACL

以下は独立した最小限のポリシー例です。ユーザー名は実際の tailnet メンバーに置き換えてください。目的のデバイスが tag:web を合法に取得していると仮定します。既存のポリシーに追記する場合、他の広範な許可項目は依然として有効であるため、この1行を既存の権限を上書きまたは取り消すものと理解してはいけません。

{
  "groups": {"group:engineering": ["alice@example.com"]},
  "tagOwners": {"tag:web": ["autogroup:admin"]},
  "grants": [
    {
      "src": ["group:engineering"],
      "dst": ["tag:web"],
      "ip": ["tcp:443"]
    }
  ]
}

この例は、一致する主体が指定された接続を開始することを許可し、戻りトラフィックは許可された接続として処理されます。サーバーがクライアントに対して任意の新しい接続を確立することを認可するものではなく、TCP 22 も付与しません。tagOwners は、誰がタグを付与できるかを管理するものであり、誰がこれらのデバイスに接続できるかを許可するものではありません。Grants 構文

アプリケーション層の app 能力には、対応するアプリケーション統合による識別が必要です。従来の Web サービスは、ポリシーファイルに能力名が出現したからといって、自動的にそのビジネス権限を実装するわけではありません。

アドレス、MagicDNS、ルーティングは別物

デバイスの Tailscale アドレスは、オーバーレイネットワーク内のアドレスであり、現在の Wi-Fi 出口のパブリックアドレスではありません。ネットワークを変更すると、外層のエンドポイントが変化する可能性があります。アプリケーションは同じノード名またはオーバーレイアドレスを引き続き使用するため、下層の位置への依存関係を減らすことができますが、ノード登録とアドレスのライフサイクルの制約は依然として受け入れます。

MagicDNS は tailnet デバイスに名前を生成し、ユーザーがデバイス名でアクセスできるようにします。名前解決は「ターゲットアドレスは何ですか」に答え、ルーティングは「どのインターフェースまたはゲートウェイに渡すか」に答え、アクセスポリシーは「許可されるかどうか」に答えます。従来のサブネットを tailnet に追加した後、その既存の内部ドメイン名が MagicDNS によって自動的に登録されるとは限りません。通常、内部 DNS とスプリット DNS 構成も必要です。MagicDNS、サブネットルーター

サブネットルーティング、出口、リレー：誰が WireGuard を終了するかを見る

従来のサーバーにアクセスする場合、サブネットルーターは内部 IP パケットを解読し、ターゲットネットワークに送信します。アプリケーションが HTTPS を使用している場合、アプリケーション層の TLS はサーバーまでの保護を継続できます。平文の HTTP を送信する場合、前半に WireGuard があったとしても、後半は自動的に暗号化されません。

Linux のカーネルルーティングとユーザー空間 netstack ルーティングは、復号化後の転送方法を記述しています。前者はカーネルが内部パケットを転送し、後者はユーザー空間で接続を処理します。「カーネルモード」から、Tailscale が必ず WireGuard の暗号化・復号化を wireguard.ko に委ねていると推論してはいけません。カーネル vs. netstack

サブネットへのアクセスは通常、ルーティングの公開と承認、クライアントが対応するルーティングを採用していること、ポリシーの許可、およびフォワーディング/戻り経路の成立を同時に満たす必要があります。デフォルトの SNAT により、従来のサーバーはルーターのアドレスを表示し、戻り経路が簡素化されます。SNAT を無効にすると、ターゲットネットワークは元の送信元に戻る方法を知らなければなりません。ソース IP の保持と戻りルーティングの不要化は、同時に無料で得られる2つの効果ではありません。サブネット SNAT

調整サービスのオフライン：既存の通信と管理変更の運命は異なる

クライアントは鍵とフィルタリングルールをキャッシュするため、制御面に到達できない場合でも、既存のノード間通信は継続する可能性があります。それは永続的な自律性ではありません。鍵の有効期限切れ、エンドポイントの変更、キャッシュの不十分さ、またはすべてのリレーが到達不能になることが接続に影響を与える可能性があります。新しいデバイスの参加、鍵の更新、新しいポリシーの伝播、および失効は、通常のフローで完了できません。調整サービスの障害

これは、見過ごされがちな現象も説明しています。制御面が中断された場合、古いビジネスが継続して実行されることは可用性の利点ですが、管理者がアクセスをすぐに緊縮したい場合、古いポリシーが依然として実行されていることは、変更の伝播の問題となります。障害処理では、接続性とポリシーの鮮度の両方を観察する必要があります。

制御面が切断された場合、どの操作が最初に失敗するか？

有効なキャッシュとダイレクト接続を維持し、調整サービスのみを切断すると、青色のビジネスパスは存在し続けます。ただし、制御面の更新は利用できなくなります。ダイレクト接続をさらに取り除くと、リレーが依然としてトラフィックを運べるかどうかを観察できます。さらに有効な状態またはすべてのパスを失うと、ここで述べるデータ面の前提条件に到達します。

証拠に基づいて特定し、relay を見たからといって設定を変更しない

以下のコマンドは手動診断用です。ping と netcheck はネットワーク探査を発行します。

tailscale status
tailscale ping <peer-name>
tailscale netcheck

status 内の direct、relay、peer-relay は、現在観察されているパスを記述しており、パスは時間とともに変化する可能性があります。デフォルトの tailscale ping は、Tailscale 層の検出/接続チェックに使用され、通常の ICMP やビジネス TCP ポートへのアクセスとは異なるテストです。1回の成功が、HTTPS 証明書が有効であるか、API 認可が正しいことを証明するものではありません。Ping のタイプ

失敗したアクセスのトラブルシューティングでは、次の順で記録できます：名前解決されたアドレス、クライアントのルーティングとノード状態、実際の転送パス、ターゲットポートの到達可能性、TLS/アプリケーションエラー。大きな応答のみが失敗する場合、MTU とパケット損失をさらに確認する必要があります。リレー経由では利用可能だがダイレクトが成立しない場合、UDP の到達可能性と NAT 条件を観察する必要があります。HTTP 403 をすでに受信している場合、透過ポートの調整を繰り返すのではなく、アプリケーションの認証認可の証拠に戻るべきです。