Tailscaleがホームサーバーに接続できない場合に確認すべきことは何ですか？

Tailscaleがホームサーバーに到達できない場合、失敗は必ずしもTailscaleネットワーク内にあるとは限りません。サーバーがオフラインであるか、デバイス名が解決されないか、アクセスルールが接続を拒否しているか、OSのファイアウォールがサービスをブロックしているか、アプリケーションがlocalhostのみでリッスンしている可能性があります。

原因を見つける最速の方法はレイヤーごとにトラブルシューティングすることです。まず両方のTailscaleノードがオンラインであることを確認し、次にサーバーの生のTailscale IPをテストし、基本的なノード接続とアプリケーションアクセスを分けて、症状が実際に示す場合にのみサブネットルーティングやDERPのトラブルシューティングに進みます。

どのレイヤーが失敗しているかを特定することから始める

よくあるトラブルシューティングの誤りは、すべてのタイムアウトを同じ問題として扱うことです。tailnetでオフラインに見えるホームサーバーは、Tailscale pingには応答するがSSHやウェブ接続を拒否するサーバーとは異なります。

Tailscaleはデバイス間のプライベートネットワーク経路を提供しますが、最終的なサービスはサーバーのOS、ファイアウォール、リッスンポート、アプリケーション設定、Dockerネットワーク、アクセスポリシーに依存します。誤ったレイヤーを修正すると、接続を回復せずに追加の問題を引き起こすことがあります。

何かを変更する前に、正確な症状を書き留めてください。サーバーがオンラインに見えるか、Tailscale IPが応答するか、MagicDNS名が解決するか、特定のアプリケーションポートが接続を受け入れるかを確認します。

両方のTailscaleノードがオンラインであることを確認する

接続に関わる2台のデバイスから始めます。リモートのノートパソコンや電話はtailnetに接続されている必要があり、ホームサーバーも期待されるアカウント、タグ、またはデバイスIDでオンラインでなければなりません。

Linuxサーバーでは、Tailscaleサービスを確認し、次を実行します tailscale statusデスクトップシステムでは、クライアントが一時停止、ログアウト、認証待ちではなく接続されていることを確認してください。再起動後にTailscaleが起動しなかったサーバーは、DNSやアプリケーションポートを変更しても修正できません。

サーバーが期待されるデバイス名とTailscale IPで表示されるかも確認してください。ノードがオフラインの場合は、サービス、ログイン状態、システム起動動作、クライアントバージョンを修正してからネットワーク層以上のトラブルシューティングを行ってください。

ホスト名をテストする前に生のTailscale IPを使う

ホスト名は接続経路にDNS解決を追加します。サーバー名から始める場合は ホームサーバー または NASデバイスネットワークか名前解決のどちらが原因かすぐには判断できません。

サーバーのTailscale IPv4アドレス（通常は100.x.x.x範囲）を見つけて直接試してください。LANルート、出口ノード、重複サブネットが経路を複雑にする場合、プライベートLANアドレスの前にTailscale IPをテストすることが特に有効です。

生のIPは動作するがホスト名が動作しない場合、基本的なノード接続は正常です。Tailscaleの再インストールやルーターの変更ではなく、MagicDNSとクライアントのDNS設定を確認してください。

IPは動作するが名前が失敗する場合はMagicDNSを確認してください

MagicDNSは、TailscaleのIPアドレスを覚える代わりに読みやすいマシン名を使えるようにします。正常に動作すると、名前が ホームサーバー 同じtailnet内の別のデバイスからその名前でアクセスできます。

この機能はtailnet内で自動的にデバイス名を作成しますが、解決が成功するにはデバイスが接続されていてクライアントがtailnetのDNS設定を受け入れている必要があります。ローカルDNSフィルター、企業のセキュリティツール、カスタムリゾルバー、古いキャッシュされたレコードが干渉することがあります。

短いホスト名、完全なtailnet名、生のTailscale IPを比較してください。名前だけが失敗する場合は、MagicDNSが有効か、マシン名が変更されていないか、他のDNS製品がリゾルバー設定を上書きしていないかを確認してください。

Tailscaleの接続性とアプリケーションの接続性を分けて考える

ノード間の接続が成功しても、サーバー上のすべてのサービスにアクセスできることを証明するわけではありません。TailscaleのIPにpingは通っても、SSH、Jellyfin、ダッシュボード、SMB、Dockerのウェブインターフェースがタイムアウトすることがあります。

通常、これはTailscaleの経路は存在するが、アプリケーション層が接続を拒否しているか欠落していることを意味します。サービスが停止している、別のポートで待機している、誤ったインターフェースにバインドされている、サーバーファイアウォールによりブロックされている、またはコンテナから公開されていない可能性があります。

