ZeroTier 上の HTTP は暗号化される？オーバーレイが終わる場所を確認

これらの確認は順番に行い、最初に失敗した時点で止めてください。本当の問いは狭いものです。ZeroTier ネットワーク上の平文 HTTP はインターネットをそのまま流れるのでしょうか。二つの ZeroTier ピアの間では通常そうではありません。オーバーレイがその区間を暗号化するからです。しかしそれは二つの端点についての話であり、リクエストが通過するすべての区間についてではありません。ルーター、ブリッジ、リバースプロキシは端点を動かし、その向こう側で平文が再開します。

確認 1: ブラウザが接続するアドレスを見つける

URL を、マシンが実際に持っているものと比較します。ip -brief addr show は zt インターフェースと、ネットワークコントローラーが割り当てたオーバーレイアドレスを一覧表示します。URL がそのアドレスを使っているなら、ブラウザのソケットはオーバーレイに入ります。

名前が代わりに LAN アドレスへ解決される場合、クライアントの状態表示が何を示していても、オーバーレイはまったく関与していない可能性があります。ip route get 10.147.20.5 はカーネルが選ぶインターフェースと送信元アドレスを出力するので、そこに zt インターフェースがあればパケットはオーバーレイに入り、物理 NIC の名前なら入らないということです。名前はもう一層加えます。オーバーレイアドレスを指すレコードは LAN アドレスを指すものとは異なる振る舞いをし、検索サフィックスや hosts ファイルのエントリが、どちらを得るかを静かに決めることがあります。

確認 2: 両端がピアであり、復号するリレーでないことを確かめる

ZeroTier はピア間を暗号化し、直接経路がない場合、パケットはルート経由で中継され、その際も暗号化されたまま転送されます。zerotier-cli peers は各ピアの経路を DIRECT または RELAY として、遅延値とともに示します。中継経路は往復のコストを払いますが、機密性は損ないません。

答えを変えるのは、本当の端点ではないメンバーです。相手側が物理 LAN へルーティングまたはブリッジする ZeroTier メンバーである場合、オーバーレイはそのメンバーで終わり、次のホップは通常の Ethernet です。

確認 3: リクエストが読めるようになる場所を見る

ページを提供していると思うホストで、再読み込み中にオーバーレイインターフェースをキャプチャします。sudo tcpdump -i ztxxxxxxx -A -c 5 'tcp port 80'。その出力に読めるリクエスト行があれば、トラフィックがそのホストに復号済みで届いた証拠であり、それが探している境界です。

次に、LAN の残りに面したインターフェースでキャプチャします。同じリクエストがそこに平文で現れるなら、アプリケーションに届く前にオーバーレイを離れており、そのセグメントのどの機器も読めます。LAN 側に何も現れずページが読み込まれるなら、アプリケーションは ZeroTier ホスト自身で終端しています。

リバースプロキシが前にいる場合は、HTTPS を受け付けて HTTP を転送するプロキシが境界を自分のバックエンドへ移すため、ループバックのキャプチャも重要です。

確認 4: ルーターやブリッジの後ろの各ホップを数える

オーバーレイと LAN の間をルーティングするよう設定されたメンバーはよくある設計であり、こうした前提の多くが崩れる場所です。オーバーレイが守るのはブラウザからルーターまでの区間で、その先は守りません。ブリッジは別の仕組みで同じ話をします。オーバーレイと物理セグメントが一つのブロードキャストドメインになるため、ブリッジされたノート PC からのリクエストは、その PC が ZeroTier ネットワーク上にあっても通常の Ethernet を通ります。

仮定せずに追跡します。クライアントからサービスアドレスへの traceroute と、ゲートウェイメンバーのルーティングテーブルを見れば、最後のホップが zt か eth かが分かります。

ZeroTier には、性能のために指定したローカル経路でトランスポートの安全性を落とせる信頼経路モードもあります。それを使うネットワークは通常の暗号化経路という前提を継承しないので、引用する前にネットワーク設定を読んでください。プロトコルのドキュメントは、ピア間の暗号化とその例外の両方を説明しています。

確認 5: アプリケーションがまだ何をすべきか決める

オーバーレイへの参加は、機器をネットワークに対して認証するものであり、相手側のサービスが到達したいものかどうかは何も語りません。HTTPS はホスト名を鍵に結び付けることで別の問いに答えます。したがって二つの保護は重なり合うものの、互いを置き換えません。認可されたピアでも誤ったサービスであり得ますし、侵害された端点は暗号化の前でも復号の後でもリクエストを読みます。どちらの仕組みも、アプリケーションが記録する内容を監査しません。

再利用可能なセッションやパスワードを持つものについては、アプリケーションまたは自分が管理するプロキシで TLS を終端し、証明書の検証を有効にしておきます。旧来のサービスを平文 HTTP のままにする必要がある場合は、許されるホスト間の経路、誰が到達できるか、どのセグメントが無防備のままかを正確に書き留めてください。そのメモが将来のレビュー担当者に必要なものです。

"VPN がつながっている" は、このどれについても評価ではありません。正直な版は、両方の端点、その間の経路、そして守られていない最初のホップを名指しします。

キャプチャ出力とピア一覧をサービスのドキュメントのそばに保管しておけば、経路を変えたりブリッジを追加したりする人が、どの前提を壊そうとしているか分かります。