世界を動かす技術を、日本語で。

Tailscale ピアリレー

2025年10月30日原文(tailscale.com)

概要

  • Tailscale Peer Relays のパブリックベータ提供開始
  • DERPサーバーに代わる 顧客管理型リレー の実現
  • 高スループット ・低遅延な通信経路の構築が可能
  • 導入・運用の簡便化 と柔軟なネットワーク設計
  • すべてのプランで 2台まで無料利用可能

Tailscale Peer Relays 公開のお知らせ

  • Tailscale Peer Relays は、TailscaleのDERPサーバーに代わる トラフィックリレー機能 の提供
  • 任意のTailscaleノードで peer relay機能を有効化 可能
  • 顧客自身がデプロイ・管理 しやすいリレーサーバー
  • 同一tailnet内 のノード間のみリレー通信を許可
  • 高スループット ・クラウドやファイアウォール環境での 高性能接続 実現
  • DERPより制約が少なく、ほぼ直接接続と同等の通信速度を記録
  • UDPベース かつTailscaleクライアントに組み込み済みで、導入が容易

ハードNAT突破とパフォーマンスの進化

  • NATトラバーサル技術の進化 により90%以上は直接接続が可能
  • ただし、クラウドや一部環境では 直接接続が困難 な場合も存在
  • DERPは信頼性重視だが、 パフォーマンス面での制約 が課題
  • Peer Relay はパフォーマンス重視設計で、 直接接続に匹敵 する通信速度
  • リソース近接配置 やUDP利用により、 低遅延・低オーバーヘッド を実現
  • 単一コマンドで有効化 でき、導入の手間を大幅削減

Peer Relayの仕組み

  • 単一UDPポート を利用し、両端がアクセス可能であれば設定可能
  • Tailscale CLIの tailscale set --relay-server-port コマンドで簡単有効化
  • 直接接続優先、次にPeer Relay、最後にDERPへ自動フォールバック
  • すべての通信は WireGuard®によるエンドツーエンド暗号化
  • ファイアウォール例外は1つのみ で済み、管理が容易
  • リージョン跨ぎのスケール、現実的ネットワーク条件への耐性、DERPへの柔軟なフォールバック

利用シナリオとメリット

  • 直接接続できない環境 でも高スループット通信を維持
  • 未管理ネットワークへのアクセス経路 の提供
  • 厳格なプライベートネットワーク での予測可能なアクセスパス構築
  • パブリックサブネット配置 +VPC Peeringでセキュリティと柔軟性を両立
  • AWS Managed NAT Gateway等のクラウドNAT突破 による高速通信
  • ファイアウォール越し通信 も単一UDPポートで迅速に許可取得
  • DERPへの依存減少、自前DERP運用の手間削減
  • ロックダウン環境 でも最小限のポート開放で安全な接続

今後の展望と利用方法

  • パブリックベータ として全プランで利用可能
  • 2台までのPeer Relayは無料 (今後の拡張も検討中)
  • 顧客フィードバックを元に進化中、可視化やデバッグ機能も今後強化予定
  • 導入・運用の容易さ柔軟な拡張性 で、さまざまなネットワーク要件に対応
  • 追加Peer Relayの導入 はカスタマーサポートへ相談

まとめ

  • Tailscale Peer Relays により、 どこでも高速・柔軟な接続 を実現
  • セキュリティ・運用性・パフォーマンス のバランスを追求
  • 全ユーザーが無料で試せる 新しいリレー技術
  • ネットワーク設計の自由度運用効率 の大幅向上

Hackerたちの意見

週末にこれの解決策を探してたんだけど、すごく変わったKubernetes Operatorの設定になっちゃった。でも今はこれを使えるから、全部取り替えられる!ブラボー!

いやー、K8sはマジで悪夢だわ(笑)。100%同意。

ネットワーク用語が難しいけど、これでオフライン接続ができるの?もしローカルLANに2台のデバイスがあって(どちらもTailnetに接続してる)、家のインターネットが切れたら、今はそのデバイス同士が切断されちゃうんだ。そうならない方法を探してたんだけど、同じWiFiネットワークに接続しているTailnetのデバイス同士が、インターネット接続が切れてもお互いを見つけられるようにしたいんだ。

それ、もう動いてるよ。

家のインターネットが切れたら、今はそのデバイス同士が切断されちゃう。自分でHeadscaleのようなコントロールプレーンをホストすることで解決できるかも。TailscaleがTailnet上のすべてのノードを管理/調整する代わりに。 https://github.com/juanfont/headscale

もしWireGuardがピアごとに複数のエンドポイントをサポートしてくれたら簡単なのに。そうすれば、外部のアドレスに加えてローカルデバイスのULAアドレスも追加できるのに。

これは20年前にtincでうまく解決されてたよ。すべてのtincノードが中継として機能できるし(希望があればそれを無効にすることもできる)、中央サーバーに依存しないし、インターネットにアクセスしなくてもちゃんと動く。真のメッシュだね。世界はtincをwireguardとメモリセーフな言語に移植することで、機能の一部をゼロから再実装するよりも良くなると思う。

Wireguardは君が言ってることができるよ。

へぇ。インターネット上に30ノードのTincネットワークがあるけど、いくつかのホストはNATの背後にいるんだ。これらのノード間でルートをランダムに失ってしまう。SSH接続を成功させた数秒後にルートを失うこともあって、イライラするよ。それに、トラフィックがリレーするノードによって復号化されて再暗号化されるみたい。エンドツーエンドの暗号化には、Tinc 1.1で追加された「ExperimentalProtocol = yes」が必要だけど、正式にはリリースされてないんだ。自分が慣れている言語でそれに似たものを書き直したいけど(たぶんcjdnsのプロトコルを基にして)、簡単じゃないね。

次のステップとして、すべてのtailscaleクライアントがTailnet内の任意の2台のマシン間で転送リクエストを自動的に受け入れられるようにすることができれば、メッシュがシームレスに自動的にルーティングされるのかな?

うん、そういう拡張は自然だし、オーバーレイネットワークの文脈でよく出てくるね。ここでの重要な質問は、他の人のCPトラフィックを中継することに問題がないかどうかだね。

これってどんな使い方するの?SaaS製品があるときに、顧客のシステムから必要なデータがある場合に使うみたいだけど。顧客データをこのリレーで公開して、SaaSに統合するって感じ?統合には、顧客に制限されたAPIを公開するソフトウェアを提供したり、認証やログ処理をする必要がありそうだね。

Hacker Newsで議論の続きを見る