必要な正確な宛先をテストしてください。例えば 100.x.x.x:22 SSHまたは http://100.x.x.x:8080 ウェブサービスの場合。ノードが応答してもポートが応答しない場合は、サーバー側のサービスが確認されるまでMagicDNSとDERPのトラブルシューティングを停止してください。

正しいインターフェースでリッスンしているか確認してください

アプリケーションはホームサーバー上で正常に動作していても、他のすべてのデバイスからは到達できないことがあります。これはサービスが 127.0.0.1でリッスンしている場合、サーバー自身からの接続は受け入れますが、LANやTailscaleインターフェース経由の接続は受け入れません。

サービスが 0.0.0.0 すべての利用可能なインターフェースでIPv4トラフィックを受け入れる一方で、サービスはサーバーのLANアドレスやTailscaleアドレスに明示的にバインドされることもあります。正しい選択は、サービスがLAN、tailnet、またはローカルリバースプロキシ経由のみで到達可能であるべきかによります。

すべてのサービスを自動的に変更してはいけません 0.0.0.0まず意図したアクセス経路を確認し、その後ファイアウォールルールとアプリケーション認証を使ってポートにアクセスできるユーザーを制限してください。

サーバーのファイアウォールがTailscaleトラフィックをブロックしている可能性があります

サービスはホームサーバーのLAN IP経由では動作しても、Tailscale IP経由では失敗することがあります。これはOSがTailscaleインターフェースを別のネットワーク経路として扱うためです。LANルールは必ずしもTailscale経由のトラフィックに適用されません。 tailscale0.

LinuxシステムはUFW、firewalld、iptables、nftablesを使用することがあります。WindowsはTailscaleアダプターをホームLANとは異なる分類にする場合があります。より広範なネットワークファイアウォールも直接UDP接続を妨げ、トラフィックを中継経路に強制することがあります。関連する確認は、ファイアウォールが意図したTailscale接続経路を許可しているかどうかです。

ファイアウォール全体を無効にするのは恒久的な解決策として避けてください。Tailscaleインターフェース、選択したTailscaleアドレス、または適切なtailnetポリシーから必要なサービスポートのみを許可し、その後アプリケーションを直接再テストしてください。

アクセスポリシー、権限、タグ、デバイスIDを確認してください

あるTailscaleデバイスがホームサーバーにアクセスでき、別のデバイスができない場合、その違いはネットワーク障害ではなく意図的なポリシーの可能性があります。アクセスはユーザー、送信元デバイス、宛先タグ、プロトコル、ポートに依存します。

インフラアクセス用にタグ付けされたサーバーは、ポリシーで許可されていない限り、個人用デバイスからのトラフィックを受け入れない場合があります。SSHを許可するルールがあっても、別のポートのウェブダッシュボードを許可するとは限らず、共有デバイスは同じユーザー所有のデバイスとは異なる権限を持つことがあります。

送信元のID、宛先のID、サーバータグ、および要求されたポートを一緒に確認してください。一時的に広範なルールを設定してポリシーの問題を特定することは有効ですが、テスト後は最も狭い正しいルールに置き換えてください。

直接接続されたホームサーバーにはサブネットルーターは不要です

Tailscaleがホームサーバーに直接インストールされている場合は、サーバー自身のTailscale IPまたはMagicDNS名を使用してください。そのマシンに到達するためにサブネットルーターは必要ありません。

サブネットルーターは別の問題を解決します：プリンター、カメラ、古いNAS、スマートホームデバイス、またはホームLAN上の他のマシンなど、Tailscaleを実行していないデバイスへのアクセスを提供します。

単純な直接ノードの問題にサブネットルーティングを追加すると、接続が失敗する可能性が増えます。まずホームサーバー上のTailscaleクライアントに到達可能であることを証明してください。実際のターゲットがそのサーバーの背後にある場合にのみ、広告されたLANルートのトラブルシューティングを行います。

サブネットルーティングには完全なルーティングチェーンが必要です

ターゲットがTailscaleを実行していないLANデバイスの場合、サブネットルーターはオンラインに見えるだけでなく、tailnetからのトラフィックを受信し、ホームLANに転送し、応答が戻ることを許可しなければなりません。

正常に動作するセットアップには通常、ルーティングデバイスでのIP転送、広告されたサブネットルート、ルート承認、一致するアクセス制御、および必要に応じたクライアント側のルート受け入れが必要です。目的はゲートウェイを通じてプライベートサブネットを広告し、tailnetデバイスがクライアントを実行していないマシンに到達できるようにすることです。

