Headscale - Tailscaleコントロールサーバーのセルフホスティング実装オープンソース

 (github.com/juanfont)
2 ポイント 投稿者 GN⁺ 2025-04-04 | 1件のコメント | WhatsAppで共有
  • Headscaleは、Tailscaleのコントロールサーバー機能をセルフホスティングできるようにしたオープンソースの代替プロジェクト
  • TailscaleはWireGuardベースのモダンなVPNソリューションで、NAT環境でも動作するオーバーレイネットワークを構成可能
  • 元のTailscale Controlサーバーはクローズドソースのソフトウェアだが、Headscaleはこれを置き換えられる自由に導入可能なサーバーソフトウェアとして開発されている
  • Windows、macOS、iOSクライアントは引き続きTailscaleのGUIを必要とする

Headscaleの目的と特徴

  • Headscaleは個人および小規模なオープンソース組織が利用できるよう、1つのtailnet（仮想プライベートネットワーク）のみをサポート
  • 自前のサーバーを運用したいユーザーや自由ソフトウェア愛好家に適したソリューション
  • 設計範囲を狭く定めることで、保守と管理を容易にしている

主な機能

  • クライアントノード間のWireGuard公開鍵交換
  • 各ノードへのIPアドレス割り当てと境界設定
  • ユーザー間でのマシン共有機能
  • ノードのルート広告管理
  • 公式機能一覧はこちらで確認可能

サポートされるクライアントOS

インストールと実行に関する案内

  • リバースプロキシ(reverse proxy)やコンテナベースでの実行は公式には推奨されていない
  • 実行方法と設定は公式ドキュメントを参照

コミュニティと貢献

開発環境とコードスタイル

  • 開発に必要な主なツール:
    • 最新版のGo
    • Buf（Protobufジェネレーター）
    • Nixを使った開発環境の構築が可能（nix developコマンド）
  • コードスタイル:
    • Goコード: golangci-lint、golines、gofumptを使用
    • Protoコード: buf、clang-formatを使用
    • その他のファイル: prettierで整形
  • コミット前にはmake lint、make fmtでコード整形が必須

ビルドとテスト

  • Protobufコードを変更した場合、Goコードの再生成が必要: make generate
  • テスト実行: make test
  • ビルド:
    • nix build
    • またはmake buildコマンドを使用

その他の情報

  • 2023年のFOSDEMでHeadscaleに関する発表を実施: 動画を見る
  • このプロジェクトはTailscale Inc.と直接の関係はないが、Tailscale所属のコントリビューターが参加しており、独立してコードレビューと方向性の策定が行われている

関連記事

1件のコメント

 
GN⁺ 2025-04-04
Hacker Newsのコメント

  • 数か月おきにこのリポジトリを見に来て、Tailnet lock が動作するようになったか、あるいはセキュリティ監査が進んだかを確認している。残念ながらどちらも進展がなく、このシステムをインフラの中核部分として信頼できるのか確信が持てなくなっている

    • Tailscale SaaS の全体的な前提は、ファイアウォールの周囲にトンネルを作り、ユーザーがそれらのトンネル経由でルーティングできるものを、直感的で統合された形で管理できるようにすることにある
    • Headscale は、ファイアウォールを回避して NAT traversal を行う部分はうまく解決しているように見える。しかし、回避したものを補えるほど十分なセキュリティを提供できるのか、それとも単にローカルネットワーク管理者を困らせる道具に成り下がるのかは疑問だ
    • Tailscale 実装について、コントロールサーバーがクライアントに指示する内容をユーザーが理解したり拒否したりする手段を提供しないまま、サーバーコードをまったく監査しないのは大胆に見える

  • オーケストレーションサーバーのセルフホスティングに関心があるなら、Netbird を見てみるとよい。このツールは非常によく似ているが、サーバーがオープンソースで提供されている。したがって、有料版のすべての機能を備えたセルフホストのコントロールサーバーと、優れた GUI を持つことができる

  • Headscale がインスタンス間のピアリング/フェデレーションを許可するとよいと思う（ACL の作り直し後でも）。主な問題のひとつはアドレス衝突だ

    • 提案: ユニークローカルアドレス（ULA）範囲の IPv6 専用オーバーレイネットワークに専念し、残りの 121 ビットを、20 ビットはデバイスアドレス（約 100 万個）、101 ビットはサーバーの公開鍵ハッシュに分ける。他のインスタンスの公開鍵を追加し、ポリシーと ACL を使ってノード間通信を管理する
    • このアイデアはよいと思うが、2023 年にこの問題を提起したとき、メンテナーの kradalby はスコープ外だと言っていた GitHub issue リンク

  • プロジェクト名の Headscale をタイトルに追加すべきだ

    • Headscale は HN に何度も登場している

  • Plan 9 で動くのか気になる

  • Headscale が大好きだ。私たちはこれを本番導入したが、とても良かった

  • Tailscale コーディネーションサーバーが侵害され、tailnet lock が有効になっている場合、自分のデバイスが侵害されるリスクがどれくらいあるのか気になる

  • 多くのユースケース（モバイルアクセス、macOS の GUI）では、公式 Tailscale クライアントはコントロールサーバーを設定できる能力に依存している

    • Tailscale で避けられない機能縮小が始まれば、この機能はなくなるだろう
    • 過去に他社が売却されたり、VC 資金が尽きたりして何度も失望してきたが、現時点では非常に満足している Tailscale の顧客としてそう言っている

  • この構成が wireguard + openwrt の構成と比べて、どんな付加価値を提供するのか気になる

  • 「Tailscale 実装について、コントロールサーバーがクライアントに指示する内容をユーザーが理解したり拒否したりする手段を提供しないまま、サーバーコードをまったく監査しないのは大胆に見える」という記述は、Headscale コントロールサーバーのソースコードを公開するだけでは、ユーザーが「コントロールサーバーがクライアントに指示する内容を理解したり拒否したりできる」ための十分条件にならないことを示唆している

    • Headscale コントロールサーバーを使う場合、ユーザーは「コントロールサーバーがクライアントに指示するあらゆることを理解したり拒否したりできる」。これは、ソースコードを読み、編集し、コンパイルすることで実現できる
    • Tailscale コントロールサーバーを使う場合、ユーザーは Tailscale 社が許可する範囲でのみ「コントロールサーバーがクライアントに指示する内容を理解したり拒否したりできる」。ユーザーはソースコードを編集したりコンパイルしたりすることを禁じられている
    • すべてのユーザーが、自分たちが使うサードパーティ製ソフトウェアを読み、編集し、コンパイルする選択肢を求めているわけではない。一部のユーザーは、シリコンバレーの VC 資金で運営される企業の継続的な保証に依存することに満足しているかもしれない。100% オープンソースのプロジェクトを望むユーザーにとっては、Headscale は有用かもしれない
    • Headscale の作者は、Tailscale コーディネーションサーバーを「本質的には公開鍵のための共有 Dropbox」と呼んでいる