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

Tailscale ピアリレー

概要

  • 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を公開するソフトウェアを提供したり、認証やログ処理をする必要がありそうだね。

これは、Tailscaleが運営するDERPサーバーの代替品だね。DERPサーバーはクラウドリレーなんだけど、TailscaleのNATパンチング機能がいくら優れていても、真のP2P接続を確立できないケースがたくさんある。最後の手段はかなり遅いDERPリレーで、実際によく使われるよ。もしTailscaleネットワーク内に良好な接続を持つピアがいて、そのピアをルーターのポートフォワードでインターネットに公開できるなら、混雑したDERPサーバーを避けるためにこのリレー設定を有効にできる。だから、実際には新しい使い方ってわけじゃなくて、同じことがただ速くなっただけだね。

Tailscaleはいくつかの要素があるね。主に、組織や個人ユーザーが簡単に安全なVPNを作れるウェブフロントエンドを持つソフトウェアプラットフォームって言えるかも。これで、様々なシステムが安全でフィルタリングされていない仮想プライベートネットワーク上でコミュニケーションできるんだ。通常のVPNのやり方はハブアンドスポーク方式で、各システムが中央のハブに接続して、そこを通じて他のシステムにアクセスするって感じ。でも、Tailscaleはそれとは違って、理想的には接続された各システムがVPN上の他のシステムと直接UDP/IP接続を形成するんだ。ハブはない。だから、ノードAがノードFにデータを送る場合、中央のハブを通さずに直接送れるんだ。これってすごくクールだよね。このピアツーピアの仕組みは、ハブアンドスポークに比べて非常に効率的なんだ。(Tailscaleを使えば、無料でかなりのことができるから、支払いは一切期待されない。)でも、理想的な世界には住んでないから、実際にはNATやファイアウォールのある世界に住んでることが多い。時にはISP自身が実装してることもあって、2つのノードが直接UDPパケットを送るのが不可能になることもある。これが到達不可能なノードを生んで、役に立たなくなるんだ。だから、Tailscaleはそのインターネットの問題を解決するために、パケットのための指定暗号化リレー(DERP)を提供してる。DERPは通常機能して、エンドツーエンドの暗号化も維持される。DERP自体は全く新しいものではないけど、直接通信できないノードのためにハブアンドスポークの一部を取り戻す感じで、これらのノードを助けるためにトラフィックを中継する役割を果たすんだ。でも、DERPはTailscaleがホストしてるもので、アプリケーションによってはかなり遅くなることもある。以前は、個々のユーザーがDERPのパフォーマンスを改善する手段はなかったんだ。単に、接続の悪いVPNノードのために帯域幅を消費するDERPサーバーの集まりだった。でも、今日の発表でTailscale Peer Relayが登場した。> これのユースケースは何?主なユースケースはシンプルで、DERPの代替なんだ。ユーザーは自分のネットワークの接続が悪いピアのために、自分のリレーサービスを提供できるようになった。だから、DERPが持っている帯域幅に制限されるのではなく、リレーはユーザーが支払ってホストできるだけの帯域幅を提供できる。もしユーザーがうまく計画すれば、Peer Relayをネットワーク上の適切な場所に配置して、DERPに比べてノード間のレイテンシを最小限に抑えることもできる。(これは全員向けではないし、Tailscaleも全員向けではない。VPNが必要ない人もいるからね。ランダムな一般顧客がそれを知って直接使うとは思わないけど。)

いいね!この機能はすごく理にかなってるし、時間がかかったね。ハブアンドスポークに戻るような感じだけど、トラフィックはエンドツーエンドで暗号化されてるし、中間ノードは直接接続できないときや特定のクライアントのためだけに使われる。自分のDERPサーバーを運営するのに似てるけど、その手間がなくて、リレーがピアから到達可能ならインターネットにポートを開ける必要もない(DERPでは必要だけど)。DERPサーバーはスループットが低いし、別の選択肢として従量課金のDERPサービスも考えられるね。最近のTailscaleサービスの発表で、リバースプロキシの必要がなくなるかもしれない。ところで、なぜ2つ以上のリレーに対してお金がかかるの?自分のデバイスと帯域幅だけ使ってるのに(笑)。実際、Tailscaleのリレーの使用を減らすことで帯域幅の請求が下がるんだ。理想的には、デフォルトでソフトウェアが直接接続を助けるノードを見つけてくれるといいね。自分のネットワーク内でのルーティングだけなんだから。

自分のderpサーバーを運営するのに似てるけど、その手間がなくて、リレーがピアからアクセスできる限り、インターネットにポートを開ける必要もないかもね(derpでは必要だけど)。ほとんどの人はインターネットにポートを開ける必要があると思うけど、そうじゃないとそもそもtailscaleを使う意味がないから。例えば、クラウドネットワークを自社ネットワークに接続する場合とかね。もちろん、例外もあって、両方のクライアントがピアリレーにはアクセスできるけど、お互いには直接アクセスできない場合もある。

一つ理解できなかったことがあるんだけど、選んだUDPポートを使うってことは、どのIPを使ってるの?すべてtailnet経由なのか、それともこのポートをインターネットに開ける必要があるの?もしTailscale/tailnet経由でしか利用できないなら、2台のデバイスがTailscale経由で接続できるときは、すでにリレーやDERP接続ではなく直接接続のルートにいるんじゃないの?

顧客は、自分のtailnetからだけ接続が来るためのファイアウォール例外を一つだけ作ることができます。ファイアウォールで一つのUDPポートを開ける必要があるので、あなたのパブリックIPアドレスになります。どこかにVMを用意する必要はなくて、ただ一つのポートだけで大丈夫。速度に関しては、ピアツーピア接続ができないときにDERPを使うことになるから、速度はDERPサーバーの速度と負荷に制限されるよ。でも、ピアリレーを使えば、デバイス間の帯域幅をほぼフルに活用できるんだ。

iOSやtvOSデバイスでサポートされてない理由って何かあるの?Apple TVで使えるようにしたいんだけど!

これ、チームにこの質問をしたときにエンジニアの一人が言ってたことを要約してるんだけど(私はTSの内部者だからね):NetworkExtensionにはアプリケーションサイズの制限があるんだ。https://developer.apple.com/documentation/networkextension だから、iOSやApple TVでこれを実装するにはバイナリサイズを小さくする必要があるんだよ。

クライアントにリレーを強制的に使わせる方法ってあるの?これってバックアップ用にしか思えないけど、リレー接続の方が実際に速い場合(tailnetメンバー間の直接接続が遅いときとか、消費者の接続では珍しくない)ってどうするの?

DERPと比べての主な欠点は、ブラウザでこれが機能しないことだね。ネイティブUDPだから。将来的にWebTransportで動作させることは可能かな。