ZeroTier から LAN へ：ポート許可ではなく UFW のルート規則

ZeroTier のメンバー経由でオフィスの LAN にあるプリンターに届くのは、一つの規則のように聞こえますが、実際には三つの異なる場所での三つの判断です。オーバーレイは LAN がどこにあるかを知る必要があり、Linux ホストはパケットを転送する用意がなければならず、LAN は応答をどう返すかを知る必要があります。ゲートウェイでポートを開くインバウンド規則は、そのどれにも触れていません。正しいホストに当てた間違った道具です。

三つの仕事、三人の担当者

管理ルートは ZeroTier のネットワーク設定に属します。あるプレフィックスが特定のメンバーアドレス経由で到達可能であることを、メンバーに伝えます。

転送は Linux カーネルと、そのファイアウォールポリシーを持つものに属します。オーバーレイに届いたパケットが物理インターフェースから再び出て行くかどうかを決めます。転送しないホストは、パケットを受け入れたあとに黙って破棄します。送信側にはタイムアウトが見え、サービスのログには何も現れません。

戻り経路は LAN に属します。そのホストとルーターは、オーバーレイのプレフィックスがゲートウェイの LAN アドレス経由で到達可能であることを知っている必要があり、そうでなければ何かが通信を変換して、この問い自体が起きないようにする必要があります。

これらのどれかが正しくても他が失敗することがあるので、ゲートウェイに ping するだけの試験は、その先のサービスについて何も証明しません。

管理ルートをメンバーに向けます

目的の LAN プレフィックスへのルートは、ゲートウェイの LAN アドレスではなくオーバーレイアドレス経由で追加します。オーバーレイアドレスは他のメンバーが到達できるもので、LAN アドレスはケーブル上でのみ意味を持ちます。

この設計が機能するには、メンバーが管理ルートを受け入れる必要があり、各自のローカルネットワークが告知するプレフィックスをすでに使っていてはいけません。自宅で 192.168.60.0/24 上にある遠隔のノート PC も、192.168.60.0/24 をオーバーレイ経由でルーティングすることはできません。

告知するプレフィックスは、作業が許す範囲で狭く保ちます。優先度に影響させるために大きな集約を告知すると、所有していないアドレス空間を主張することにもなり、生じた競合は両方のネットワークにつながる機器に現れます。メンバーがどこにも通じない経路を優先してしまうこともあります。ルートは正直に保ち、残りはポリシーに任せます。

プレフィックスとメンバーアドレスは、ファイアウォール規則と同じメモに書きます。最も多い不具合は、間違ったメンバーを指すルートだからです。

カーネルで転送を有効にします

何かを変える前に現在の転送値を読み、そのうえで設定は、再起動で消える一時的なコマンドではなく、システムがすでに使っている仕組みで永続化します。

ポリシーを UFW が持っている場合、そのルート規則は送信元・宛先・インターフェースの組に対する転送を表します。これはゲートウェイ自体でサービスを開くインバウンド規則とは別ものです。

sysctl net.ipv4.ip_forward
sudo ufw route allow in on zt3f2a1c9d out on eth0 proto tcp to 192.168.60.20 port 443
sudo ufw status verbose

インターフェース名はそのホスト上の実際のオーバーレイデバイスで、ip link から読めます。インストールごとに固定の文字列ではありません。ホストが既定で転送していて UFW が経路上にない場合、ルート規則は無視され、カーネルの設定が重要になります。

応答がどう戻るかを選びます

送信元を保持する場合、LAN のサービスは本当のオーバーレイアドレスを見て、そこへ応答します。そのためには LAN ホストかそのルーターに、オーバーレイのプレフィックスをゲートウェイへ向けるルートが必要で、これは Linux の外側の変更です。

そのルートを追加できない場合、範囲を絞った送信元変換によって、要求は LAN 上のゲートウェイから来たように見えます。すると応答はローカルに戻り、LAN のルーティング変更は不要になりますが、サービスのログから元の送信元が失われます。

変換はオーバーレイの送信元と特定の LAN 宛先に限定します。LAN インターフェースから出るものすべてを変換するのは広い版で、あとから規則を読む人を驚かせ、本来ブロックされるべき通信も隠してしまいます。

どちらの選択も、LAN から任意のオーバーレイメンバーへの求められていないアクセスを与えるものではありません。それが望ましいなら、独自のレビューを伴う別の規則です。

実際のメンバーから試験します

ゲートウェイからではなく、別のメンバーから接続し、許可されたサービスを一つ要求します。次に、閉じたままであるべきサービスを試し、再接続のあととゲートウェイの再起動のあとに両方の試験を繰り返します。

ONLINE を報告するメンバーや、ゲートウェイのオーバーレイアドレスへの ping の成功は、ルート、転送規則、戻り経路のどれも検証しません。

zerotier-cli listnetworks
ip -4 route get 192.168.60.20
sudo ufw status numbered

二つ目のコマンドは、LAN ホスト宛てにパケットがどのインターフェースを使うかを示し、三つ目はルート規則が意図した形で存在するかどうかを示します。どちらも正しく見えるのにサービスがまだタイムアウトするなら、残る容疑者は戻り経路です。