コミュニティソリューション

ZimaOSでTailscaleを設定:ログインURL、認証キー、永続状態

An October 2025 ZimaOS thread where one user joined Tailscale through the container terminal login URL and the original poster solved their setup with the linked App Store/auth-key workflow. Current Tailscale state settings add the missing persistence guidance.

この2025年10月のスレッドでは、ユーザーがZimaOSにTailscaleアプリを登録するために利用できた2つの有効な方法が紹介されています。1つはコンテナのターミナルから取得した対話型ログインURL、もう1つはZima-Giorgioが以前の解決済みスレッドとして案内した認証キーの手順です。元の投稿者は、最初にターミナル方式を試した際には何も表示されませんでしたが、その後、認証キーの手順を使い、問題が解決したことを明示的に示しました。

現在の完全なセットアップには、短い元の議論では扱われなかった要素がもう1つ必要です。ZimaOSまたはアプリを再起動してもノードが同じマシンとして認識され続けるよう、Tailscaleの状態ディレクトリを永続化する必要があります。

まずTailscaleコンテナが実際に実行中であることを確認する

コンテナが正常に起動し、Tailscaleのコントロールプレーンに接続できる場合にのみ、認証が役立ちます。アプリが停止している、クラッシュループしている、または必要なネットワーク機能が不足している場合、ログインURLでは実行時の問題は解決しません。

認証情報を変更する前に、アプリケーションのターミナルまたはログを開き、Tailscaleプロセスが実行中であることを確認してください。

方法1:コンテナからログインURLを使用する

コミュニティの参加者の1人は、Tailscaleアプリのターミナルを開き、次のコマンドを実行しました。

tailscale status

ノードがログアウト状態だったため、Tailscaleはブラウザー認証用のURLを返しました。

ログアウト状態とブラウザーログインURLが表示されたZimaOS Tailscaleコンテナのターミナル
ターミナル方式では、再利用可能なキーをアプリ設定に埋め込む代わりに、Tailscale標準のブラウザー認証フローを使用します。

正しいTailscaleアカウントにすでにサインインしている信頼できるデバイスで、URLを開いてください。

ユーザーのtailnetにZimaOS Linuxノードを認証するTailscaleのデバイス接続ページ
ブラウザーでの手順により、選択したtailnetにLinuxノードを承認します。

方法2:アプリ設定で認証キーを使用する

Zima-Giorgioは、ユーザーが認証キーを生成し、Tailscaleアプリの環境設定に入力した以前の解決済みスレッドを案内しました。このスレッドの元の投稿者は後に、その手順に従って問題が解決したと述べています。

Tailscale管理コンソールから、自分用の認証情報を生成してください。認証キーはパスワードと同じように扱い、公開したり、他人の値を再利用したり、スクリーンショットに保存したりしないでください。

元のユーザーはキーを生成するために適切なTailscale権限を必要とした

元のスレッドの最後の返信では、アカウントを適切に設定する手順に従った後、ユーザーがキーを生成してセットアップを完了できたと説明されています。これは、認証キーのオプションが表示されない原因が、ZimaOSアプリの問題ではなくアカウントの役割にある可能性を示しています。

Tailscale管理コンソールにノードが表示されることを確認する

Tailscaleの100.xアドレスで接続されたZimaOS Linuxデバイスを表示するTailscale管理コンソール
登録に成功すると、Tailscale IPアドレスとマシン名を持つオンラインのLinuxノードが作成されます。

ノードが表示されたら、オンライン状態だからといってZimaOS上のすべてのサービスに接続できるとは限らないため、別のtailnetデバイスから到達性をテストしてください。

マシンの状態を永続化する

現在のTailscale Dockerデプロイでは、TS_STATE_DIRを使用してtailscaledがID情報とログイン状態を保存する場所を指定します。このディレクトリは、ZimaOSの永続ストレージにマッピングしてください。

状態を永続化しない場合、ホスト名が同じでも、コンテナの再作成時にTailscaleから完全に新しいマシンとして認識されることがあります。

恒久的なZimaOSノードを構成する前に、現在のTailscale Docker認証および状態オプションを確認してください。

永続状態で自動登録するにはTS_AUTH_ONCEを使用する

認証キーを意図的にコンテナ設定に保持する場合、現在のTailscaleではTS_AUTH_ONCE=trueを使用できます。これは、有効な状態がまだ存在しない場合にのみコンテナを認証する設定です。

これにより、サービスの再起動だけでデプロイが新しいマシンとして扱われるのを防げます。

どちらの方法がよいか

個人サーバーでは、再利用可能なキーをアプリ設定に残す必要がないため、対話型ログインURLのほうが監査しやすくなります。認証キーは自動デプロイに便利で、特に永続状態および1回限りの認証と組み合わせると効果的です。

どちらも正当な方法です。元のスレッドでは、あるユーザーが認証キーで成功し、別の参加者がログインURLで成功したことが示されています。

Tailscale設定に関するよくある質問

認証キーなしでTailscaleに参加できますか?

はい。スレッドでは、アプリのターミナルからブラウザーログインURLを生成する方法が示されています。

元の投稿者は設定を解決できましたか?

はい。後に、認証キーの手順で解決したと述べています。

再起動後にノードが新しいマシンとして再び表示されるのはなぜですか?

状態ディレクトリが永続化されていないか、コンテナが新規認証を強制している可能性があります。

再利用可能な認証キーをスクリーンショットやフォーラム投稿に表示してもよいですか?

いいえ。秘密の認証情報として扱ってください。