ルート

デフォルトでは、Mesh ノードには自身の Mesh IP だけで到達できます。ノード背後のサブネット上のほかのデバイス（Cloudflare One Client を実行できないサーバー、データベース、プリンター、IoT デバイス）に到達できるようにするには、ノードにルートを追加します。Mesh ノードは次の 2 種類のルートに対応します。

• CIDR ルート — IP 範囲（プライベート（例: 10.0.0.0/24）またはパブリック）のトラフィックをノード経由で転送します。
• ホスト名ルート — IP ではなくホスト名のトラフィックをノードへ引きます。プライベート ホスト名（例: wiki.internal.local）で使えます。アプリケーションの IP が不明または一時的なときに便利です。パブリック ホスト名（例: www.example.com）では、そのホスト名のトラフィックをノード経由でルーティングし、ノードのパブリック IP からエグレスします。

ルートを追加すると、Mesh ノードはゲートウェイとして動作します。広報した CIDR またはホスト名宛てのトラフィックはノードへ転送され、ノードはローカルネットワーク上の適切なホストへ届けます（または公衆インターネットへエグレスします）。

IPv4 と IPv6 の CIDR ルートの両方に対応します。IPv6 ルートには、Mesh ノードの デバイスプロファイル が MASQUE を使う設定である必要があります。デバイスプロファイルが WireGuard を使う場合は動作しません。

• ルートなし — Mesh 上のデバイスは、Mesh IP でノード自身にだけ到達できます。ノード上で直接動くサービスには、この方法で到達できます。
• ルートあり — Mesh 上のデバイスは、ノード背後のサブネット上の任意のホストに到達できます。Cloudflare One Client を実行できないインフラがあるときに使います。

flowchart LR
  subgraph subnet["サブネット 10.0.0.0/24"]
    node["Mesh ノード <br> 10.0.0.1"]
    db["データベース <br> 10.0.0.50"]
    printer["プリンター <br> 10.0.0.100"]
  end
  client["クライアントデバイス <br> 100.96.0.10"] --> CF((Cloudflare)) --> node
  node --> db
  node --> printer

CIDR ルートを使い、Mesh ノードからローカルネットワーク上のデバイスへトラフィックを転送します。

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"network": "10.0.0.0/24",
		"tunnel_id": "{mesh_node_id}",
		"comment": "Staging subnet"
	}'

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID" \
	--request PATCH \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"network": "10.0.0.0/24",
		"comment": "Updated description"
	}'

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/teamnet/routes/$ROUTE_ID" \
	--request DELETE \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

広報した CIDR にトラフィックが届くには、Mesh ノードとクライアントデバイスの両方で、その範囲が Cloudflare 経由でルーティングされる必要があります。

Mesh ノードのデバイスプロファイルで、広報した CIDR が Cloudflare 経由になるようにします。

• Include モード（Mesh ノードに推奨）: include リストに CIDR を追加します。
• Exclude モード: exclude リストから CIDR（またはその親範囲）を外します。

たとえば 10.0.0.0/24 を広報していて、Split Tunnels の exclude リストに 10.0.0.0/8 がある場合、10.0.0.0/8 を削除し、Cloudflare 経由にしたくない 10.0.0.0/8 の部分だけを再度追加します。

クライアントデバイスが使うデバイスプロファイルでも同じ Split Tunnel 設定を行い、広報した CIDR が Cloudflare 経由になるようにします。

Mesh ノードは、Cloudflare からの受信トラフィックをサブネット上のデバイスへ転送します。ただし 戻りトラフィック（サブネットデバイスから Mesh クライアントへの応答）では、サブネットデバイスに Mesh ノードへ戻るルートが必要です。

flowchart LR
  client["クライアントデバイス <br> 100.96.0.10"] -- リクエスト --> CF((Cloudflare)) -- リクエスト --> node["Mesh ノード <br> 10.0.0.1"]
  node --> db["データベース <br> 10.0.0.50"]
  db -. "応答: <br> ノードへのルートが必要" .-> node -. 応答 .-> CF -. 応答 .-> client

設定方法は、Mesh ノードのインストール場所によって変わります。

Mesh ノードがサブネットのデフォルトゲートウェイである（またはルーター上にインストールされている）場合、追加設定は不要です。サブネットデバイスからのすべてのトラフィックは、自然にノード経由になります。

Mesh ノードがサブネット上の通常ホストである場合、サブネットのルーターを設定し、Mesh トラフィックをノード経由で送ります。静的ルートを追加します。

