Cloudflare Tunnel

解決する課題

• オリジンサーバーやオフィス内サービスを公開するためにインバウンドポートを開けたくない
• VPN機器やファイアウォールの穴あけ・保守にかかる運用負荷を減らしたい
• 動的IPやNAT配下、クラウド・オンプレ混在環境からでも安定して外部公開したい
• 社内アプリへのアクセスをゼロトラストな認証・認可でコントロールしたい
• DDoSや直接攻撃からオリジンのIPアドレスそのものを隠したい

主要概念と用語

• cloudflared: オリジン側（サーバーやコンテナ、オフィス内マシン）で動作する軽量デーモン。Cloudflareエッジへアウトバウンド接続を確立する
• トンネル（Tunnel）: cloudflaredとCloudflareエッジの間に張られる、複数の暗号化された永続コネクションの集合
• コネクタ（Connector）: 1つのトンネルを担う個々のcloudflaredプロセス。冗長化のため複数台を同一トンネルに参加させられる
• パブリックホスト名（Public Hostname）: トンネル経由で公開するホスト名と、その背後にあるローカルサービス（ポートやプロトコル）の対応付け
• プライベートネットワークルーティング（Private Network / WARP to Tunnel）: DNS名だけでなくIPアドレス帯そのものをトンネル経由でルーティングし、WARPクライアントから社内ネットワークへアクセスする仕組み
• オリジン証明書（Origin Certificate）: トンネル作成時にゾーンに紐づけて発行される証明書。cloudflaredがCloudflareアカウントに属することを証明する
• Cloudflare Access: トンネルの手前に置いて、公開したアプリへのアクセスをID・デバイス・場所などの条件で認可するゼロトラストサービス
• QUIC／HTTP2トランスポート: cloudflaredがエッジとの通信に使うプロトコル。ネットワーク状況に応じて選択される

仕様・制限・クォータ

• cloudflaredはオリジン側からアウトバウンドで接続を開始するため、オリジン側のファイアウォールでインバウンドポートを開放する必要がない
• 1つのトンネルに複数のcloudflaredインスタンスを参加させることで、単一障害点を避けた冗長構成にできる
• 公開できるプロトコルはHTTP／HTTPSに限らず、TCP・SSH・RDPなど任意のTCPベースのサービスにも対応する
• 設定はダッシュボードのUIから行う方法と、cloudflared設定ファイル（YAML）とトークンによるコマンドライン運用の両方がある
• トンネル数・ルート数などにはアカウントプランに応じた上限があり、詳細は公式ドキュメントとダッシュボードの表示に従う
• Kubernetes環境向けにcloudflaredのコンテナイメージやHelmでのデプロイもサポートされる

内部の仕組み

cloudflaredはオリジン側で起動すると、まずCloudflareアカウントに紐づくトークンまたは証明書を使って認証し、複数のCloudflareエッジロケーションへアウトバウンドの永続的な接続を確立します。この接続は暗号化されたトンネルとして維持され続けます。

クライアントがパブリックホスト名へリクエストを送ると、Cloudflareエッジはそのリクエストを最も近い健全なトンネル接続へ振り向け、確立済みのコネクションを通じてcloudflaredまで転送します。cloudflaredは設定に従い、ローカルのサービス（例えば同一ホスト上のWebサーバーやDBポート）へリクエストを中継し、応答を同じ経路で送り返します。

この方式により、オリジン側には着信のためのリスニングポートを一切開ける必要がなくなり、オリジンのグローバルIPアドレスも外部から見えなくなります。冗長化のために複数のcloudflaredプロセスを同じトンネルに参加させると、Cloudflareエッジは生きているコネクタへ自動的に振り分けます。

設計パターン / ベストプラクティス

• 本番運用では同一トンネルに複数のcloudflaredレプリカを異なるホストやリージョンで稼働させ、単一障害点を避ける
• 公開するアプリの手前にCloudflare Accessを組み合わせ、社内向けアプリであっても認証・認可を必須にする
• オリジン側のファイアウォールは、可能であればCloudflareからの通信のみを許可し、直接インターネットに晒される経路を残さない
• コンテナ環境やIaCで管理する場合は、cloudflaredの設定やトークンをシークレット管理の仕組みで扱い、平文でリポジトリに置かない
• 監視の観点では、cloudflaredのヘルスとトンネル接続状態をダッシュボードやログ連携で継続的に確認する

運用・監視

• ダッシュボードでトンネルごとのコネクタの稼働状況・接続数・直近のエラーを確認できる
• cloudflaredはログを標準出力やログ管理基盤へ送れるため、接続断や再接続の頻度を継続的に監視する
• 複数コネクタ構成では、一部のコネクタが落ちても他が引き継ぐため、アラートはコネクタ全滅時に絞るなどノイズを減らす工夫が有効
• 設定変更（パブリックホスト名の追加・変更）はダッシュボードまたはAPI経由で行い、変更履歴を追跡できるようにする

コスト

Cloudflare Tunnel自体はcloudflaredの利用に対して基本的な公開機能では追加費用がかからない位置づけで提供されていますが、組み合わせるCloudflare One系サービス（AccessのシートやGatewayなど）や上位プランの機能を使う場合は別途費用が発生し得ます。具体的な条件や金額は変わりやすいため、契約中のプランと公式の料金ページで確認することが望ましいです。

セキュリティ

• インバウンドポートを開けないため、ポートスキャンや直接攻撃の対象領域そのものを減らせる
• Cloudflare Accessと組み合わせることで、社内アプリであってもID・グループ・デバイス状態に基づく認可を強制できる
• トンネル経由の通信は暗号化されているが、オリジン内部でのサービス間通信やローカルの認証も別途しっかり設計する必要がある
• トンネルのトークンや証明書は最小権限の原則で発行・管理し、不要になったトンネルは削除する
• 監査ログでトンネルの作成・変更・削除やAccessポリシーの変更を追跡し、不正な設定変更を検知する

関連サービス・比較

Cloudflare Tunnelは、Cloudflare Access・WARP・Gatewayなど他のCloudflare Oneコンポーネントと組み合わせて使われることが多いです。伝統的な代替手段としては、リバースSSHトンネルや商用VPN製品が近い役割を担ってきました。

ハンズオン / CLI例

cloudflaredのインストール後、Cloudflareアカウントへログインしてトンネルを作成し、パブリックホスト名を設定する典型的な流れです。

# Cloudflareアカウントへログインし、証明書を取得
cloudflared tunnel login

# 新しいトンネルを作成（名前を指定）
cloudflared tunnel create my-app-tunnel

# 作成したトンネルの一覧・IDを確認
cloudflared tunnel list

# 設定ファイル（config.yml）でパブリックホスト名とローカルサービスを紐付け
cat <<'EOF' > config.yml
tunnel: my-app-tunnel
credentials-file: /root/.cloudflared/<TUNNEL_ID>.json

ingress:
  - hostname: app.example.com
    service: http://localhost:8080
  - service: http_status:404
EOF

# DNSレコードをトンネルに向ける
cloudflared tunnel route dns my-app-tunnel app.example.com

# トンネルを起動（フォアグラウンド実行例）
cloudflared tunnel --config config.yml run my-app-tunnel