- Tailscale Peer Relays は、既存の DERP サーバー を置き換える新しいトラフィックリレー機能で、ユーザー自身がデプロイして管理できる構造
- 各ノードは UDP ポートを 1 つ開くだけで リレーとして動作でき、Tailscale クライアントに内蔵されているため簡単に有効化可能
- 高速・高スループット接続 をサポートし、クラウド NAT やファイアウォールの背後でも 直接接続に近い性能 を確保
- すべてのトラフィックは WireGuard® ベースのエンドツーエンド暗号化 を維持し、DERP およびカスタム DERP への 自動フォールバック(fallback) をサポート
- 現在 パブリックベータ として提供されており、すべての料金プランで 最大 2 つの無料 Peer Relay を利用可能
Tailscale Peer Relays の概要
- Tailscale Peer Relays は、Tailscale のマネージド DERP サーバー を置き換えられる ユーザー管理型トラフィックリレーメカニズム
- どの Tailscale ノードでもリレーとして設定可能で、同じ tailnet 内のノード間トラフィックを中継
- リレーは、自身が属する tailnet のノードのみを中継可能
- 顧客が直接管理するため DERP よりスループット制約が少なく、閉鎖的なクラウドインフラやファイアウォール環境 でも高い性能を提供
- 初期パートナーテストでは 直接接続に近いスループット を記録し、既存の DERP と比べて 数十倍以上高速な性能 を確認
Hard NAT 環境の克服
- Tailscale は NAT 環境でも可能な限り 直接接続(90% 以上) を維持できるよう、改良された NAT トラバーサル技術を適用
- しかし一部の クラウド環境 では、直接接続が不可能または非効率な場合がある
- 既存の DERP は安定した接続を提供する一方、QoS 制約と性能限界 により一部のデプロイ環境では課題が存在
- Peer Relays は 性能重視の接続ツール として設計されており、UDP ベースの低遅延通信 と クライアント内蔵構造 によりデプロイが容易
- 顧客が自らリレーを配置することで 高性能・高柔軟性のネットワーク構成 が可能
動作方式
- Peer Relay は 両側ノードがアクセス可能な単一の UDP ポート を使用
- CLI コマンド
tailscale set --relay-server-port で簡単に有効化可能
- 直接接続が不可能な場合は、Peer Relay → DERP(マネージドまたはカスタム) の順で自動フォールバック
- すべての接続は WireGuard® 暗号化 で保護
- ファイアウォール例外を最小限に抑えつつ tailnet 内部トラフィックのみを許可 するよう設定可能
- リージョン間の拡張性、ネットワーク障害耐性、DERP 自動フォールバック機能をすべてサポート
さまざまな活用シナリオ
- クラウド NAT 環境(AWS Managed NAT Gateway など) で直接接続できないトラフィックを高速中継
- 厳格なファイアウォール環境 で単一の UDP ポートだけを開放し、承認手続きを短縮
- DERP ネットワーク負荷の軽減 および カスタム DERP の保守不要
- 閉鎖的な顧客ネットワークへのアクセス 時に、予測可能なエンドポイントを通じて最小限のポートのみを開放
- 実際の顧客は Peer Relay を活用して、非管理ネットワークへのアクセス、パートナー接続経路の制御、VPC ピアリングベースの細分化されたネットワーク構成 などを実現
パブリックベータと提供ポリシー
- Tailscale Peer Relays は パブリックベータ版 として今すぐ利用可能
- 現在、一部の 可視性およびデバッグ改善作業 が進行中
- 初期パートナーは 容易なデプロイと安定した性能 を確認
- すべての料金プラン(無料を含む)で 最大 2 つの Peer Relay を無料提供、追加のリレーは拡張可能
- 追加のリレーが必要な場合は Tailscale 営業チームへの問い合わせ を通じて拡張可能
1件のコメント
Hacker Newsのコメント
この機能は本当に理にかなっていると思う
直接接続できないときだけ中継ノードを使う仕組みで、トラフィックはエンドツーエンド暗号化される
derpサーバーを自前で運用するのに近いが、ポートを開ける必要がなく、Tailscaleのリレー利用量を減らして帯域コストも削減できる
ただ、2つ以上のリレーを使うとなぜ有料なのかは気になる
そうでなければ、そもそもtailscale自体が不要かもしれない
例外的に、2つのクライアントがリレーにはアクセスできても互いに直接接続できないケースはある
昔のtincがすでにこの問題を解決していた
すべてのノードがリレー役になれ、中央サーバーなしで本当のメッシュネットワークとして動作する
わざわざ新規実装するより、wireguardベースでメモリ安全な言語へ移植したほうがよいと思う
SSH接続の直後に経路が切れることも多い
リレーノードでトラフィックが復号・再暗号化される構造なので、エンドツーエンド暗号化には実験的なプロトコルを使わなければならない
cjdnsプロトコルベースで書き直してみたいが、簡単ではない
Tailscaleの新しいPeer Relay機能は、ZeroTierが以前やっていたことに似て見える
「Tailscale独自の機能」だと主張するのは無理があり、ユーザー単位の課金とは別に追加料金まで取るのは割高に感じる
その代わり、独自の暗号化方式、シングルスレッド性能の低さ、開発速度の遅さが問題だった
いろいろ代替を試したが、Tailscaleほど機能と性能の両方を備えたものはまだない
「FTPがあるのに、なぜDropboxを使うのか」という類いの比較に感じる
外部のIPv4/IPv6アドレスを直接指定できるのか気になる
送信と受信で異なるアドレスを使ったり、複数のインターネット接続先アドレスのうち一部だけがファイアウォールで許可されていたりする場合があるからだ
先週headscaleとsplit horizon SSLを設定したが、結局DERPしか使えないことが分かった
ローカルネットワークでUDPポートを直接公開するほうが良いと思う
Wireguardクライアントの安全性が十分に検証されているなら、そのほうが楽だ
直接Wireguardのポートを開けようとしたのか、それともTailscaleのポートの話なのか聞きたい
DERPの代わりにこの機能を使うと、ブラウザでは動作しない
ネイティブUDPベースだからだ
将来的にWebTransportで実装できるのか気になる
ただし、NATトラバーサルの問題は解決できない
IrohのQADの進捗も注意深く見ている
すべてがうまくかみ合えば、もっと魔法のようなネットワークになると思う
次の段階として、すべてのtailscaleクライアントが自動で転送リクエストを受け付け、メッシュネットワークが途切れず自己修復するようになったらどうかと思う
ただし、他人のトラフィック中継を許可するかどうかが核心だ
Tailscaleでサービス間接続はできるが、もしTailscale障害が起きた場合、自分のサービス同士の通信まで途切れるのか気になる
tailscaleに接続できず、再接続も不可能だった
だから今はheadscaleを自前で構築しようとしている
ローカルLAN機器同士すら通信できなくなるのはちょっとひどいと思った
週末ずっとKubernetes Operator向けに暫定ソリューションを作っていたが、この機能のおかげで全部撤去できそうだ
本当にブラボーだ
この機能のユースケースが気になっていた
SaaS製品が顧客システム内のデータを必要とするとき、顧客側でデータをリレー経由で公開して統合する用途のように見える
それでも認証やロギングなどのためのソフトウェアは必要になりそうだ
NAT越えができないケースが多いためDERPはよく使われるが、速度が遅い
今後はネットワーク内で接続性のよいピアをリレーに指定して、より高速に使えるようになる
新しいユースケースというより、既存DERPの性能改善版だ
従来のハブアンドスポーク構成ではなく、可能な限りすべてのノードが直接UDP/IPで接続されるP2P構成を志向している
ただし、NATやファイアウォールのために直接接続できないことが多く、その際はDERPが中継する
DERPは遅く、ユーザー側で性能を改善する手段がなかったが、今回のPeer Relayによって自前のリレーを運用できるようになった
配置をうまく選べば遅延も減らせる
もちろん、すべてのユーザーに必要な機能ではない