ベストプラクティス

Cloudflare Mesh デプロイの運用ガイダンスです。クライアントの更新、クラウドプロバイダーの設定、Cloudflare Tunnel との併用、よくあるトラブルシューティングを扱います。

Mesh ノードの更新は、Linux ホスト上の cloudflare-warp パッケージを更新することを意味します。更新中にノードは短時間切断され、そこを経由するトラフィックが中断します。高可用性 が有効なら、トラフィックはスタンバイレプリカへ自動フェイルオーバーします。

3. ノードが再接続したことを確認します。

   warp-cli status

   出力に Status update: Connected が表示されます。

IP 転送により、Mesh ノードはゲートウェイとして動作し、ネットワークインターフェースと Cloudflare ネットワークの間でパケットを転送できます。これはノードが CIDR ルート を通知する場合にのみ必要です。Mesh IP だけでノードに到達する場合、転送は不要です。

古いインストールでは IP 転送に sysctl -w を使っていたことがあり、再起動後は保持されません。サーバー再起動後にルート接続が失われる場合は、次を実行して転送を永続化します。

printf 'net.ipv4.ip_forward = 1\nnet.ipv6.conf.all.forwarding = 1\nnet.ipv6.conf.all.accept_ra = 2\n' | sudo tee /etc/sysctl.d/99-zzz-cloudflare-warp-connector.conf && sudo sysctl --system

設定が有効かどうかは次で確認できます。

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding net.ipv6.conf.all.accept_ra

新しいインストールでは、この手順は自動的に含まれます。

クラウド VPC に Mesh ノードをデプロイする場合、ノードがサブネット上の他デバイス向けにトラフィックを転送できるよう、追加のプロバイダー設定が必要になることがあります。

Mesh ノードをインストールした VM インスタンスで IP 転送を有効化 ↗ します。

• EC2 インスタンスで 送信元 / 宛先チェック ↗ を無効にします。
• サブネットのルートテーブル ↗ に、Mesh トラフィック（たとえば 100.96.0.0/12）を EC2 インスタンスへ向けるルートを追加します。

• VM のネットワークインターフェースで IP 転送を有効化 ↗ します。
• Mesh トラフィックを VM のプライベート IP へ向ける ユーザー定義ルート ↗ を追加します。

Mesh ノードは Traffic and DNS モード で動き、ホスト上の DNS クエリを Cloudflare Gateway へリダイレクトします。同じマシンで動く DNS サービス（Active Directory DNS、Pi-hole、Unbound、BIND、dnsmasq など）と競合します。

サーバーで DNS サービスを動かしている場合、そのホストに Mesh ノードをインストールしないでください。同じサブネット上の別マシンにノードをインストールし、CIDR ルート で DNS サーバーへ到達できるようにします。

Cloudflare One Client は仮想ネットワークインターフェースを作成し、システムのルーティングテーブルを管理します。同じことをする他のソフトウェア（Tailscale、WireGuard、OpenVPN、Cisco AnyConnect、GlobalProtect、ZScaler、Netskope、従来の VPN クライアント）は、ルーティングの制御を奪い合います。同時実行すると動作が予測不能になり、トラフィックが誤ったトンネルを通ったり、完全に失敗したりします。

別のソリューションから Cloudflare Mesh へ移行する場合:

1. 他のクライアントをアンインストールまたは無効化します（Linux では sudo systemctl stop tailscaled && sudo systemctl disable tailscaled、macOS / Windows ではシステムトレイからアプリケーションを終了します）。
2. マシンを再起動し、Cloudflare One Client の仮想ネットワークインターフェースがルーティングテーブルで優先されるようにします。
3. warp-cli status を実行し、Mesh IP へ ping して接続を確認します。

これは Mesh ノードとクライアントデバイスの両方に当てはまります。

Mesh ノード (warp-cli) と Cloudflare Tunnel (cloudflared) は、同じ Linux ホストで実行できます。Mesh ノードをプライベートネットワークのゲートウェイとして使い、同時に Cloudflare Tunnel で特定のアプリケーションを公開したい場合に便利です。

Mesh ノードはアウトバウンドトラフィックを捕捉して Cloudflare 経由でルーティングするため、cloudflared が必要なアウトバウンド接続を確立できなくなることがあります。これを解消するには、Split Tunnels で、Tunnel with firewall に列挙されたホスト名と IP を除外します。

Cloudflare Mesh と Cloudflare WAN の間でトラフィックをルーティングする（WAN 接続サイトから Mesh ノードへ到達する、またはその逆）には、アカウントが Unified Routing モード である必要があります。Unified Routing は、すべての接続タイプ（Cloudflare One Client、Cloudflare Tunnel、IPsec、GRE、CNI）に単一のルーティングファブリックを使います。これがないと、Mesh と WAN の接続はトラフィックを交換できません。

Cloudflare Workers は VPC Network バインディング を使って Mesh ネットワークに接続できます。cf1:network にバインドすると、特定のトンネル UUID を指定せずに、アカウント内の任意の Mesh ノード、クライアントデバイス、サブネットルートへ到達できます。

同じバインディングは、パブリックインターネット宛てのアウトバウンドトラフィックも処理します。リクエストは Cloudflare Gateway 経由でエグレスするため、既存の Zero Trust トラフィックポリシーが適用され、Worker のトラフィックは他のトラフィックと並んで Gateway の DNS、HTTP、Network ログに現れます。

セットアップ手順と例は Workers を Cloudflare Mesh に接続する を参照してください。

Load Balancing のヘルスチェックや Workers など、Cloudflare サービスが Mesh ノード経由でプライベートネットワークへトラフィックを送るとき、トラフィックは Cloudflare の送信元 IP 範囲（デフォルト 100.64.0.0/12）から始まります。IP の衝突を避けるため、Cloudflare 送信元 IP の設定 が必要になることがあります。

Mesh ノードはカプセル化でトラフィックをルーティングするため、各パケットにオーバーヘッドが加わります。2 つの Mesh 参加者間のトラフィックでは特に重要です。パケットが二重にカプセル化されることがあるためです（送信ノードで一度、受信側へ届ける前に Cloudflare でもう一度）。

送信元デバイスが最大サイズ近く（1,460 バイト以上）のパケットを送ると、二重カプセル化で 1,500 バイトを超え、パケットが破棄されることがあります。

• 送信元デバイス（サーバー、カメラ、IoT デバイス）の MTU を 1,280 バイト に設定し、カプセル化後もパケットが収まるようにします。
• TCP のみのトラフィックでは、ルーターで MSS クランプを 1,240 バイト（1,280 MTU - 20 バイト IP ヘッダー - 20 バイト TCP ヘッダー）に適用します。
• Path MTU Discovery (PMTUD) ↗ を使う最近のアプリケーションは、通常これを自動で処理します。