Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

プライベートホスト名を接続する

最終更新 Markdown で表示Agent セットアップ

静的な IP リストとルートを管理する代わりに、ホスト名（例: wiki.internal.local）を使って、ユーザーをプライベートな HTTP および非 HTTP アプリケーションに接続できます。プライベートホスト名ルートは、アプリケーションの IP が不明または一時的な場合に特に有用です。サードパーティのクラウドプロバイダーがインフラストラクチャをプロビジョニングするときに、よく起きます。

  1. クライアントデバイス

    wiki.internal.local を要求します

  2. DNS クエリ
  3. Cloudflare Gateway

    トークン IP を返し、宛先を実際の IP に書き換えます。

    172.64.128.0/20
  4. ホスト名ルート
  5. Cloudflare Tunnel

    トラフィックをプライベートネットワークへ転送するか、パブリックインターネットへエグレスします

  6. プライベートホスト

    wiki.internal.local · 10.0.0.50

ユーザーがプライベートホスト名をリクエストすると、Cloudflare Gateway は 初期解決 IP を割り当て、トンネル経由で正しいプライベート IP アドレスへトラフィックをルーティングします。デフォルトでは、この IP は Cloudflare 所有の公開 IPv4 範囲（172.64.128.0/20）から割り当てられ、Carrier-Grade NAT（CGNAT）空間からは割り当てられません。そのため Google Chrome の Local Network Access 制限 は発動しません。既存ネットワークと衝突する場合は、カスタム範囲を設定 することもできます。アーキテクチャとパケットフローの詳細は、発表ブログ記事 ↗ を参照してください。

対応するオンランプ / オフランプ

次の表は、プライベートホスト名ルーティングと互換性がある Cloudflare One 製品の要約です。表の見方は凡例を参照してください。

✅ 製品は制約なく使えます
🚧 製品は一部の制約付きで使えます
❌ 製品は使えません

デバイス接続

エンドユーザーは、次のトラフィックオンランプを使ってプライベートホスト名に接続できます。

オンランプ方式 互換性
Cloudflare One Client ✅
PAC files ✅
Browser Isolation ✅
Cloudflare Mesh ✅
Cloudflare WAN 🚧1

機能の利用可否

クライアントモード
Traffic and DNS モード
システム 利用可否 最小クライアントバージョン
Windows ✅ 2025.4.929.0
macOS ✅ 2025.4.929.0
Linux ✅ 2025.4.929.0
iOS ✅ 1.11
Android ✅ 2.4.2
ChromeOS ✅ 2.4.2

Footnotes

  1. ECMP ルーティング とは互換性がありません。ホスト名ベースのルーティングを動作させるには、DNS クエリとそれに続くネットワークトラフィックが、同じ IPsec/GRE トンネル経由で Cloudflare に到達する必要があります。
    ↩

プライベートネットワーク接続

プライベートホスト名ルーティングは、次のオフランプで動作します。その他のトラフィックオフランプには、IP ベースのルートが必要です。

コネクタ 互換性 最低バージョン
cloudflared ✅ 2025.7.0
Cloudflare Mesh ✅ 2026.6.822.0（Linux）
Cloudflare WAN ❌

プライベートホスト名を接続する

このセクションでは、cloudflared を使ってプライベートホスト名アプリケーションへのリモートアクセスを有効にする方法を説明します。

前提条件

プライベートホスト名に接続する前に、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 プロキシ を参照してください。

デバイスは、次のトラフィックも Cloudflare へ転送する必要があります。

  • 初期解決 IP:
    • IPv4: 172.64.128.0/20
    • IPv6: 2606:4700:0cf1:4000::/64

    これがデフォルトの範囲です。既存ネットワークと衝突する場合は、IPv4 向けに カスタムの初期解決 IP 範囲を設定 できます。

  • プライベートホスト名の DNS クエリ

設定手順は デバイスオンランプ によって異なります。

Cloudflare One Clients

  1. WARP の デバイスプロファイル で、初期解決 IP が WARP トンネル経由でルーティングされるよう Split Tunnels を設定します。設定内容は Split Tunnels のモード によって異なります。

    • Exclude mode: Split Tunnels のリストから 100.64.0.0/10 を削除します。Cloudflare One サービスで明示的に使っていない IP 範囲を戻す ことを推奨します。これにより、CGNAT アドレス空間を使う既存のプライベートネットワーク設定との衝突リスクを下げられます。
    • Include mode: 次の IP アドレスを Split Tunnel のエントリとして追加します。
      • IPv4: 172.64.128.0/20
      • IPv6: 2606:4700:0cf1:4000::/64

      これがデフォルトの範囲です。既存ネットワークと衝突する場合は、IPv4 向けに カスタムの初期解決 IP 範囲を設定 できます。

  2. Local Domain Fallback で、プライベートホスト名のトップレベルドメインを削除します。これにより WARP が DNS クエリを Cloudflare Gateway へ送り、解決します。

