Headscale - Tailscaleコントロールサーバーのセルフホスティング実装オープンソース
(github.com/juanfont)- Headscale は、Tailscaleコントロールサーバーをオープンソースかつセルフホスティング可能に実装したプロジェクトであり、self-hosterや趣味開発者のプロジェクト・ラボ環境を対象としている
- Tailscale は WireGuard ベースのモダンなVPNで、NAT traversal を使用し、ネットワーク上のコンピューター間でオーバーレイネットワークのように動作する
- Tailscale のコントロールサーバーは、ノードの WireGuard公開鍵交換、クライアントIP割り当て、ユーザー境界の作成、ユーザー間でのマシン共有、ノードが広告したルートの公開を担う
- Headscale は、個人利用や小規模なオープンソース組織に適した 単一のTailscaleネットワーク（tailnet） 実装を、限定的なスコープで提供する
- このプロジェクトは Tailscale Inc. とは無関係であり、Headscale の実行には リバースプロキシやコンテナの利用をサポートまたは推奨していない
Headscaleの目的と範囲
- Headscale は Tailscale コントロールサーバーの、セルフホスティング可能なオープンソース代替を目指している
- 対象ユーザーは self-hoster、趣味開発者、個人プロジェクトやラボ環境の利用者
- 実装範囲は意図的に絞られており、単一の tailnet を提供する
- 個人利用に適している
- 小規模なオープンソース組織にも適している
Tailscaleとコントロールサーバーの役割
- Tailscale は WireGuard 上に構築された モダンなVPN である
- Tailscale はネットワーク上のコンピューター間で オーバーレイネットワーク のように動作し、NAT traversal を使用する
- Tailscale では、一部のGUIクライアントとコントロールサーバーを除くすべての要素がオープンソースである
- 例外として挙げられているGUIクライアントは、Windows や macOS/iOS などのプロプライエタリOS向けクライアントである
- コントロールサーバー は、Tailscale ネットワークノード間の WireGuard 公開鍵交換ポイントとして動作する
- クライアントIPアドレスを割り当てる
- ユーザー間の境界を作成する
- ユーザー間でのマシン共有を可能にする
- ノードが広告したルートを公開する
- Tailscale network、すなわち tailnet は、Tailscale が個人ユーザーまたは組織に割り当てるプライベートネットワークである
ドキュメントとバージョンに関する注意事項
- 使用中のリリースバージョンに対応した設定例を見るには、必ず同じ GitHub tag を選択する必要がある
mainブランチには、まだリリースされていない変更が含まれている場合がある- ドキュメントは安定版と開発版で提供されている
- 機能一覧は Features 文書 で確認するよう案内している
- クライアントおよびOSのサポート範囲は Client and operating system support 文書 で確認するよう案内している
実行とビルド
- Headscale の実行には リバースプロキシとコンテナ の使用をサポートまたは推奨していない
- 実行方法は 公式ドキュメント を参照するよう案内している
- NixOS ユーザー向けモジュールは
nix/ディレクトリにある mainブランチの開発ビルドはコンテナイメージとバイナリで提供される- 詳細は development builds 文書 を参照
プロジェクトとの関係と貢献
- このプロジェクトは Tailscale Inc. とは無関係 である
- Headscale のアクティブなメンテナーの1人は Tailscale に雇用されており、勤務時間中にプロジェクトへ貢献できる
- 当該メンテナーの貢献は他のメンテナーがレビューする
- メンテナーたちは、self-hoster、熱心なユーザー、趣味開発者コミュニティを支援しながら持続可能なプロジェクトを作るという原則のもと、プロジェクトの方向性を共同で定めている
- 貢献者は CONTRIBUTING.md を読む必要がある
開発環境とワークフロー
- 貢献には最新の Go と Buf が必要
- Buf は Protobuf ジェネレーターとして使われる
- 開発環境のセットアップには Nix の使用を推奨
nix developを実行すると必要なツールがインストールされ、シェルが提供される- この方法により、Headscale メンテナーと同一の開発環境が保証される
- Go コードは
golangci-lintで lint し、golines、gofumptでフォーマットするgolinesの幅は 88 に設定されている- コミット前に
make lintとmake fmtの実行を推奨
- Proto コードは
bufで lint し、clang-formatでフォーマットする - ドキュメントは
mdformat、Markdown・YAML などその他のファイルはprettierでフォーマットする proto/を変更した場合は、Protobuf から Go コードを再生成する必要がある- コマンドは
make generate gen/の変更は、レビューを容易にするため別コミットに分けることを推奨
- コマンドは
- テストとビルドはそれぞれ
make test、make buildで実行する - 推奨ワークフローは
nix developの後にmake test、make buildを実行する方法- 依存関係を自分で管理する場合は Make を直接利用できる
- Makefile は必要なツールがない場合に警告を出し、
nix developの実行を提案する - 利用可能なターゲットは
make helpで確認できる
1件のコメント
Hacker Newsのコメント
数か月ごとにこのリポジトリに戻ってきて、Tailnet lockがついに動くようになったか、その間に誰かがセキュリティ監査をしたかを確認している
残念ながらどちらも進展がないように見え、そのためこれを自分のインフラの中核コンポーネントとしてどれほど信頼できるのか、ますます不確かになっている
Tailscale SaaSの前提は、ファイアウォールを迂回するトンネルを作り、そのトンネル経由で何をルーティングするかを、ユーザーが直感的かつ統合された形で制御できるようにすることだ
Headscaleはファイアウォール迂回と高度なNAT越えはうまくやっているようだが、いま迂回したばかりのセキュリティを補うだけの独自のセキュリティを提供できるのかは疑問だ
制御サーバーがクライアントに何をするよう指示しているのかをユーザーが理解したり拒否したりする方法がなく、サーバーコードのセキュリティ監査もまったくないなら、かなり大胆な選択に見える
これはTailscaleの基本バックエンドサービスの上に載った制御レイヤーだと思っていたのだが、新しい方式で接続を仲介しているのだろうか？
ZeroTierはかなりよく使うがTailscaleには詳しくないので、当たり前の質問かもしれない
セルフホスト型のオーケストレーションサーバーに興味があるなら、Netbirdも見る価値がある
似たツールだがサーバーもオープンソースで公開されており、セルフホスト型の制御サーバーに decent なGUIと有料版の機能が付いてくる
https://netbird.io/knowledge-hub/tailscale-vs-netbird
堅牢で強力、機能も多そうだが、Headscaleのセルフホストははるかに単純で要件も少ない
いまはTailscaleも動かし続けているが、徐々に廃止してNetbirdへ完全移行する方向に近づいている
関連するGitHub issueはこちら
https://github.com/netbirdio/netbird/issues/1103
タイトルにプロジェクト名であるHeadscaleを入れるとよさそうだ
HeadscaleはHNに何度も上がっているプロジェクトだ
Headscaleがインスタンス間のピアリング/フェデレーションをサポートするとよさそうだ。ACLの再設計後になるかもしれない
主な問題の1つはアドレス衝突だ
提案はこうだ。ユニークローカルアドレス（ULA）範囲のIPv6専用オーバーレイネットワークとし、残りの121ビットをデバイスアドレス用の下位20ビット（約100万個）と、サーバー公開鍵ハッシュである上位101ビットに分ける
別インスタンスの公開鍵を追加してフェデレーションし、ポリシーとACLでノード間通信を管理すればよい
良いアイデアだと思うが、2023年に持ち出したとき、メンテナーのkradalbyはスコープ外だと言っていた: https://github.com/juanfont/headscale/issues/1370
Headscaleを半年間うまく使っている
とても良くて、以前はTailscaleネットワークなしでどうやって暮らしていたのかわからないほどだ
OpenBSD向けにパッケージ化されていて、私はそのパッケージをサーバーとして使っている
Headscaleが気に入っていて、つい先ほど本番環境に入れたが、とてもよく動いている
ログインにはGmailドメインを使っているが、ユーザーが自分のデバイスを直接登録できるという大きな利点がある
以前のOpenVPNでは、運用チームが証明書と設定を直接渡す必要があった
唯一の欠点は、ユーザーが誤って自前サーバーではなくTailscaleのログインサーバーに接続してしまい、なぜサービスにアクセスできないのか迷う場合があることだ
ユーザーグループでアクセス可能なサービスを設定している
まだ古いバージョンのHeadscaleを使っているが、新しい制御プレーンへ移植しなければならない連携があるためだ
headscale node list | wc基準でノードは約250個で、大半はサーバーだTailscaleがルーティングテーブルとファイアウォールルールに魔法のように手を入れるのはあまり好きではないが、概ね問題にはならず、かなりうまく動いていた
いくつかのユースケース、たとえばモバイルアクセスや macOS GUI では、公式の Tailscale クライアントが制御サーバーを設定できる機能を維持してくれないと Headscale を使えない。
Tailscale で避けられない品質低下が始まった瞬間、この機能は消えるだろう。
今は Tailscale に非常に満足している顧客だが、過去に他社が売却されたりベンチャー資金が尽きたりして何度も痛い目を見てきた立場から言っている。
それもありそうな話だ。Headscale は主にホームラボユーザーや小規模な趣味ユーザーが使っており、Pulsesecure、Cisco Anyconnect、GlobalProtect ではなく、セルフホストの OpenVPN や WireGuard と競合している。
余暇に新しい技術が好きだが、インフラのコントロールは手放したくない人たちに Tailscale を紹介する経路になっている。
そういう人たちが職場に Tailscale の専門知識と熱意を持ち込むことになる。
企業は、IT インフラ管理が中核能力でない限り、あまりやりたがらない。
もちろん一部の企業は Tailscale 本製品ではなく Headscale を選ぶだろうが、企業規模と金額を考えると少数である可能性が高い。
それは売上原価に近く、Facebook 広告やシリコンバレーの道路脇の看板広告と大きく変わらない。
職場で Tailscale を使えない理由は、こちらが制御できないサーバーを通じてトラフィックがルーティングされるからだ。
職場で Tailscale を本当に使いたいし、多くの問題を解決してくれるはずだ。
ポートを開ける必要があるなら受け入れられるが、そのポートを通じてトラフィックをトンネルするのは非常に心配だ。
面白そうだ。WireGuard + OpenWrt 構成と比べて、どんな付加価値があるのか気になる。
中央で管理される ACL の制約を受けながら、そのまま動作する。
Tailscale を「単なる WireGuard オーケストレーター」と過小評価することがあるが、実際にはそれよりはるかに多い。
プロダクトの観点では、WireGuard は実装の詳細にすぎない。
私は以前 Headscale UI があまりに基本的だと感じて Netbird を選んだが、この数年で改善されているかもしれない。
多数のクライアントで動作し、私の Apple TV も Tailscale ネットワークに接続されている。
設定には 1 分ほどしかかからず、ゲートウェイとしても使える。
Tailscale や外部にホストした Headscale なら、そのように使える。
Tailscale の調整サーバーが侵害され、Tailnet lock が有効になっている場合、自分のデバイスが侵害されるリスクはどの程度なのか気になる。