ルートが見えているのにトラフィックが失敗する場合は、各段階を個別に確認してください。正しいサブネットが広告されているか、承認されているか、転送ファイアウォールを検査し、LANデバイスに有効な戻り経路があるかを確認します。

重複するプライベートサブネットはトラフィックを誤った方向に送る可能性があります

多くの家庭、オフィス、ホテルのネットワークは192.168.1.0/24のようなアドレスを再利用しています。もし現在のWi-Fiと自宅のサブネットが同じレンジを使用している場合、OSは宛先をローカルとみなし、Tailscale経由で送信しないことがあります。

これにより混乱を招く症状が発生します：サーバーの直接のTailscale IPは機能しますが、そのホームLANのIPは機能しません。リクエストはリモートサブネットルーターではなく現在のネットワークに送られている可能性があります。

可能な限りターゲットのTailscale IPを使用してください。サブネットアクセスが必要な場合は、1つのLANをあまり一般的でないプライベートレンジに変更するか、重複するネットワークを意図的に処理するルーティング設計を検討してください。

出口ノードは現在のLANへのアクセスを変更することがあります

クライアントデバイスがTailscale出口ノードを使用している場合、そのルート選択は通常のtailnet接続とは異なります。ローカルネットワークアクセスが明示的に許可されていない限り、近くのLANデバイスへのアクセスはブロックされることがあります。

これは、ホテル、オフィス、自宅のWi-Fiに接続したラップトップからトラブルシューティングする際に重要です。プライベートLANアドレスに到達できない場合、それはホームサーバーではなく出口ノードの動作による可能性があります。

出口ノードなしでテストするか、ローカルネットワークを信頼する場合のみLANアクセスを有効にしてください。未知の公共Wi-Fiで広範なローカルアクセスを自動的に有効にしないでください。

Dockerは別のポートとインターフェースの境界を追加します

SSHのようなホストサービスはTailscale経由で動作するのに、同じサーバー上のDockerアプリケーションが失敗することがあります。これは通常、ノードの接続性ではなくコンテナのネットワーク設定に問題があることを示します。

コンテナが実行中か、アプリケーションがコンテナ内でリッスンしているか、そのポートがホストに公開されているかを確認してください。Composeのマッピング例として 8080:80 コンテナのポート80をホストのポート8080に公開しますが、ポートがバインドされているのは 127.0.0.1 Tailscale IPを通じてアクセスできないままである可能性があります。

リバースプロキシルート、ホストネットワーキング、Dockerファイアウォールルール、およびアプリケーション自体が非LANアドレスからの接続を許可しているかどうかも確認してください。ホストポートを直接テストしてから、上位のドメインや証明書のデバッグを行いましょう。

DERPは完全な接続失敗よりも遅延の原因を説明することが多いです

Tailscaleはデバイス間の直接接続を試みます。NATの動作やファイアウォールの制限でそれが妨げられる場合、代わりにリレーパスを使用できます。

DERPは直接接続が失敗した場合の暗号化リレーフォールバックを提供します。リレーはすでに暗号化されたトラフィックを転送し、IPv4、IPv6、NAT、およびファイアウォールの複雑な組み合わせを越えてデバイスを接続できます。

DERPパスは遅延が大きかったりスループットが低かったりすることが多いため、SSHが遅いと感じたりファイル転送が遅い場合の有力な原因です。接続がまったく機能しない場合は、まずノードの状態、アクセスポリシー、ローカルファイアウォール、アプリケーションポート、およびバインドアドレスを確認してください。

ルーターを変更する前に接続診断を使用してください

次のようなコマンド tailscale ping ノードパスとアプリケーションパスを区別するのに役立ちます。成功した結果は、アプリケーションのポート、プロキシ、証明書に依存せずに接続性をテストするため、失敗したブラウザタブよりも信頼性があります。

tailscale netcheck UDPの利用可能性、NATの動作、IPv4またはIPv6の接続性、近隣のリレー地域を示すのに役立ちます。これらの結果は、接続がリレー経由でのみ機能する場合やネットワーク間で変化する場合に最も有用です。

ホームルーターにパブリックポートフォワーディングを追加することから始めないでください。Tailscaleはホームサーバーのアプリケーションポートを直接インターネットに公開せずに動作するよう設計されています。ルーターの変更は、確認された経路問題に対応するものであり、前の診断ステップの代わりではありません。

障害のあるレイヤーがわかってから再起動とアップデートを行う

Tailscaleの再起動は失敗したデーモンや古いクライアント状態を復元できますが、繰り返しの再起動は診断ではありません。毎回再起動後に同じ障害が発生する場合、根本的な問題は起動設定、ファイアウォールポリシー、ルーティング、またはアプリケーションのバインドにある可能性が高いです。