Cloudflare Mesh

ホスト名のトラフィックを cloudflared トンネルではなく Mesh ノードへ引き込むには、ノードに ホスト名ルート を追加します。上記の 初期解決 IP は、Mesh ノードとクライアントデバイスプロファイルの両方で Cloudflare 経由でルーティングする必要があります。プライベートホスト名の場合、ノードはそのホスト名を解決できる必要があります（ローカルの hosts ファイルまたは Gateway リゾルバーポリシー経由）。ホスト名ルート を参照してください。

Cloudflare WAN

  1. 上記の 初期解決 IP が、Cloudflare WAN から Cloudflare へ ルーティングされる ことを確認します。
  2. Cloudflare WAN ネットワークの DNS リゾルバーを Cloudflare Gateway に 向けます。

1. アプリケーションを Cloudflare に接続する

  1. Cloudflare ダッシュボードにログインし、Networking > Tunnels を開きます。

    Tunnels を開く ↗

  2. Create a tunnel を選択します。

  3. トンネルの名前を入力します。このトンネル経由で接続するリソースの種類がわかる名前（例: enterprise-VPC-01）を推奨します。

  4. Create Tunnel を選択します。

  5. オペレーティングシステムを選び、インストールコマンドをコピーして、オリジンサーバーのターミナルで実行します。

  6. トンネルの接続を待ちます。接続が確立したら Continue を選択します。

  1. トンネルが接続されたら、トンネルの Routes タブを開き、Add route を選んでから Private hostname を選びます。

  2. アプリケーションを表す完全修飾ドメイン名（FQDN）を入力します（例: wiki.internal.local）。

    ホスト名の形式制限

    • 文字数制限: 255 文字未満である必要があります。
    • 使えるワイルドカード: ワイルドカード（*）は 1 つだけ使え、DNS ラベル全体を表す必要があります。 例: *.internal.local
    • 使えないワイルドカード: 次のワイルドカード形式はサポートされていません。
      • *-dev.internal.local や dev-*.internal.local のような部分ワイルドカード。
      • foo*bar.internal.local や foo.*.internal.local のように、途中に入るワイルドカード。
      • *.*.internal.local のように、ホスト名に複数のワイルドカードがある場合。
    • ワイルドカードのトリム: 先頭のワイルドカード（*）は取り除かれ、暗黙のドット（.）があると見なされます。たとえば、*.internal.local は internal.local として保存されますが、ワイルドカード階層のすべてのサブドメインに一致します（foo.internal.local は対象、foo.bar.internal.local は対象外）。
    • ドットのトリム: 先頭と末尾のドット（.）は使えますが、保存時に取り除かれます。

  3. Save を選びます。

2. DNS 解決を設定する

Gateway がプライベートホスト名のリクエストを受け取ると、そのホスト名をプライベート IP アドレスに解決する必要があります。ネットワークトポロジーに応じて、設定方法は 2 つあります。

シナリオ A: システムリゾルバーを使う（デフォルト）

デフォルトでは、cloudflared はホストマシンに設定されたプライベート DNS リゾルバーを使います（Linux では例: /etc/resolv.conf）。

cloudflared を実行しているマシンが、ローカルシステムリゾルバーで wiki.internal.local をプライベート IP にすでに解決できる場合、追加の設定は不要です。ステップ 3 に進んでください。

シナリオ B: 特定のプライベート DNS サーバーを使う（上級）

cloudflared に、ホストのデフォルトリゾルバーとは異なる特定の内部 DNS サーバーを使わせる場合は、その DNS サーバーを IP/CIDR ルート で Cloudflare に明示的に接続する必要があります。あわせて、Gateway のリゾルバーポリシー を設定し、クエリをこのプライベート DNS サーバーへルーティングします。

  1. DNS サーバーの IP/CIDR ルートを作成する手順です。

    1. Networking > Routes を開きます。

      Routes を開く ↗

    2. Add CIDR route を選びます。

    3. 内部 DNS リゾルバーのプライベート IP アドレスを入力します。

    4. この DNS サーバーがあるネットワークに接続している Cloudflare Tunnel を選びます。

    5. Create を選びます。

  2. リゾルバーポリシーを作成する手順です。

    1. Traffic policies > Resolver policies を開きます。
    2. Create a policy を選びます。
    3. プライベートホスト名に一致する式を作成します。
      セレクター演算子値
      Hostinwiki.internal.local
    4. Configure custom DNS resolvers で、内部 DNS サーバーのプライベート IP アドレスを入力します。
    5. ドロップダウンメニューから - Private のルーティングオプションと、前の手順で選んだトンネルに割り当てた 仮想ネットワーク を選びます。
    6. Create policy を選びます。

