一方の Tailscale ホストは応答するのに、もう一方は沈黙したまま。あるいは、すべてが動いていたのに、公開サイトが突然まったく違う国を報告し始める。どちらの相談も「Tailscale が壊れた」という形で届きますが、たいていは目的に対して誤った構成を有効にしているだけです。サブネットルーターはプライベートネットワークを tailnet に公開し、出口ノードはインターネット通信がどこから出るかを変えます。まず失敗した宛先を整理し、その宛先を覆う役割を選んでください。

失敗した宛先から始める

動かなかったアドレスや名前と、それが何なのかを書き出します。別拠点の先にあるプライベート LAN の機器、自分のセグメント上のサービス、公開サイトは、たまたま同じクライアントを共有しているだけの三つのルーティング問題です。区別は見た目の話ではありません。二つの構成は覆う宛先の集合が違うからです。片方を有効にしてももう片方には何の効果もなく、混乱の源はそこにあります。

アドレスファミリーにも注目してください。IPv4 としてしか広告されていないサブネットは、IPv6 の宛先をローカル経路に残します。両方のルーティングテーブルを誰かが比べるまで、これは部分的な障害に見えます。経路がどうなると思っていたかを記録しておけば、後のテストに反証する材料ができます。

Tailscale を一切動かさない機器に届かせる

ルーターは特定の範囲を tailnet に広告し、その後 tailnet とプライベートセグメントの間でパケットを中継します。そのため、そのセグメント上の機器に専用クライアントは不要です。自宅のノート PC からオフィスの NAS に届かせるのがまさにこのケースです。その側で tailnet のメンバーはルーターだけです。

tailscale up --advertise-routes=10.40.0.0/24 --advertise-exit-node=false
ip route get 10.40.0.55
tailscale status

広告は三つの条件のうち最初の一つにすぎません。経路は tailnet に承認され、 クライアントが広告された経路を受け入れ、アクセスルールが接続を許可している必要があります。この連鎖があるため、症状はたいてい「ルーターは動いているのに NAS に届かない」という形になります。到達できるルーターはトンネルが動いていることの証明ですが、承認・クライアントの受け入れ・ポリシーについては何も証明しません。

この三つの失敗は管理コンソールではそれぞれ違って見えます。三つを一度に変えず、順番に確認してください。二つ目の変更は、どれが効いたのかを隠してしまいます。

公開トラフィックを別のマシンから出す

出口ノードは通常のインターネット通信を自分経由で流します。これは他の VPN 製品の全文トンネル構成に最も近いものです。ここでも三つの同意が別々に必要です。機器が役割を広告し、管理者がそれを許可し、クライアントがそれを選びます。tailnet に参加しただけでは、既定では他のメンバー経由で何も流れません。

tailscale up --advertise-exit-node
tailscale up --exit-node=100.101.102.103 --exit-node-allow-lan-access=false
tailscale status --json | grep -i exitnode

出口ノードを選んでも、そのノード自身の LAN へのアクセスが自動で得られるわけではありません。LAN アクセスのオプションが存在するのは、これが別の権限だからです。切ったままにするのが安全な既定値です。他の Tailscale リソースへの経路は、出口ノードが有効な間も独自の扱いを保ちます。だからこそ、公開インターネットの経路が変わっても、サブネット上のサービスは動き続けられます。

出口ノードは、速く感じるかどうかだけでなく、インターネットからどう見えるかも変えます。位置情報、ストリーミングのカタログ、レート制限は、あなたのアドレスではなく出口のアドレスに従うと考えてください。

一つのホストだけが失敗したときは三方向の切り分けを読む

自分のセグメントのプリンター、遠隔のサブネットルーターの先の NAS、公開サイトは、三つの異なる経路を持つ三つの宛先です。そのうちちょうど一つだけが失敗するなら、不具合はその宛先の経路に属し、クライアント全体の問題ではありません。 出口ノードを使っている間のローカルプリンターについては、LAN アクセスの設定がいつもの答えです。遠隔の NAS については、広告された範囲、その承認状態、アクセスルールの順に確認します。公開サイトについては、どの出口ノードが選ばれているか、クライアントが実際にそれを受け入れたかを確認します。

アドレスは動くのに名前が動かないなら、経路を見るのはやめてください。プライベート DNS は別に設定され、誤ったアドレスに解決する名前は、ブロックされた経路とそっくり同じ形で失敗します。まずアドレス、次に名前を試せば、どちらの層を開くべきかが分かります。

自分が作ったと思う経路を確認する

検証は経路の照会とアドレスの確認であり、ping ではありません。照会は宛先がどのインターフェースを使うかを示し、アドレスの確認は宛先が実際どの範囲にいるかを示します。成功した ping はホストがどこかで生きているというだけで、それは問いの答えではありません。設定を変える前に両方を実行してください。

ip route get 10.40.0.55
ip -6 route show default
tailscale ping 10.40.0.55

それを tailnet 自身の表示と組み合わせます。ピアが直接つながっているのか中継されているのかが分かります。中継経路でも動きますし、それが、あなたが調べていた経路とは無関係な遅延の不満を説明します。 サブネットルーターのドキュメント には、なじみがなければ承認の手順が書かれています。そのうえで、自分のネットワークでどの構成がどの宛先を覆うのかを書き留めてください。次に拠点を追加する人も同じ質問をするからです。

関連記事