tailscale-subnet-router-debug

Tailscale サブネットルーターのデバッグ

Tailscale サブネットルーターの接続障害を診断して修正します。 ルートのアドバタイズから戻り経路の確認まで、ルートのライフサイクル全体を対象とする7つのチェックを順番に実行します。

このスキルでできること

1. サブネットルーターがルートをアドバタイズしていることを確認します。
2. ルートが承認されていることを確認します（管理コンソールまたは autoApprovers）。
3. クライアントがサブネットルートを受け入れることを確認します（--accept-routes）。
4. ポリシールーティングテーブル52にインストールされたルートがあるかを調べます。
5. サブネットルーターでIPフォワーディングが有効になっていることを確認します。
6. サブネットルーターからターゲットに直接到達できることをテストします。
7. 応答トラフィックの戻り経路を確認します。

よくある問題のきっかけ

• クライアントからサブネットルーターには ping できるものの、アドバタイズされたサブネット上のデバイスには ping できない
• 管理コンソールではルートが承認済みと表示されるのに、ip route が空になっている
• Docker コンテナーで TS_ROUTES 経由のルートアドバタイズに失敗する
• ターゲットにはトラフィックが届くものの、応答が返ってこない
• 「ルーター自体からは動作するが、ほかのクライアントからは動作しない」

診断ワークフロー

各ステップを順番に実行します。最初に失敗した時点で停止し、先に修正してから続行してください。後続のステップは先行するステップに依存します。

ステップ1 — ルートがアドバタイズされていることを確認する

tailscale status --json | jq '.Self.AllowedIPs'

合格： サブネット CIDR が AllowedIPs に表示されます（例：10.100.0.0/24）。

失敗： Tailscale IP のみが表示されます。ルートはアドバタイズされていません。

修正： tailscale set --advertise-routes=<CIDR> を実行します。Docker の場合は、TS_ROUTES 環境変数を確認してください。初回起動時に認証に失敗していると、反映されないことがあります。その場合は、実行時に tailscale set を実行してください。

ステップ2 — ルートが承認されていることを確認する

管理コンソールを確認するか、ピアノードから次を実行します。

tailscale status --json | jq '.Peer[] | select(.HostName=="<router>") | .AllowedIPs'

合格： ピアから見たルーターの AllowedIPs に、サブネット CIDR が表示されます。

失敗： ピアからは Tailscale IP のみが表示されます。ルートは承認待ちです。

修正： 管理コンソールで承認するか、ACL に autoApprovers を追加します。

"autoApprovers": {
  "routes": { "10.100.0.0/24": ["tag:subnet"] }
}

ステップ3 — クライアントがルートを受け入れることを確認する

tailscale debug prefs | grep -i route

失敗： --accept-routes が false（デフォルト）です。クライアントは、承認済みであってもアドバタイズされたサブネットルートを無視します。

修正： tailscale set --accept-routes=true を実行します。Docker の場合は、TS_EXTRA_ARGS に --accept-routes を追加します。Docker では tailscale down を使用しないでください。containerboot が停止します。代わりに tailscale set を使用してください。

ステップ4 — ポリシールーティングテーブルにルートがあることを確認する

ip route show table 52

合格： サブネット CIDR のルートが dev tailscale0 経由で表示されます。

失敗： テーブル52が空か、サブネットルートがありません。

重要： ip route（テーブルの指定なし）には、メインテーブルのみが表示されます。Tailscale はポリシールーティングテーブル52を使用するため、デフォルトの出力にはルートが表示されません。これは最もよくある誤検知です。

次も確認してください。

ip rule show

テーブル52とTailscaleのポリシールーティングの仕組みについて詳しくは、references/policy-routing.md を参照してください。

ステップ5 — サブネットルーターでIPフォワーディングが有効になっていることを確認する

cat /proc/sys/net/ipv4/ip_forward

合格： 1 が返されます。

失敗： 0 が返されます。カーネルが転送パケットを黙って破棄しています。

修正： sysctl -w net.ipv4.ip_forward=1 を実行します。Docker Compose では、sysctls: [net.ipv4.ip_forward=1] を設定します。Linux ホストで設定を永続化するには、/etc/sysctl.d/ に追加してください。

ステップ6 — サブネットルーターからターゲットへのネットワーク経路を確認する

サブネットルーターから次を実行します。

ping <target-ip>
ip addr show

合格： ルーターからターゲットに到達でき、アドバタイズされたサブネット上にインターフェースがあります。

失敗： ルーターからターゲットに到達できません。これはローカルネットワークの問題（ファイアウォール、VLAN、ルーティング）であり、Tailscale の問題ではありません。

ステップ7 — 戻り経路を確認する

ターゲットは、サブネットルーターを経由して応答を返す必要があります。ターゲットのデフォルトゲートウェイがサブネットルーターでない場合、戻りトラフィックは別の経路を通り、破棄されます。

修正： ターゲット（またはそのゲートウェイ）に、サブネットルーターの内部 IP を指す 100.64.0.0/10 の静的ルートを追加します。または、マスカレードを有効にします。

iptables -t nat -A POSTROUTING -o eth1 -j MASQUERADE

Tailscale 1.64+ では、デフォルトで --snat-subnet-routes が有効になり、この問題が自動的に処理されます。

エラー処理

失敗したチェックを黙ってスキップしないでください。具体的な失敗内容と修正方法を報告してから、続行してください。修正のために Tailscale の再起動やコンテナの再作成が必要な場合は、そのようにユーザーに指示し、ステップ 1 から再実行してください。

参考資料

• references/route-lifecycle.md — 広告から戻り経路までの、ルートライフサイクル全 7 段階
• references/policy-routing.md — テーブル 52、ip rule、VRF との類似点、および ip route で Tailscale のルートが見つからない理由
• references/common-failures.md — 症状から検索できる、根本原因と修正方法をまとめた表