目次
Tailscale と Clash が単独では正常で、同時に有効にした場合だけ切断されるときに初めて、本当の競合と判断できる
Tailscale だけを有効にした状態では tailnet のデバイスへアクセスでき、Clash TUN だけを有効にした状態では普段の振り分けを行える必要があります。それぞれ単独では正常で、併用時だけ失敗する場合に、ルート、DNS、デフォルト出口の競合を調べます。どちらか一方が単独でも失敗するなら、先にそのツール自体の設定を修正してください。
三つの状態を個別に記録します。Tailscale だけ、Clash だけ、両方を有効にした状態で、それぞれ一つの tailnet IP、一つの tailnet デバイス名、一つのローカルネットワークアドレス、一つの公開アドレスをテストします。IP とデバイス名で結果が異なれば、ルーティングと MagicDNS の問題をすでに切り分けられます。
三組の比較から分かること
| 結果 | 可能性の高い問題 |
|---|---|
| 100.x アドレスにもデバイス名にも到達できない | Tailscale サブネットが TUN またはデフォルトルートに取り込まれている |
| 100.x アドレスには到達できるが、デバイス名では到達できない | MagicDNS または Clash DNS の取り込み順 |
| tailnet は正常だが、公開インターネットが切断される | 二つのツールがデフォルト出口または exit node を奪い合っている |
| 特定のローカルサブネットだけに到達できない | Tailscale のサブネットルートとローカルサブネットが重複している |
ルーティングテーブルを見れば、対象サブネットを奪ったネットワークアダプターが分かる
Tailscale はデバイスへ 100.64.0.0/10 の範囲からアドレスを割り当て、管理者が承認したサブネットルートを受け取る場合もあります。exit node を選ぶとデフォルトルートも追加されます。Clash TUN もルートを書き込むため、二つのスイッチだけを見ても競合は診断できません。
障害が発生している状態で route print、ip route、netstat -rn の結果を保存し、単独で動作させた状態と比較します。100.64.0.0/10、実際に公開されたサブネット、家庭内 LAN、デフォルトルートがそれぞれどのインターフェースを指しているか、同じプレフィックスで metric の異なる二つの項目がないかを重点的に確認してください。
# Windows
route print
# Linux
ip route
ip rule
# macOS
netstat -rnデフォルトのインターネット出口は一つのツールだけに任せる
Tailscale exit node と Clash TUN はどちらもデフォルトのインターネット通信へ影響します。目的が Tailscale 経由で自宅の NAS へアクセスし、公開通信の振り分けを Clash に任せることだけなら、このデバイスで Tailscale exit node を選ばないでください。
Tailscale には tailnet と公開済みサブネットだけを任せます。
反対に、会社の方針で公開通信をすべて指定の Tailscale exit node へ通す必要がある場合は、Clash の対象を明示したアプリまたはプロキシポートだけに絞り、この併用が組織の方針に沿っていることを確認してください。二つのツールがどちらもデフォルト出口を宣言している状態で時々接続できても、単にその時点のルート metric が一方に有利なだけで、安定した設定ではありません。
tailnet と実際のサブネットは Tailscale に任せる
Clash Verge Rev など、TUN から任意のサブネットを除外できるクライアントでは、100.64.0.0/10、実際に使う家庭内 LAN、Tailscale の管理コンソールで承認した advertised routes を除外範囲へ追加できます。
他人のプライベートサブネットをすべてコピーしないでください。除外範囲が広すぎると、本来 Clash で処理すべき接続まで直接外へ出てしまいます。
Mihomo のルールでこれらのサブネットを明示的に DIRECT にすることもできますが、ルーティング層の除外とルール層の DIRECT は完全に同じではありません。ルールが判断するには、接続が先にコアへ入る必要があります。100.x のリクエストが Clash の接続記録に現れない場合はシステムルートを直接確認し、記録に現れてプロキシへ一致する場合はルールを調整してください。
自分のネットワークに合わせて入力する
- 100.64.0.0/10 の tailnet アドレス範囲
- 自宅またはオフィスで実際に使う LAN サブネット
- Tailscale コンソールで承認済みのサブネットルート
- Docker、WSL、仮想マシンで実際に tailnet と重複するサブネット
IP では到達できるのにデバイス名で失敗する場合は、ルーティングではなく MagicDNS を修正する
100.x アドレスへ直接アクセスできれば、tailnet へのルートは概ね存在しています。それでもデバイス名の名前解決に失敗する場合、Clash DNS、ブラウザの DoH、システム resolver のいずれかが tailnet の名前を Tailscale の DNS 設定へ渡していない可能性があります。
まず tailscale status でデバイスのアドレスを取得し、nslookup または OS の名前解決ツールで短い名前と完全な tailnet 名を比較します。トラブルシューティング中はブラウザ独自の DoH を無効にし、Clash の nameserver-policy またはローカルドメイン除外を確認してください。tailnet 名を公開 DNS へ転送しないでください。
WSL、Docker、遠隔地の LAN が偶然同じサブネットを使っている場合がある
Tailscale のサブネットルートが 192.168.1.0/24 を公開し、現在いるカフェや自宅も 192.168.1.0/24 を使用している場合、システムはアドレスだけではどちらへアクセスするか判断できません。Docker と WSL2 も独自のプライベートサブネットを追加するため、競合がコンテナやサブシステム内だけで発生する場合があります。
サブネットが重複した場合は、自分で制御できる LAN、Docker、仮想マシンのアドレス設計を優先して変更します。同じプレフィックスを高優先度のルートで長期的に奪い合う構成では、ネットワークの切り替え、スリープ復帰、アップグレードの後に再び失敗します。
スリープ復帰時や Wi-Fi の切り替え後だけ失敗するなら、多くはルートの書き換え順が変わっている
ノートパソコンのスリープ復帰、有線から Wi-Fi への切り替え、スマートフォンのテザリングへの接続時には、二つのクライアントがデフォルトインターフェースを再検出してルートを書き込みます。再接続が完了するまで待ってからルーティングテーブルを比較してください。決まった順序で一方を再起動すると復旧するなら、起動順に問題がある証拠です。
両方のクライアントを更新しても繰り返し発生する場合は、自動起動時の競合を減らします。システムのネットワークが準備できてから必要なトンネルを起動し、Tailscale exit node を同時に自動選択しないでください。障害と無関係な設定まで消去されるため、毎回ネットワーク全体をリセットしないでください。
修正完了とするには、二つの用途がどちらも機能することを証明する
同じテスト周期で検証する
tailnet IP へアクセス
100.x のルートが引き続き Tailscale に割り当てられていることを証明します。
tailnet 名へアクセス
MagicDNS または専用の名前解決が引き続き機能することを証明します。
公開済みサブネットへアクセス
承認済みの subnet route が Clash に取り込まれていないことを確認します。
公開インターネットへアクセスして Clash の記録を確認
通常の振り分けが引き続き想定したポリシーで処理されることを証明します。
四項目のうち失敗した項目に対応するルート、DNS、サブネット、デフォルト出口だけを調整します。Tailscale の担当と Clash の担当を同時に説明できて初めて、偶然の metric 順序に依存しない設定になったといえます。