Linux の Tailscale クライアントがアドバタイズされたサブネットルートを無視する理由

手がかりはテーブル 52 です。Linux の Tailscale クライアントは --accept-routes を指定した後に初めてアドバタイズされたサブネットルートをインストールし、デバイスの承認は別のゲートです。

あなたは Linux ノート PC を使っていて、tailscale status は他のマシンを一覧表示しているのに、10.80.0.25 の NAS は依然としてタイムアウトします。tailnet は健全で、サブネットルーターはオンラインで、クライアントの出力には背後の LAN に到達できない理由が何も書かれていません。以下の手順はその症状から外側へ進みます。まずこのクライアントのフラグ、次にルーターのアドバタイズ、次に承認、次にポリシー、そして最後に宛先そのものです。どのゲートも同じタイムアウトで失敗するので、コマンドより順序のほうが重要です。

Linux クライアントがインストールを拒むもの

Linux の Tailscale クライアントは、指示しない限りアドバタイズされたサブネットルートを受け入れません。この設定がないと、クライアントは tailnet に参加してピアのアドレスには到達しますが、ルーターがアドバタイズするプレフィックスはすべて未使用のままです。既定値は意図的なもので、症状がローカルの判断ではなく壊れたルーターのように見えるのはそのためです。

ここでは別々の二つがルーティングと呼ばれ、あなたのものはそのうち一つだけです。ルーターはプレフィックスを tailnet にアドバタイズし、あなたのマシンがそれをインストールするか決めます。どちらが失敗しても同じタイムアウトになるので、当て推量は半日を無駄にします。何かを編集する前に、どちら側が拒否しているのかを突き止めてください。

このマシンでルート受け入れを有効にする

クライアントで設定を有効にし、コマンドが効いたと決めつけずに何が変わったかを見ます。現在の形式はログインの流れを繰り返さずに設定を適用するので、セッションの途中ではそれが重要です。

sudo tailscale set --accept-routes
tailscale status
ip route show table 52

Tailscale は受け入れたルートを Linux の独自テーブルにインストールするので、テーブル 52 にプレフィックスが現れることは、このクライアントがアドバタイズをインストールした直接の証拠です。そのテーブルに自分の範囲がなければ、そこで止めてください。問題はローカルにあり、ルーター側で何をしても変わりません。

古いクライアントは同じ設定をログインコマンドのフラグとして公開しているので、tailscale set がない場合の代替は sudo tailscale up --accept-routes です。ルートを手で編集するのではなくこれを使ってください。デーモンが独自のテーブルを書き換えるため、次の再接続で編集は消えます。古い記事からコマンドをコピーする前にバージョンを確認してください。

アドバタイズと承認を別々に確認する

サブネットルーターではプレフィックスをアドバタイズする必要があり、カーネルはインターフェース間でパケットを転送する必要があります。転送なしのアドバタイズは、トラフィックを静かに落とす承認済みルートを与えます。これが最もよくある中途半端な構成です。

sudo tailscale up --advertise-routes=10.80.0.0/24
sysctl net.ipv4.ip_forward
ip -br addr

アドバタイズされたプレフィックスを、実際に到達しようとしているアドレスと一文字ずつ比較します。10.70.0.0/24 をアドバタイズするルーターは 10.80.0.25 の NAS について何も言っておらず、両方の数字が同じくらいもっともらしく見えるため、この不一致はどのステータス出力にも現れません。壊れたルートの報告の多くはここで終わります。下流に触れる前にアドバタイズを直してください。

承認が次のゲートで、ルーターをシェルから設定した場合は飛ばしがちです。他のマシンが使う前に、管理コンソールでそのデバイスのアドバタイズを有効にする必要があります。クライアントでルートを受け入れても何も承認されず、どのアクセスルールも上書きされません。

ホスト名より先にプライベートアドレスを試す

ルーター自身の tailnet アドレスへの接続成功は tailnet が機能している証拠ですが、それは既に分かっていたことです。有用なテストは本当に必要なサービスを、まずプライベートアドレスに対して行うことです。そうすれば DNS の失敗がルーティングの失敗に見えることはありません。

tailscale ping 10.80.0.1
ping -c 2 10.80.0.25
nc -vz 10.80.0.25 445
getent hosts nas.internal.example

アドレスが応答してホスト名が応答しないなら、名前解決の問題であり、ルートの問題として扱うのをやめるべきです。どちらも応答しないなら、一つ前の節に戻ってアドバタイズがアドレスを網羅しているか確認してください。二つの失敗はアプリからは同じに見え、直す場所は異なります。

tailnet を責める前に、ローカルの確認を一つしておく価値があります。現在の LAN がリモートのサブネットと同じプレフィックスを使っていると、カーネルは直接接続されたルートを優先し、トラフィックはマシンから出ません。家庭とオフィスがどちらも 192.168.1.0/24 を選んだときに起きることです。

クライアントのフラグがルーターの設定ではない理由

これは異なる要件を持つ異なる役割であり、クライアントのフラグをルーターにコピーするのは、動いている tailnet がループを得る方法です。ルートをアドバタイズするマシンには転送、転送されたトラフィックを許可するファイアウォール規則、どのプレフィックスをアドバタイズするかの判断が必要です。そのどれも --accept-routes から含意されません。

サブネットルーターのドキュメントは、一つのプレフィックスをアドバタイズする冗長ルーターでルート受け入れを有効にしないよう警告しています。待機ノードが既にローカルなトラフィックをアクティブノード経由で外へ押し出せるからです。HA ペアを運用するなら、それを脚注ではなく設計上の制約として扱い、両方で承認する前にどちらのノードがプレフィックスを所有するか決めてください。単一ルーターでは同じ警告は、受け入れはクライアント側のものでありアドバタイズするマシンのものではないという注意として読めます。どのゲートが閉じていたかを書き留めてください。

通常のクライアントでは手順は最初に失敗したアプリのテストで終わります。ルーターでは転送、アドバタイズ、承認、ファイアウォールをこの順に確認してください。最初に欠けているものが、あなたが始めたのと同じタイムアウトを生み出すからです。

関連記事