Tailscaleコンテナは、サブネットルーターとして機能していなくても接続済みと表示されることがあります。この2026年4月のZimaOSスレッドでは、TailscaleはDocker上でホストネットワーク、特権モード、 /dev/net/tun マウントされていたにもかかわらず、Tailscale管理コンソールには、そのマシンがルートを公開していないと表示されました。Navidromeはローカルネットワークでは動作しましたが、tailnet経由でリモートからアクセスできませんでした。
このスレッドは、元の投稿者による修正成功の確認をもって終了したわけではありません。その代わり、別のコミュニティメンバーが、自身のZimaOS環境でLANサブネットの広告に成功した、動作するBigBear Tailscaleコンテナ設定を共有しました。この設定はトラブルシューティングの参考にはなりますが、すべてのTailscaleアプリパッケージに対するIceWhaleのサポート保証ではありません。
Tailscaleに接続済みでもサブネットルートが広告されるとは限らない
元の設定では、デバイス認証はすでに完了していました。問題はルーティングに限られていました。ログにはルート一覧が空であることが示され、Tailscale管理コンソールには承認可能なサブネットルートが表示されませんでした。
この違いは重要です。通常のTailscaleノードはtailnetに参加するだけですが、サブネットルーターには追加の役割があります。1つ以上のLANプレフィックスを広告し、tailnetとそのLANの間でトラフィックを転送するために必要なオペレーティングシステムのルーティング要件を満たさなければなりません。
現在のTailscaleドキュメントでは、サブネットルーターを、tailnet上のデバイスにプライベートネットワークを広告するゲートウェイとして説明しています。また、LinuxでのIPフォワーディングと、Tailscale管理コンソールでのルート承認も必要です。ただし、 autoApprovers ポリシーによって承認が自動的に処理されます。
動作するコミュニティの参考例ではTS_ROUTESを使用
TomasSzwedの返信では、BigBear Tailscaleコンテナを使用し、起動後に手動で一度だけコマンドを実行するのではなく、環境変数でサブネットを設定していました。この参考例の重要な部分は次のとおりです。
-
network_mode: host; - 特権モード、
-
/dev/net/tunコンテナにマウントし、 -
TS_USERSPACE=false; -
TS_ROUTES=192.168.2.0/24広告対象のLAN用に、 -
TS_EXTRA_ARGS=--accept-routesそのユーザーの設定では、 - 永続的なTailscale状態を
/var/lib/tailscale.
ネットワークに合った正しいLANプレフィックスを使用する
動作した例で広告された 192.168.2.0/24この値が意味を持つのは、そのサブネットを使用するLANの場合だけです。別のホームネットワークでは 192.168.1.0/24, 10.0.0.0/24、または別のプライベートプレフィックス。
誤ったサブネットを広告すると、Tailscaleノード自体は正常でも、意図したZimaOSサービスへルーティングできない状態になる可能性があります。設定する前に、実際のローカルネットワークのプレフィックスを確認してください TS_ROUTES または同等の --advertise-routes オプション。
広告されたルートは、引き続き有効化する必要があります
現在のTailscaleのガイダンスでは、ルートの広告とルートの承認を分けて扱います。サブネットルーターがルートを広告すると、そのルートは、tailnetポリシーによって自動的に承認される場合を除き、Tailscale管理コンソールで有効にする必要があります。
管理コンソールで、そのマシンがルートをまったく公開していないと表示される場合は、まずコンテナのルート広告設定を確認してください。ルートが表示されるのにトラフィックが機能しない場合は、ルートの承認、アクセス制御ポリシー、フォワーディング、さらに宛先サービス自体を確認してください。
Dockerのネットワーク設定によって、コンテナがルーティングできる範囲が変わります
元の投稿者はホストネットワークを使用し、TUNデバイスをマウントしていました。コミュニティの参考例でも同じ構成が使われていました。現在のTailscaleドキュメントでもDocker内でのTailscale実行がサポートされていますが、DockerのネットワークとTailscaleのルーティングは別の層であり、両方を正しく設定する必要があります。
ZimaOS App Storeにある2つのTailscaleアプリが、同一のコンテナ定義を使用していると考えないでください。元の投稿者は、共有された例がBigBearのTailscaleパッケージを使用している一方で、自分の既存のインストールでは別のTailscale項目を使用していることに気づいていました。
Navidromeやその他のローカルサービスにとっての意味
元のスレッドの目的は、パブリックポートフォワーディングを使わずにiPhoneからNavidromeへアクセスすることでした。NavidromeがすでにローカルLAN上でアクセス可能であれば、正常に動作するサブネットルーターによって、そのLANアドレスを承認済みのtailnetデバイスから利用できるようになります。
ただし、そのスレッドでは、元の投稿者がBigBearの設定への切り替えを完了したことも、その後Navidromeに正常にアクセスできたことも確認されていません。したがって、このページは実行可能なコミュニティの参考例と診断モデルを示すものであり、そのインストール環境での解決を確認したものではありません。
ZimaOS Tailscaleサブネットルーティングに関するFAQ
Tailscaleでは接続済みと表示されるのに、サブネットルートが表示されないのはなぜですか？
tailnetへの参加とLANルートの広告は別の操作です。元のケースでは認証に成功しましたが、ルート一覧は空のままでした。
ZimaOS上でDockerのTailscaleをサブネットルーターとして動作させられますか？
あるコミュニティメンバーは、ZimaOSの環境で動作したと報告し、BigBearのTailscale設定を共有しました。Tailscale自体もサブネットルーティングとDockerでのデプロイをサポートしていますが、ZimaOSアプリの正確な設定も重要です。
Tailscaleでルートを承認する必要がありますか？
現在のTailscaleの動作では、広告されたサブネットルートは通常、管理コンソールで承認する必要があります。ただし、 autoApprovers ポリシーによって自動的に処理されます。
スクリーンショットの192.168.2.0/24をコピーすればよいですか？
いいえ。公開したいLANの実際のサブネットを使用してください。スクリーンショットの値は、別のコミュニティメンバーのネットワークのものです。
