00:00:00これはHeadscale。どんなサーバーにもインストールできる、Tailscaleのフリーかつオープンソース版です。
00:00:06インターネットがダウンしたり、Tailscaleが突然値上げしたりしても、暗号化ネットワークを完全に自分で制御できます。
00:00:13でも不思議なのは、Headscaleの開発者がTailscaleの社員だということです。
00:00:18なぜ彼らは競合製品を作る人に給料を払っているのでしょうか？
00:00:22チャンネル登録をして、その謎を探ってみましょう。
00:00:25詳細に入る前に、Headscaleが実際に動いている様子をサッと見てみましょう。
00:00:30現在、3つのHetznerサーバーがあります。1つはHeadscaleのメイン・コントロールプレーン用、あとの2つは相互に接続したいノードです。
00:00:40この2つのノードは、現在私の暗号化ネットワークの一部になっています。
00:00:44すべてDockerで動いているので、このコマンドを実行すると、現在のノード（Ubuntu TestとUbuntu Test 2）を確認できます。
00:00:53これらが、接続に使用できるIPアドレスです。
00:00:56では、この2つのノード間で相互に接続してみましょう。
00:00:59まず、このIPアドレスをコピーします。
00:01:02次にUbuntu Test 2から、rootユーザーでSSH接続します。
00:01:07テスト用なのでrootを使っていますが、本来は推奨されません。
00:01:09これがHeadscaleのIPアドレスです。
00:01:11エンターを押して画面をクリアすると、ご覧の通りUbuntu Test 1に入っています。
00:01:17Ubuntu Test 2からUbuntu Test 1に入ることができました。exitでUbuntu Test 2に戻ります。
00:01:24Ubuntu Test 1側でも同様に、rootでUbuntu Test 2のIPアドレスを指定してSSH接続してみます。
00:01:31画面をクリアすると、Ubuntu Test 1からUbuntu Test 2に入っているのがわかります。
00:01:36ですが、テールネット（Tailnet）の外、つまりMacから新しいタブでUbuntu Test 2のIPへSSH接続しようとすると、
00:01:48ネットワーク外なので、このように接続が止まってしまいます。
00:01:52見ていただいた通り、Headscaleを使えばネットワークを完全に掌握できます。
00:01:56細部までコントロールでき、ベンダーロックインを気にせず好きなだけノードを追加できます。
00:02:03古いRaspberry PiやNASに接続すれば、インターネットなしでも動作します。
00:02:08ただ、セットアップは少し複雑です。
00:02:11実際にどう動くのかお見せしましょう。
00:02:13新しく「Ubuntu Test 3」というサーバーを用意しました。新しいユーザーで、2つのノードを接続する暗号化ネットワークを作成します。
00:02:24テスト用にUbuntu Test 3とUbuntu Test 1を接続します。
00:02:29Headscaleコントロールプレーンには導入済みですが、その手順を振り返ってみましょう。
00:02:37現在、3つのDockerコンテナが動いています。
00:02:40Headscale UI、Headscale本体、そしてCaddyです。
00:02:45Docker Composeファイルを見ると、Headscale公式ドキュメントにあるものと非常によく似ています。
00:02:56Headscaleのバージョンやディレクトリパスなどは、いくつか変更しています。
00:03:03また、Headscale UIのコンテナも動かしています。これはHeadscaleで使える多くのオープンソースWeb UIの一つです。
00:03:11これについては後ほど詳しく説明します。
00:03:13さらに、リバースプロキシとしてCaddyを使っています。
00:03:16興味がある方のために、このDocker Composeファイルへのリンクを概要欄に貼っておきます。
00:03:21このディレクトリには、libフォルダとconfigフォルダもあります。
00:03:26libフォルダには、主にSQLiteデータベースが入っています。これでユーザー、ノード、DNSなどの情報を管理しています。
00:03:36SQLiteを使いたくない場合は、設定でPostgresデータベースに変更することも可能です。
00:03:43configディレクトリには、Tailscaleの設定と、人間が読みやすいJSON形式のアクセス制御リスト（ACL）ポリシーが含まれています。
00:03:52後で詳しく話しますが、まずはTailscaleのドキュメントから取得した設定を見てみましょう。私はcurlコマンドでサーバーに入れました。
00:04:01GitHubにある設定例を見ると、サーバーURLからプレフィックス、ポリシーファイルの場所まで、あらゆることが変更可能です。
00:04:11私の設定もこれに近いですが、変更したのはサーバーURLだけです。ネットワーク内のノードが相互に認識できるよう、Cloudflareのドメインを紐付けています。
00:04:23あとはポリシーのパスを追加したくらいです。
00:04:28ドメインは一般的なCloudflareのもので、Aレコードを使ってheadscaleサブドメインをコントロールプレーンのIPに紐付けています。
00:04:37準備ができたらCaddyファイルを確認します。/web配下のHeadscale UI用と、Headscaleプロキシ用の2つのURLが使われているのがわかります。
00:04:49これらの準備が整ったら、最初に行うのはユーザー作成です。次のコマンドを入力します。
00:04:56今回は「Tom」というユーザーを作りますが、名前は何でも構いません。
00:05:00ユーザーが作成されたので、リストを表示して確認します。ID 6で新しいユーザーが登録されています。
00:05:08ただ、まだこのユーザーにはノードが紐付いていません。
00:05:11それでは、Tomにノードを割り当てていきましょう。
00:05:13新しく作成したUbuntu Test 3サーバー内で、まずはこのコマンドを実行してTailscaleクライアントを追加します。
00:05:23これでTailscaleバイナリが使えるようになります。
00:05:27rootユーザーでない場合は、sudoを使って実行してください。
00:05:31ただし、Tailscaleを起動したりログインしたりする前に、Headscaleで動作させるための特定の手順が必要です。
00:05:38そのために「事前認証キー（pre-auth keys）」を作成します。コマンドはHeadscaleドキュメントの「Getting Started」ページにあります。
00:05:46下にスクロールして、このコマンドをコピーします。
00:05:49Headscaleコントロールプレーンで「docker exec」に続けてコマンドを貼り付けます。
00:05:54ユーザーIDの部分には、TomのIDである「6」を入力します。
00:05:59コンテナ内で実行するので、コマンドの頭にheadscaleを付け足します。
00:06:04これで事前認証キーが発行されました。
00:06:07このコマンドをコピーして、Ubuntu Test 3に貼り付けます。
00:06:11先ほどの事前認証キーをコピーして、ここに貼り付けます。
00:06:15そしてログインサーバーを、設定済みの自前サーバー（headscale.pandor.css）に変更します。
00:06:23Pandoraドメインが取れなかったので、このドメインにしています。
00:06:26これでエンターを押せば、Headscaleネットワークに新しいノードが追加されるはずです。
00:06:31コントロールプレーンに戻ってノードリストを確認すると、ユーザーTomに属するUbuntu Test 3が、IPアドレスと共に表示されました。
00:06:44次に、Ubuntu Test 1もTomのユーザーに追加しましょう。
00:06:47まず、既存のUbuntu Testノード（ID 1）を削除します。確認をスキップするために強制削除（force delete）を実行します。
00:06:56完了したら、別の事前認証キーを作成してUbuntu Testに追加します。SSH機能を有効にするため「--ssh」フラグを忘れないようにします。
00:07:06Ubuntu Test 3にも移動して、SSH接続を許可する設定を行っておきます。
00:07:13ノードリストを見ると、Ubuntu Test 1とUbuntu Test 3の両方がTomの配下にあります。
00:07:20では、両方に接続してみましょう。
00:07:21Ubuntu Test 3のIPをコピーし、Ubuntu Test 1からrootでSSH接続します。
00:07:30キーを有効にすると、Ubuntu Test 1からUbuntu Test 3に接続できました。
00:07:35同様に、Ubuntu Test 3からUbuntu Test 1への接続も可能です。
00:07:41もし手順通りに進めても動かない場合は、アクセス制御ポリシー（ACL）の設定が必要な可能性が高いです。
00:07:49私の設定をお見せしましょう。
00:07:51Headscaleディレクトリのconfigフォルダ内に、人間が読める形式のACL JSONファイルがあります。
00:08:01中身は非常にシンプルで、ネットワーク内の誰からでも、どの宛先・ポートへの接続も許可する設定になっています。
00:08:11SSHについても、テールネット内の全ノード間で、承認なしでrootユーザーへの接続を許可しています。
00:08:24もちろん、実際の運用では、特定のノードやポートに制限するなど、よりセキュアな設定にすることをお勧めします。
00:08:33これはあくまで導入用のシンプルな設定です。
00:08:37この設定へのリンクも概要欄に貼っておきます。
00:08:40さて、「Headscale UIを使えばもっと簡単になるのでは？」と思うかもしれません。
00:08:43答えは「イエスでもあり、ノーでもある」といったところです。
00:08:45お見せしましょう。
00:08:47これがHeadscale UIのURLです。TessとTomの2人のユーザー情報が表示されています。
00:08:48接続されているキーやノードの情報が見れますね。
00:08:57これを使うには、まずコマンドで発行したHeadscale APIキーを登録する必要があります。
00:09:01ただ、私が困ったのはデバイス一覧の表示です。
00:09:06ご覧の通り、情報があまり表示されていません。コンソールを見るとTypeScriptの型エラーが出ています。ソースは弄っていないので私のせいではないはずですが。
00:09:09この時点でアプリがフリーズしてしまい、何も操作できなくなります。
00:09:22本来ならここからデバイスを追加したり設定を変えたりできるはずなのですが。
00:09:26バグが多いので、正直あまり実用的とは言えませんでした。
00:09:32他にもHeadscale UIはいくつかあり、中にはACLの設定を簡単にしてくれるものもあります。
00:09:35ですが個人的には、今のところHeadscale UIが非常に便利だと感じるまでには至っていません。
00:09:42やはり、セットアップは少し手間がかかります。
00:09:46というか、かなり手間です。
00:09:49専門知識がない人やジュニアデベロッパーが一人で設定するのは、結構苦労するでしょう。
00:09:51Tailscaleチームが社員にこの開発を許しているのも、現時点では自社への大きな脅威にはならないと判断しているからかもしれません。
00:09:57もし誰かがClaude Opusなどを使って素晴らしいUIを作れば、面白いことになるかもしれませんが、ライセンスの関係で潰される可能性もあります。
00:10:07ただ、一度立ち上げてしまえばHeadscaleは驚くほど快適に動きます。
00:10:18FunnelやServeといった一部の機能（サーバーを公開する機能など）は、まだサポートされていませんが。
00:10:22複数のテールネット、エフェメラルノード、ネイティブなネットワークログなども未対応です。
00:10:32それでも、オープンソースツールとしては非常に印象的な出来栄えです。
00:10:38もし将来、自分のOpenClaudeをローカルLLMを使って完全オフラインで動かしたくなったら、これを使うことを検討するでしょう。
00:10:42And if I ever get to the stage where I want my OpenClaw to run completely offline with a local LLM, then I may consider it.