3.（推奨）Gateway でネットワークトラフィックをフィルタする

デフォルトでは、Zero Trust 組織に登録したすべてのデバイスが、Cloudflare Tunnel 経由でプライベートネットワークに接続できます。Gateway を設定すると、ネットワークトラフィックを検査し、ユーザーのアイデンティティとデバイスポスチャに基づいてアクセスを許可またはブロックできます。ポリシー設計の詳細は、最初のアプリケーションを保護する を参照してください。

Cloudflare One Client のユーザーがプライベートネットワーク全体にアクセスできないようにするには、プライベート IP 空間向けの キャッチオール Gateway Block ポリシー を作成することを推奨します。そのうえで、特定のアプリケーションや IP へのアクセスを許可する、優先度の高い Allow ポリシー（Access または Gateway）を重ねます。

オプション 1: Access アプリケーション（推奨）

プライベートホスト名向けに Access セルフホストアプリケーション を作成し、そのアプリケーション内で Access ポリシー を設定できます。このオプションでは、SaaS やその他の Web アプリと並べてユーザーアクセスを管理できます。

オプション 2: Gateway ファイアウォールポリシー

従来のファイアウォールモデルでアプリケーションを保護したい場合は、SNI または SNI Domain セレクターを使って Gateway ネットワークポリシーを作成できます。保護をさらに厚くするには、Host または Domain の解決を許可またはブロックする Gateway DNS ポリシーを追加します。

ネットワークポリシーの例

次の例は 2 つのポリシーで構成されます。1 つ目は特定ユーザーがアプリケーションに到達できるようにし、2 つ目はその他すべてのトラフィックをブロックします。

  1. 会社の従業員を許可する
セレクター 演算子 値 論理演算 アクション
SNI in wiki.internal.local And Allow
User Email matches regex .*@example.com
  1. キャッチオールのブロックポリシー
セレクター 演算子 値 アクション
Destination IP in 10.0.0.0/8 Block

DNS ポリシーの例

セレクター 演算子 値 論理演算 アクション
Host in wiki.internal.local And Allow
User Email matches regex .*@example.com

4. 接続をテストする

エンドユーザーは、プライベートホスト名にアクセスしてアプリケーションに到達できます。たとえば、プライベート Web アプリケーションに接続するには、ブラウザーを開いて wiki.internal.local にアクセスします。

トラブルシューティング

接続できない場合は、次を確認してください。

  1. DNS 解決を確認する - デバイスから、プライベートホスト名を正常に解決できることを確認します。

    nslookup wiki.internal.local
    Server:		127.0.2.2
Address:	127.0.2.2#53

Non-authoritative answer:
Name:	wiki.internal.local
Address: 172.64.128.48

    クエリは WARP の DNS プロキシ を使って解決し、Gateway の 初期解決 IP を返す必要があります。クエリの解決に失敗するか、別の IP が返る場合は、Local Domain Fallback の構成と Gateway リゾルバーポリシー を確認してください。

  2. Gateway ログを確認する - Gateway ネットワークログ を確認し、ポリシーによって接続がブロックされていないかを見ます。

  3. トンネルの状態を確認する - トンネルの状態 を確認し、トンネルが正常で接続されていることを確かめます。

  4. 初期解決 IP への接続をテストする - プライベートホスト名でアプリケーションに接続すると、デバイスは 初期解決 IP へ接続します。

    curl -v4 http://wiki.internal.local
    * Trying 172.64.128.48:80...
* Connected to wiki.internal.local (172.64.128.48) port 80
...

    リクエストが失敗する場合は、初期解決 IP が WARP トンネル経由でルーティングされる ことを確認してください。トンネルログ を確認し、リクエストがアプリケーションのプライベート IP へルーティングされていることも確認できます。

制限

Google Chrome がプライベートホスト名へのアクセスを制限する

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 内から発生する場合（例: サードパーティポータルに埋め込まれたアプリケーション）、親フレームにブラウザーのプロンプトを表示するには、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 にします。個人ユーザー向けの方法で、エンタープライズ全体への展開には向きません。

役に立ちましたか？