原因は非常に明確です。これはすべてのアプリケーションに影響するDockerの障害ではありませんでした。ユーザーがTailscaleでExit Nodeを設定した後、JellyfinなどのアプリURLがローカルネットワーク上でも開けなくなっていました。その後、Tailscaleをアンインストールし、ZimaOSのLAN IP経由で接続したところ、すべて正常に動作するようになったと報告しています。
この挙動は、現在のTailscaleドキュメントの説明と一致します。クライアントがExit Nodeを使用すると、ローカルネットワークアクセスを許可が有効になっていない限り、ローカルLANへのアクセスはデフォルトで無効になります。アプリケーションを再インストールしたりDockerを再起動したりする前に、ルーティングテーブルと、クライアントが意図的にExit Node経由でトラフィックを送信していないかを確認してください。
アプリの直接ポートも機能しなかった
ユーザーはアプリケーションのポートを直接開こうとしましたが、Tailscale経由以外はすべて機能しなかったと述べています。これは有用な手がかりです。複数の無関係なコンテナが同時に到達不能になった場合は、各アプリが個別に壊れたと考える前に、共有ネットワークやルーティングの層を確認してください。
失敗したDocker再起動コマンドは本質的な問題ではなかった
ZimaOSは、オンラインチュートリアルにあるすべてのサービス管理コマンドが適用できる一般的なDebianシステムではありません。すべてのアプリが機能しない場合は、まずコンテナが実際に稼働しているか、公開ポートにホストまたはLANから到達できるかを確認してください。
Exit Nodeはクライアントのデフォルトルートを変更する
TailscaleのExit Nodeは、一般的なインターネットトラフィックを別のtailnetデバイス経由でルーティングします。現在のTailscaleドキュメントには、Exit Nodeの使用中はローカルネットワークアクセスがデフォルトで無効になると明記されています。
現在のTailscaleにおけるExit Nodeの動作を参照してください。
意図的に両方を使用する場合は「ローカルネットワークアクセスを許可」を有効にする
現在のTailscaleクライアントには、ローカルネットワークアクセスを許可というオプションがあります。CLIベースのクライアントでは、Exit NodeのLANアクセス用フラグで同等の設定を行えます。
ローカルネットワークを信頼できる場合にのみ有効にしてください。
問題を切り分けるにはExit Nodeを無効にする
簡単な診断方法は、アクティブなExit Nodeとしてなしを選択し、ZimaOSのLAN IPといずれか1つのアプリポートを再試行することです。ローカルアクセスがすぐに復旧するなら、Dockerではなくルーティング設定を重点的に調べるべきです。
投稿者はTailscaleを削除し、復旧を確認した
ユーザーによると、Tailscaleの設定経由で接続すると、コンピューターがルーターやローカルIPへの経路から切断されていました。TailscaleをアンインストールしてローカルIPを使用したところ、すべてのアプリが再び動作しました。
これは投稿内で確認された復旧結果です。ただし、問題の動作を引き起こした正確なExit Nodeのフラグについては記録されていません。
よりよいトラブルシューティングの順序
- LAN IPを使ってZimaOSダッシュボードを直接開く。
- アプリのポートが1つでもローカルで機能するか確認する。
- 有効なTailscaleのExit Nodeを無効にする。
- ローカルからアプリに再度アクセスする。
- それでもポートを利用できない場合にのみ、Dockerやアプリのログを確認する。
すべてのアプリで「サービスを利用できません」と表示される場合のFAQ
アプリを再インストールすれば、元の問題は解決しましたか？
いいえ。問題のあるTailscaleのルーティング状態を削除した後にのみ、アプリが動作するようになりました。
TailscaleのExit NodeによってローカルLANへのアクセスがブロックされることはありますか？
はい。現在のTailscaleドキュメントによると、Exit Nodeの使用中は、ユーザーがローカルネットワークアクセスを有効にしない限り、LANアクセスはデフォルトで無効になります。
Docker自体が壊れていることは確認されましたか？
いいえ。投稿の解決結果は、Dockerデーモンの障害ではなく、ルーティングの問題を示しています。