• 宛先: 100.96.0.0/12（Mesh IP 範囲）
• ネクストホップ: Mesh ノードのローカルサブネット IP（例: 10.0.0.1）

これで、Mesh クライアントへの応答は Mesh ノードへ転送され、Cloudflare 経由で配信されます。

複数サイトに Mesh ノードがある場合、あるサブネット上のデバイスは、Cloudflare 経由でもう一方のサブネット上のデバイスに到達できます。

flowchart TD
  subgraph siteA["サイト A — 10.0.0.0/24"]
    serverA["サーバー <br> 10.0.0.50"] --- nodeA["Mesh ノード <br> 10.0.0.1"]
  end
  subgraph siteB["サイト B — 192.168.1.0/24"]
    serverB["サーバー <br> 192.168.1.50"] --- nodeB["Mesh ノード <br> 192.168.1.1"]
  end
  nodeA <--> CF((Cloudflare))
  nodeB <--> CF

これが動くには、次が必要です。

1. 各 Mesh ノードは、ローカルサブネットを CIDR ルート として広報し、Cloudflare がどのノードへ転送するかを知る必要があります。
2. 各ノードで、リモートサブネット CIDR が Cloudflare 経由でルーティングされる必要があります。Mesh ノードの Split Tunnel 設定で、リモートサイトの CIDR を include リストに追加します（または exclude リストから外します）。
3. 各サイトのルーターには、リモートサブネットをローカル Mesh ノードへ向ける静的ルートが必要です。

サイト A のルーター:

• 宛先: 192.168.1.0/24 → ネクストホップ: 10.0.0.1（ローカル Mesh ノード）
• 宛先: 100.96.0.0/12 → ネクストホップ: 10.0.0.1

サイト B のルーター:

• 宛先: 10.0.0.0/24 → ネクストホップ: 192.168.1.1（ローカル Mesh ノード）
• 宛先: 100.96.0.0/12 → ネクストホップ: 192.168.1.1

本番のサイト間導入では、各ノードで 高可用性 を有効にすることを検討します。HA は、ノードが広報する CIDR ルートにフェイルオーバーを提供します。アクティブなレプリカが落ちると、Cloudflare がスタンバイを昇格し、サブネットへのトラフィックは流れ続けます。

Cloudflare Gateway でサブネットからの DNS クエリをフィルタするには、次を行います。

1. ルーターの DNS を設定する: ルーターの DNS を Gateway リゾルバー IP に向けます。

   • 172.64.36.1
   • 172.64.36.2

2. ルーターに IP ルートを追加する: ルーターで、Gateway リゾルバー IP を Mesh ノードのローカル IP へ向ける静的ルートを追加します。これにより、DNS トラフィックがノード経由で Cloudflare に届きます。

   • 宛先: 172.64.36.1 → ネクストホップ: 10.0.0.1（ローカル Mesh ノード）
   • 宛先: 172.64.36.2 → ネクストホップ: 10.0.0.1

3. Split Tunnels を設定する: Split Tunnels 設定で、次の IP が Mesh ノード経由になるようにします。

   • サブネットの内部 DNS リゾルバー IP
   • Gateway の Initial resolved IP 範囲: 172.64.128.0/20（IPv4）と 2606:4700:0cf1:4000::/64（IPv6）

Gateway は、発信元デバイスのプライベート送信元 IP 付きで DNS クエリを記録します。これを使い、内部 DNS レコード向けの リゾルバーポリシー を作成できます。

IP 範囲を広報する代わりに、特定ホスト名のトラフィックを Mesh ノードへ引けます。ユーザーがそのホスト名を要求すると、Cloudflare Gateway が Initial resolved IP を割り当て、トラフィックをノード経由でルーティングします。

• プライベートホスト名（例: wiki.internal.local）— ノードは、ローカルネットワーク上のアプリケーションのプライベート IP へトラフィックを届けます。アプリケーションの IP が不明または一時的なときに便利です。
• パブリックホスト名（例: www.example.com）— ノードは自身のパブリック IP を使い、公衆インターネットへトラフィックをエグレスします。そのホスト名の専用エグレスとして Mesh ノードを使えます。

ホスト名ルートは、リソースへ到達する方法として 仮想ネットワーク を置き換えます。ホスト名はグローバルに一意であるため、重複するホスト名は使えません。ホスト名は、同時に 1 つのノードまたはトンネルにだけルーティングできます。

ホスト名ルーティングのパケットフローの詳細は、発表ブログ ↗ を参照してください。

