通常のTailscale Dockerアプリは便利ですが、コンテナ化されたVPNは、LinuxホストにTailscaleを直接インストールした場合と常に同じように動作するとは限りません。元の著者は、実際のTUNデバイスを備えた一級市民のホストデーモンを求めており、ZimaOS自体をサブネットルーターまたはexit nodeとして動作させ、tailnetから到達可能なリソースをマウントできるようにしました。
ZimaOSにはアプライアンス型の読み取り専用ルートがあり、従来の apt install tailscale パスで、著者はTailscaleを次の形式でパッケージ化しました。 systemd-sysext 拡張機能。このプロジェクトはコミュニティ製であり、IceWhaleがサポートするTailscaleパッケージではないため、そのコマンドとライフサイクルは適切に区別して記載する必要があります。
なぜTailscaleをホスト上で実行するのか？
元の著者は、Dockerのユーザー空間ネットワークは通常の接続には十分だが、ホストレベルのルーティングでは扱いにくいと説明しました。ネイティブデーモンならカーネルのTUNデバイスを直接使用し、統合できます。 systemctl、IPフォワーディング、サブネットルート、exit-nodeの動作。
systemd-sysextがZimaOSに適している理由
systemd-sysextは、次のような場所に追加ファイルをオーバーレイします /usr 実行時に、イミュータブルなベースイメージを変更せずに。著者はTailscaleの上流Buildrootレイアウトを再現し、永続的な認証状態を次の場所に保存しました /DATA/AppData/tailscale/.
プロジェクトはホスト用インストールスクリプトを提供する
コミュニティリポジトリのクイックスタート手順では、プロジェクトをクローンし、sudoでインストーラーを実行した後、次のコマンドで認証します tailscale upこれはroot権限で実行されるサードパーティー製コードなので、実行前にリポジトリとリリース履歴を確認してください。
古いフォーラム版をコピーするのではなく、現在のsysextプロジェクトと保守されているインストール手順をお読みください。
認証状態は使い捨ての拡張機能の外部に保存される
プロジェクトはノードの状態を次の場所に保持します /DATA/AppData/tailscale/これにより、TailscaleのIDは再構築または置き換え後も維持されます。 .raw sysextファイル。
初回リリース後に実際の再起動バグが見つかった
ユーザーが次のように報告しました tailscaled 再起動後に起動しませんでした。プロジェクトの著者が再現し、競合について次のように説明しました。 multi-user.target 前にサービスの依存関係を解決しました systemd-sysext.service 拡張機能を統合済みだったため、systemdがターゲットを構築した時点ではサービスユニットが存在していませんでした。
v1.0.1でWatchdogタイマーを追加
著者は、永続ルート上に保存した小さなタイマーとoneshotサービスで起動競合を修正しました /etc/systemd/system/これは起動直後に実行され、開始します tailscaled sysextオーバーレイが存在した直後に。
元の著者は、実際の再起動で修正を確認したと報告しました。
IPフォワーディング設定は別の永続化に関する問題だった
このスレッドでは、サブネットルーターのsysctl設定が再起動後も維持されるかどうかも質問されました。著者は、ZimaOSが永続化することを説明しました /etc 永続ストレージを基盤とするオーバーレイを通じて、そのため /etc/sysctl.d/ 維持され、再適用されます。
これらのフォワーディング設定は、サブネットルーターやイグジットノードとして使用する場合に必要であり、通常のTailscaleクライアントには必要ありません。
IPv6の制限はZimaOSのカーネルによって変わりました
2026年5月に公開された元のモジュールでは、ZimaOS 1.6.1／カーネル6.12.25にIPv6ポリシールーティングに必要なカーネルオプションがなく、そのためTailscaleがトンネル経由のIPv6を無効にしていたことが説明されていました。
7月30日、IceWhaleの新しいカーネルによって必要なIPv6機能が提供されたため、作者はスレッドを更新しました。現在のプロジェクトリポジトリでは、ZimaOS 1.7.0／カーネル6.18.9でIPv6のtailnet動作が確認されています。
ZimaOSの更新後にインストーラーを再実行する
このプロジェクトは、公式Tailscale静的バイナリからsysextを再構築し、認証状態を別途保持するよう設計されています。現在のリポジトリでは、ZimaOSのアップグレード後にインストーラーを再実行することを推奨しています。
root権限で動作するコミュニティモジュールをシステムソフトウェアとして扱う
このモジュールはNASホスト上で直接動作し、インストーラーには昇格された権限が必要です。重要なデータを保存しているシステムに導入する前に、ソース、ハッシュ、更新動作、アンインストール動作を確認してください。
このプロジェクトはZimaOS 1.7.0で再検証されました
現在のリポジトリでは、カーネル6.18.9を搭載したZimaOS 1.7.0で、再起動後の永続化やtailnetでのIPv6動作を含む、エンドツーエンドのテストに成功したと報告されています。これは、ZimaOS 1.6.1を対象に開発された2026年5月の元の投稿よりも強い証拠です。
Dockerとネイティブsysextは異なるニーズに対応します
Tailscale経由で特定のアプリケーションだけにアクセスできればよい場合は、Docker方式のほうが簡単で、ホストへの変更も最小限に抑えられます。ZimaOSホスト自体でtailnetリソースをマウントしたり、LANサブネットを広告したり、イグジットノードとして動作させたりする必要がある場合は、sysext方式が適しています。
ネイティブ方式が存在するというだけで、正常に動作しているDockerインストールを置き換えないでください。ホストレベルのルーティングが実際に必要かどうかに基づいて選択してください。
アンインストールと完全削除は異なる操作です
このコミュニティプロジェクトでは、sysextの削除とTailscaleの状態データの削除を意図的に分離しています。通常のアンインストールでは永続的なノードデータを保持できますが、完全削除では状態ディレクトリも削除されます。別のtailnet IDを作成せずに再インストールするつもりなら、この違いは重要です。
ブートウォッチドッグは現在も設計の一部です
現在のプロジェクトドキュメントでは、ZimaOS 1.7.0でもウォッチドッグが必要だと説明されています。sysext内のサービスユニットが、systemdの初期ターゲット構築に依然として間に合わない場合があるためです。新しいカーネルで修正されたのはIPv6機能であり、sysextのサービス順序に関する競合ではありません。
ネイティブTailscaleに関するよくある質問
これはIceWhale公式のTailscaleパッケージですか？
いいえ。これはコミュニティによるsystemd-sysextプロジェクトです。
Dockerではなく、これを使う理由は何ですか？
このプロジェクトは、ホストレベルのTUN、サブネットルーター、イグジットノード、通常のsystemd統合を対象としています。
再起動時の起動問題は修正されましたか？
プロジェクトの作者はこの問題を再現し、v1.0.1でウォッチドッグベースの修正をリリースしました。
IPv6には、まだ1.6.1の制限がありますか？
このプロジェクトの報告によると、ZimaOS 1.7.0で使用される新しい6.18.9カーネルには、必要なIPv6ポリシールーティングのサポートが備わっています。