ホームサーバーがインタラクティブなデスクトップログインなしでTailscaleを起動し、再起動後も接続を維持することを確認します。また、1台のデバイスが他のtailnetのデバイスと異なる動作をする場合はクライアントバージョンを比較してください。

アップデートや再起動後は、同じ順序で同じテストを繰り返します：ノードステータス、生IP、ホスト名、Tailscale ping、アプリケーションポート。一貫したテストシーケンスは、どのレイヤーが実際に変わったかを示します。

1つのトラブルシューティング順序に従う

最速の経路はTailscaleノードからアプリケーションに向かうことです。DNS、サブネットルート、ファイアウォールルール、Dockerネットワークを同時に変更しないでください。

まず両方のノードがオンラインであることを確認します。次に生のTailscale IPをテストし、その後MagicDNS名をテストします。ノード経路をテストし、次にアプリケーションポートをテストします。これらのチェックの後にのみ、サーバーファイアウォール、バインドアドレス、アクセスポリシー、Dockerマッピング、またはサブネットルーティングを調査してください。

この順序は、単純なサービス停止が複雑なルーティング問題に発展するのを防ぎます。各テストは次のレイヤーに進む前に1つの質問に答えるべきです。

最終的な結論

Tailscaleがホームサーバーに接続できない場合は、最も簡単な区別から始めましょう：2つのTailscaleノードが通信できるか、アプリケーションがトラフィックを受け入れられるかを確認します。両方のノードがオンラインであることを確認し、生のTailscale IPをテストし、次にMagicDNS名と正確なサービスポートをテストします。

ノード経路が機能してアプリケーションが動作しない場合は、サーバーファイアウォール、リッスンインターフェース、アプリケーション設定、Dockerポートマッピング、アクセスポリシーに注目してください。ターゲットがTailscaleを実行していない場合は、サブネットルーターの設定、ルート承認、IP転送、重複サブネットの確認に進んでください。

DERP中継経路は通常、完全な障害よりも遅いパフォーマンスの原因です。接続がどこで止まっているか分からないままTailscaleの再インストール、ファイアウォールの無効化、公開ポート転送の追加をするよりも、一貫したレイヤーごとのテストが効果的です。

よくある質問

なぜTailscaleサーバーにpingは通るのにWebインターフェースが開けないのですか？

ノード間接続は機能していますが、Webサービスが停止している、別のポートでリッスンしている、localhostのみにバインドされている、サーバーファイアウォールによりブロックされている、またはDockerコンテナから公開されていない可能性があります。

なぜTailscale IPは機能するのにサーバー名は機能しないのですか？

これはMagicDNSまたは他のDNS設定の問題を示しています。MagicDNSが有効か、マシン名が変更されていないか、他のDNSリゾルバーがTailscaleの設定を上書きしていないか確認してください。

ホームサーバーにアクセスするにはサブネットルーターが必要ですか？

そのサーバーに直接Tailscaleがインストールされている場合はありません。Tailscale IPまたはMagicDNS名を使用してください。Tailscaleを実行していない他のLANデバイスにアクセスするにはサブネットルーターが必要です。

ノードがオンラインでもファイアウォールがTailscaleをブロックすることはありますか？

はい。Tailscaleクライアントはテイルネットに接続できますが、OSのファイアウォールがTailscaleインターフェース経由で到着するSSH、Web、SMB、または他のアプリケーションポートをブロックしている場合があります。

DERP接続はTailscaleが壊れていることを意味しますか？

いいえ。DERPは直接接続が確立できない場合の暗号化されたフォールバックです。遅延が増えたりスループットが低下したりすることがありますが、デバイス間の接続は維持されます。

なぜサーバーには接続できるのにホームLANの別のデバイスには接続できないのですか？

サーバーは直接のTailscaleノードですが、もう一方のデバイスはサブネットルーターが必要です。IP転送、広告ルート、ルート承認、アクセスルール、LANデバイスの戻り経路を確認してください。

重複するホームとリモートのサブネットはTailscaleのアクセスを妨げますか？

はい。両方の場所が同じプライベートサブネットを使用している場合、クライアントはリモートサブネットルートではなく現在のLANにトラフィックを送信する可能性があります。ターゲットのTailscale IPを優先するか、どちらかのネットワークのアドレス範囲を変更してください。

Tailscaleを修正するためにルーターのポートを開けるべきですか？

通常はそうではありません。まずノードの状態、ファイアウォールの動作、アプリケーションのバインディング、アクセスポリシー、接続が直接か中継かを確認してください。アプリケーションポートの公開転送は、実際のTailscaleの障害を見つける代わりにはなりません。