• 対応する Mesh ノードバージョンを実行する。 ホスト名ルーティングには、Mesh ノードが Linux Cloudflare One Client バージョン 2026.6.822.0 以降である必要があります。

• Mesh ノードの デバイスプロファイル を MASQUE に設定する。 デバイスプロファイルが WireGuard を使う場合、ホスト名ルーティングは動きません。

• TCP、UDP、ICMP 付きで Gateway プロキシを有効にする。

  1. Traffic policies > Traffic settings を開きます。
  2. Proxy and inspection で、Allow Secure Web Gateway to proxy traffic をオンにします。
  3. TCP を選択します。
  4. UDP を選択します（内部 DNS リゾルバーへのトラフィックをプロキシするために必要です）。
  5. （推奨）ping や traceroute などの診断ツールのトラフィックをプロキシするには、ICMP を選択します。cloudflared 経由で ICMP トラフィックを許可するには、システムの更新 も必要な場合があります。

  1. cloudflare_api_token ↗ に次の権限を追加します。

     • Zero Trust Write

  2. cloudflare_zero_trust_device_settings ↗ リソースを使い、TCP または UDP のプロキシ（あるいは両方）をオンにします。

     resource "cloudflare_zero_trust_device_settings "global_warp_settings" {
     	account_id            = var.cloudflare_account_id
       gateway_proxy_enabled = true
     	gateway_udp_proxy_enabled = true
     }

  これで Cloudflare は、登録済みデバイスからのトラフィックをプロキシします。split tunnel の設定 で除外したトラフィックは対象外です。Gateway がトラフィックを転送する仕組みの詳細は、Gateway プロキシ を参照してください。

• Mesh ノードのデバイスプロファイルとクライアントデバイスプロファイルの両方の Split Tunnel 設定で、次の IPv4 範囲を Cloudflare 経由にする。 Include モードでは各範囲を追加します。Exclude モードでは、それら（または親範囲）が除外されていないことを確認します。

  用途	IPv4
  Mesh デバイス IP 範囲	100.96.0.0/12
  Cloudflare 送信元 IP 範囲	100.64.0.0/12

  ホスト名ルーティング（トークン IP）範囲（172.64.128.0/20）とすべての Cloudflare One IPv6 範囲は 自動で Cloudflare 経由になります。手動追加は不要です。

• クライアントデバイスの Local Domain Fallback から、ホスト名のトップレベルドメインを外す。 DNS クエリが Cloudflare Gateway へ送られ、解決されるようにします。

curl "https://api.cloudflare.com/client/v4/accounts/$ACCOUNT_ID/zerotrust/routes/hostname" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"hostname": "wiki.internal.local",
		"tunnel_id": "{mesh_node_id}",
		"comment": "Internal wiki"
	}'

プライベート ホスト名では、Gateway がそのホスト名をプライベート IP に解決できる必要があります。設定方法は、DNS 解決とアプリケーショントラフィックが 同じ コネクタを使うか、別の コネクタを使うかで変わります。

デフォルトでは、Mesh ノードはホストマシンで設定された DNS リゾルバー（Linux では /etc/resolv.conf など）でホスト名を解決します。cloudflared と同じ方法です。そのリゾルバー経由でノードがすでにホスト名をプライベート IP に解決できる場合、追加設定は不要です。

ノードが単独でホスト名を解決できない場合、最も簡単な方法は、ノードの hosts ファイル（Linux では /etc/hosts など）に、ホスト名とプライベート IP の対応を追加することです。Cloudflare Tunnel とは異なり、Mesh ノードでは専用 DNS サーバーの実行は 不要 です。

10.0.0.50 wiki.internal.local

Gateway の リゾルバーポリシー が必要なのは、DNS クエリをアプリケーショントラフィックと 別の コネクタへ送る必要があるときだけです。たとえば、内部 DNS サーバーが 1 つの Mesh ノードまたは Cloudflare Tunnel の背後にあり、アプリケーションは別のコネクタ経由で到達する場合です。その場合:

1. DNS サーバーの IP 向けに CIDR ルート を追加し、DNS サーバーがあるコネクタ（Mesh ノードまたは Cloudflare Tunnel）経由で Gateway が到達できるようにします。
2. そのホスト名（またはそのドメイン）の DNS クエリを、その内部 DNS サーバーへ送る リゾルバーポリシー を作成します。

パブリック ホスト名では、Mesh ノードが解決を担当します。Gateway は DNS クエリをノードへ送り、ノードはアップストリーム DNS プロバイダーで解決し、パケットを宛先へルーティングして、自身のパブリック IP でエグレスします。内部 DNS サーバーやリゾルバーポリシーは不要です。

