Cloudflare Tunnel

Cloudflare WAN（旧 Magic WAN）は Cloudflare Tunnel と組み合わせて、ネットワークとアプリケーション間のアクセスを簡単にできます。

デフォルトでは、Cloudflare Gateway は、IPsec / GRE トンネル経由でルーティングされ、Cloudflare Tunnel 背後のルート宛てとなる TCP、UDP、ICMP トラフィックをプロキシし、フィルタします。

Cloudflare は最長プレフィックス一致でプライベートネットワークルートを評価します。プレフィックスは、ベース IP アドレスと、ネットワーク部分を定義するビット数を示すプレフィックス長を組み合わせます（例: 192.168.0.0/24）。複数のルートが宛先 IP に一致しうる場合、Cloudflare は最も長いプレフィックス（最も具体的な一致）のルートを選びます。

たとえば、10.0.0.0/16 と 10.0.1.0/24 の両方のルートがある場合、10.0.1.50 宛てのトラフィックは、より具体的なため /24 ルートに一致します。

仮想ネットワーク 内では、各プレフィックスは Zero Trust ルーティングテーブルに 1 回だけ現れます。同じ仮想ネットワーク内で、異なるトンネルを指す同じプレフィックスの Zero Trust ルートを 2 つ作成することはできません。

同じプレフィックスを異なる宛先へルーティングするには、別々の 仮想ネットワーク を使います。

Cloudflare は Zero Trust サービス向けに次の IP 範囲を予約しています。

これらの予約範囲と重なるルートは設定しないでください。

アカウントで WAN 接続（IPsec、GRE、CNI）も使う場合、ルート選択の動作はルーティングモードに依存します。

詳細は Zero Trust 接続でのルート評価 を参照してください。

最長プレフィックス一致ルーティングは、デフォルトのルート選択方法です。ほかのメカニズムは、ルート評価を迂回または補強できます。

Automatic Return Routing は、戻りトラフィックのルート参照を迂回します。

ARR が有効な場合:

1. Cloudflare はフロー確立時に、各フローに送信元接続（トンネルまたはインターコネクト）をタグ付けします。
2. 戻りトラフィックでは、Cloudflare はルーティングテーブルを迂回し、タグ付けした送信元接続へパケットを直接戻します。
3. これにより、複数のサイトが NAT や VRF の設定なしで、同一のプライベート IP 範囲を使えます。

ARR には Unified Routing モードが必要です。詳細は Automatic Return Routing を参照してください。

ホスト名ベースのルーティング は、Gateway DNS を使ってホスト名を Initial resolved IPs に解決し、それらを特定のネクストホップに対応づけます。

Hostname Routes が有効な場合:

1. Gateway DNS はホスト名を Initial resolved IP に解決します（デフォルトは 172.64.128.0/20）。
2. クライアントは Initial resolved IP へトラフィックを送ります。
3. Cloudflare は Initial resolved IP を参照し、実際の宛先 IP と割り当てられたネクストホップ（特定のトンネルまたはインターコネクト）を判断します。
4. トラフィックは割り当てられたネクストホップへ転送され、ネクストホップ選択のルート評価を迂回します。

これにより、宛先 IP を事前に知らなくても、非 HTTP トラフィック向けのホスト名ベースのポリシーが可能になります。

cloudflared トンネルが Cloudflare WAN 接続と正しく動くことを確認する手順は次のとおりです。

1. お客様構内機器の背後にあるホストからブラウザーを開きます。
2. Cloudflare Tunnel のプライベートネットワークルート経由で到達できる IP アドレスまたはホスト名を開きます。例の宛先は 10.1.2.3 です。
3. アプリケーションが想定どおり読み込まれることを確認します。読み込まれる場合、Cloudflare Tunnel は設定どおりにトラフィックを処理しています。