要約

  • Cloudflare の公開例は重複部分を仮想ネットワークで区別した後も、広い本番経路を既定ネットワークに残し、staging 選択時の重複範囲外への本番到達性を説明している。
  • 新しい概覧が述べる既定表への回帰可能性には WAN 経路という限定がある。すべての Tunnel 経路の処理を一般化する根拠にはならない。
  • クライアントが取り込む通信、経路の参照先、許可条件は異なる管理対象であり、環境名だけでは三つを証明できない。

改番しない選択が残す仕事

企業統合で二つのネットワークが出会うとき、同じ数字が違う機器を指すことがある。本番と検証を別々に構築してきた組織でも同じことが起こり得る。RFC 1918 のプライベートアドレスは企業内、または利用を調整する企業間で意味を持つ。世界中で一つの宛先を特定する名前ではない。

そのため重複を見つけただけで、どちらかの計画が間違っていたとは言えない。必要なのは接続時に二つの意味を区別する方法である。Cloudflare のTunnel 仮想ネットワークの説明は、重複する範囲を別々の文脈に結び付ける方法を示す。利用者は Cloudflare One Client から仮想ネットワークを選択できる。

これは改番を唯一の前提にしないための機能である。ただし本稿は費用や移行時間の削減を測定していない。アドレスを残せる代わりに、どの文脈がどの環境を表すか、クライアントの選択を誰が管理するか、残る経路を誰が承認するかという仕事が必要になる。手間がなくなるというより、手間の所在が変わる。

本番経路は全部移されたわけではない

Cloudflare の重複アドレスを扱う学習ページでは、最初に本番の 10.0.0.0/8 を Tunnel A、検証の 10.0.1.0/24 を Tunnel B に接続する。いずれも既定の仮想ネットワークに置かれる。範囲が重なる部分では、より具体的な経路が検証を指すため、同じアドレスの本番側を選び分けられない。

次の手順で production と staging の文脈を設け、重複する 10.0.1.0/24 をそれぞれに関連付ける。本番側にはその具体的な経路を追加する。一方、広い 10.0.0.0/8 の本番経路は既定ネットワークに残る。

ページの文章はこの残り方まで説明している。staging を選んだ利用者は、重複部分では検証に到達するが、広い本番範囲のそれ以外のアドレスには接続できるとされる。例の目的は同じアドレスの行き先を区別することであり、検証を選ぶと本番全体から切り離されるという説明ではない。

環境名だけを受入条件にすると、この広い経路が議論から落ちる。担当者が重複部分の二つの機器を正しく開けたとしても、範囲外の本番宛先を禁止した証拠にはならない。何を区別できるかと、何を許さないかは違う質問だからだ。

これは文書上の例の読み取りである。実際の顧客接続、情報流出、権限違反、停止を観測したものではない。例が残す到達範囲を指摘することと、製品で隔離障害が起きたと断定することを混同してはならない。

WAN の限定を外して読まない

学習ページの更新日は2026年4月23日である。8月25日更新の仮想ネットワーク概覧は、それぞれが独立した経路表を持ち、一つの表の経路は他の表には現れないと説明する。選択した表に一致する項目がない場合に既定表を利用する可能性の説明には、WAN 経路という範囲が付いている。

同じ概覧では、IPsec、GRE、CNI による WAN 接続は既定の仮想ネットワークだけを使えるとしている。したがって、この説明をすべての不一致 Tunnel 経路が任意の既定 Tunnel に必ず戻るという規則へ拡大してはいけない。

別々の表を持つことは、経路記録の分離を説明する。特定の宛先にどの経路で到達するかは、接続方式や残された範囲の説明を必要とする。二つの更新日の違いも、単独で仕様変更を証明しない。本稿は異なる範囲の記述をつなぎ合わせて、未記載の万能な転送手順を作らない。

調達側に必要なのは、自社で購入する接続方式に適用される説明である。既定表に何が残るのか、それを選択後に利用する条件は何か、利用してはいけない宛先をどの仕組みで拒否するのか。文書の範囲差はこの確認を促す材料であり、外部から一つの動作を断定する材料ではない。

クライアントの入口と許可の出口

経路より先に、通信がその仕組みに入る必要がある。プライベート CIDR の接続ガイドによれば、Cloudflare One Client は既定で RFC 1918 の範囲を除外する。対象通信を取り込むには Split Tunnels の範囲を調整する。同ガイドは範囲を広げすぎると端末のローカル資源への接続に影響し得るとも注意する。

端末が取り込まない通信には、仮想ネットワークを増やしても役に立たない。逆に取り込み範囲を広げることは、追加したすべての宛先を承認することではない。入口の設定を経路設定やアクセス許可の代用にすると、受入試験の成功が何を示したのか分からなくなる。

ガイドは、登録済み端末が既定では Tunnel 配下のプライベートネットワークへ接続できると説明し、Gateway の全体的な拒否ルールに、優先度の高いアプリケーションまたは IP の許可ルールを組み合わせるよう勧める。これはインターネット上の誰でも入れるという意味ではない。ネットワークで到達できても、アプリケーションの認証が通るとは限らない。

ネットワークポリシーの説明では、動作と論理条件を組み合わせる。Cloudflare One Client で特定の仮想ネットワークを利用する通信を条件として扱える。文脈を許可判断の材料にはできるが、staging という文字列を付けた時点で他の環境への拒否が完成するわけではない。

契約で求めるべき説明可能性

よい受入条件は、同じアドレスの二つの端点が開けることだけではない。利用者と端末の条件、取り込む通信、選んだ文脈、既定表に残る範囲、許可と拒否をそれぞれ結び付けて説明できることだ。

共有サービスを残すことが業務上正しい場合もある。問題は残すこと自体でなく、それが環境分離の説明から隠れてしまうことである。反対に本番への接続を禁止するなら、名称ではなく拒否条件を受入対象にする必要がある。改番を避ける機能を評価しながら、許可境界については別の証拠を要求する。この二つを同時に求めても矛盾はない。

Cloudflare の公開例は、環境の選び分けを具体化する。それを全面的な宛先禁止の約束として売買してしまうのは、例が示す能力を越えた解釈である。購入対象を正確に言葉にすることが、導入後の責任分担を正確にする第一歩となる。

出典