ホスト名ルートを追加したあと、Access のセルフホストアプリケーション または Gateway ネットワークポリシー で保護します。詳細と例は、プライベートホスト名の接続 を参照してください。

Chrome 142 ↗ 以降、ローカルネットワークアクセス（Local Network Access、LNA）は、Web サイトからローカル IP アドレスへのリクエストを制限します。LNA は Chromium エンジン層で実装されているため、Google Chrome だけでなく、Chromium ベースのすべてのブラウザー（例: Microsoft Edge、Brave、Opera）に影響します。Gateway の 初期解決 IP 範囲が、まだキャリアグレード NAT（CGNAT）アドレス空間（100.64.0.0/10）から割り当てられているアカウントで、この問題が起きることがあります。例として、レガシーのデフォルト範囲 100.80.0.0/16 や、CGNAT 空間内に設定したカスタム範囲です。これらのブラウザーは、該当アドレスをローカルネットワークに属すると分類します。公開 IP から読み込んだ Web サイトが、この空間の初期解決 IP 経由で解決したドメインへサブリクエストを送ると、ブラウザーは公開ネットワークからローカルネットワークへのリクエストとして扱い、ローカルネットワーク上のデバイスへのアクセスを許可するようユーザーに確認します。ユーザーがこのプロンプトを許可するまで、ブラウザーはこれらのドメインへのリクエストをブロックします。

この問題は、広く使われるドメイン（cloudfront.net や github.com など）に Egress ポリシーが一致し、公開ページからのサブリクエストが CGNAT 空間へ解決されるときに、よく起きます。

現在のデフォルトの初期解決 IP 範囲（172.64.128.0/20）を使っているアカウントは影響を受けません。この範囲は CGNAT ではなく、Cloudflare の公開アドレス空間だからです。このデフォルトが変わる前に作成したアカウント、またはカスタムの CGNAT 空間範囲を設定したアカウントでは、次のブラウザー回避策に頼るのではなく、初期解決 IP を設定する を参照して、CGNAT 以外の範囲へ移してください。

以下の回避策は Google Chrome Enterprise ポリシーを使います。組織が別の Chromium ベースブラウザーを管理している場合は、同等の制御について、そのブラウザーのエンタープライズポリシーのドキュメントを確認してください。

影響を受けるリクエストが iframe 内から発生する場合（例: サードパーティポータルに埋め込まれたアプリケーション）、親フレームにブラウザーのプロンプトを表示するには、iframe が local-network-access 権限を宣言する必要があります。

• Chrome 142〜144: iframe 要素に allow="local-network-access" 属性を使います。
• Chrome 145 以降: 権限は allow="local-network" と allow="loopback-network" に分かれました。

iframe が入れ子になっている場合は、チェーン内のすべての iframe に適切な属性が必要です。サードパーティアプリケーションは自身の iframe 属性を制御するため、エンドユーザー側では設定できないことがあります。

この問題を避けるには、次のいずれかを選びます。

• IP アドレス空間の分類を上書きする（Chrome 146 以降）: LocalNetworkAccessIpAddressSpaceOverrides ↗ Chrome Enterprise ポリシーを使い、CGNAT 空間の初期解決 IP 範囲（例: 100.80.0.0/16）を公開として再分類します。セキュリティチェック全体を無効にするのではなく、初期解決 IP 範囲の分類だけを変えるため、いちばん対象を絞った対処です。
• 特定の URL を許可する（Chrome 140 以降）: LocalNetworkAccessAllowedForUrls ↗ Chrome Enterprise ポリシーを使い、特定の Web サイトをローカルネットワークアクセスのチェックから除外します。すべての URL でチェックを無効にする場合、https://* も有効なエントリです。
• 特定の URL を許可する（Chrome 146 以降）: LocalNetworkAllowedForUrls ↗ Chrome Enterprise ポリシーを使います。Chrome 146 以降、LocalNetworkAccessAllowedForUrls の代わりになります。
• ローカルネットワークアクセス制限をオプトアウトする（Chrome 142〜152）: LocalNetworkAccessRestrictionsTemporaryOptOut ↗ Chrome Enterprise ポリシーを使い、ローカルネットワークアクセス制限を完全にオプトアウトします。一時的なポリシーで、Chrome 152 以降は削除されます。
• Chrome の機能フラグを無効にする: chrome://flags を開き、Local Network Access Checks フラグを Disabled にします。個人ユーザー向けの方法で、エンタープライズ全体への展開には向きません。