ZeroTierで承認済みなのにアドレスがない？ 別々の二つの設定

ZeroTier はメンバーを OK と表示し、ネットワークにも参加しているのに、ping を送る先のアドレスがありません。この組み合わせは不具合のように感じられますが、実際には設定が二つに分かれているのが原因です。メンバーの承認は一つのスイッチで、アドレスの割り当てはもう一つのスイッチです。プールや割り当てモードが設定されていなければ、ネットワークは端末を受け入れても何も割り当てません。

どちらかを変更する前に、両側を確認してください。答えは二か所に現れ、そのうち制御側にあるのは一つだけです。

承認と割り当ては別のスイッチ

承認は、このノードがネットワークに参加してよいかを決めます。アドレスの割り当ては、参加した後にネットワークが何を渡すかを決め、その答えはアドレスプールと割り当てモードから決まります。どちらの設定も他方を意味しません。一方は許可であり、もう一方は配分です。

コントローラの設定には通常、管理ルート、アドレス範囲、自動割り当てを使うかどうかを決めるモードが含まれます。別の環境からネットワークIDをコピーしても、メンバーシップは引き継げても、その設定は何も付いてきません。

だからこそ、メンバー一覧では正常に見えるのに、割り当てアドレスの列が空のままになります。コントローラは受け入れたものの、渡すものがありません。両方の記述が同時に正しいのです。

メンバーの実際の状態を読む

コントローラの意図ではなく、クライアントが実際に受け取ったものを尋ねてください。通常の一覧は状態とアドレスの列を表示し、JSON 形式はクライアントが適用したネットワーク設定を、管理アドレスやルートも含めて表示します。

zerotier-cli listnetworks
zerotier-cli -j listnetworks | jq '.networks[] | {nwid, status, assignedAddresses}'

同じネットワークIDについて二つの出力を比較してください。オペレーティングシステム自身の一覧に現れる物理アダプタではありません。空のアドレス集合で OK と報告する行は、接続の障害ではなく割り当ての欠落を裏づけます。誤った行を読むことが、この誤りの残り半分です。

ACCESS_DENIED という状態は承認を指し示します。そしてそれは別の修理です。コマンドがローカルの認証トークンをまったく読めない場合、問題はコントローラによる拒否ではなくローカルの権限であり、修正は今座っている機械の側です。

クライアントがコントローラの送信を無視するとき

クライアントには、管理設定を適用するかどうかを決める独自の設定があります。管理アドレス、管理ルート、既定ルートの処理を無効にするプロファイルは、ネットワークが送るものを捨ててしまい、コントローラ側から見たメンバー一覧は正しいままに見えます。

これらのフラグはローカルのノードだけに影響します。変更しても他のメンバーが受け取るものは変わらず、定義されていないプールが直ることもありません。

したがって診断は二つの枝に分かれます。コントローラに渡すアドレスがないか、クライアントが渡されたアドレスを拒否したかです。どちらも別の機械での別の修理につながります。JSON 出力は両者を区別します。アドレスがネットワーク設定に存在しないか、存在するのにクライアントの適用状態に欠けているかのどちらかだからです。

アドレスを作り出す代わりに直すもの

任意の固定アドレスを打ち込むのは誘惑的な第三の選択肢であり、最悪の選択です。乱暴なアドレスは他のノードと衝突したり、ネットワークが広告するルートの外にあったり、ファイアウォール規則が別扱いする範囲に入ったりします。さらに、次にネットワークを見る人から欠けているプールを隠してしまいます。代わりに割り当てを直し、コントローラとクライアントに同じ結果を合意させてください。

管理者にネットワークが何を配るべきかを尋ね、プールが意図した範囲を覆っているか、割り当てモードが有効かを確認します。変更後に再参加し、クライアントがすぐ自力で新しい設定に追いつくことを期待しないでください。

アドレスが現れたら、本当に必要だったものを試します。ピア、サービス、あるいはゲートウェイの向こうのサブネットです。メンバーの先の LAN に届くにはメンバーシップ以上のルーティングと転送が必要で、一般的なインターネット接続には出口ノードが必要です。つまり、動くアドレスはその試験の終わりではなく始まりです。