Cloudflare Zero Trustトンネルをようやく理解した

 (david.coffee)
2 ポイント 投稿者 GN⁺ 2025-11-17 | 1件のコメント | WhatsAppで共有
  • Cloudflare Zero TrustとWarpを活用して、NAT・ファイアウォールの問題なしにプライベートネットワークを接続し、サービスへのアクセスを制御する構成を説明
  • Argoトンネルを通じてプライベートネットワークやローカルサービスを公開ドメインとして公開したり、Warp接続時のみアクセス可能なプライベートネットワークを構成可能
  • TailscaleはP2Pベースで高速だが、NAT環境では制約があり、Cloudflareはすべてのトラフィックをエッジネットワーク経由でルーティングして安定した接続を提供
  • Cloudflaredはトンネル作成、Warp Clientはネットワーク接続とポリシー適用を担当し、Tunnels・Routes・Targetsでトラフィックの流れとアクセス制御を構成
  • メールアドレス・GitHubログインなどによる細かなAccess Policyを設定し、Warp接続の有無に応じてログイン手順を省略または制限するセキュアなネットワーク環境を構築

Cloudflare Zero TrustとWarpの概要

  • TailscaleのNAT越え失敗をきっかけに、Cloudflare Zero Trust + Warpの学習を開始
  • Zero Trustトンネルを通じて、プライベートネットワーク接続、サービス公開、プライベートIPネットワーク構成、ローカルサービスの一時公開など多様な機能を活用可能
  • NATの問題なしにCloudflareネットワーク経由ですべてのトラフィックが転送され、きめ細かなアクセス ポリシーでユーザー・ボット・サーバー間のアクセス制御が可能
  • SSH接続時には公開ポートなしでZero Trust認証ベースのログインをサポート

Cloudflare Zero Trust vs Tailscale

  • TailscaleはNAT・ファイアウォールを回避してP2P接続を試み、不可能な場合は中継サーバーを使用
  • CloudflareはWarp-to-Warpを除くすべてのトラフィックがCloudflareエッジサーバーを経由して転送されるため、NATの問題はないが多少の遅延が発生

CloudflaredとWarpの違い

  • Warp Client: クライアントをCloudflareネットワークに接続し、ポリシーを適用するツール
    • 主にクライアントで実行されるが、サーバーでも使用可能
    • Warp-to-WarpルーティングでP2P接続をサポート
  • Cloudflared: トンネルを作成してZero Trustネットワークに追加するツール
    • サーバーで実行してネットワークの入口を提供
    • cloudflared accessコマンドで他のZero Trustリソースに接続可能
    • 単発テスト用のトンネル作成が可能

Tunnels, Routes, Targetsの構造

  • Tunnels: cloudflaredでデプロイされるトラフィックの出口地点
    • 例: ホームネットワーク(192.168.1.1/24)の常時稼働デバイスにインストール
    • 設定ファイル(/etc/cloudflared/config.yml)でリクエスト到着時のルーティング先を指定
    • 例: gitlab.widgetcorp.tech → localhost:80, gitlab-ssh → localhost:22
  • 公開例:
    • homeassistant.mydomain.com → 192.168.1.3へルーティング
    • Cloudflare DNSでCNAMEをトンネルアドレスに指定すればWarpなしでもアクセス可能
  • Routes: 特定のIP範囲をどのトンネルへ送るかを定義
    • 例: 192.168.1.1/24全体、または192.168.1.3/32単一IPを指定
    • Warp接続時、そのIPへのリクエストはCloudflareネットワーク経由でトンネルへ転送
    • 存在しない仮想IP(例: 10.128.1.1)もルーティング可能
  • Targets: 保護するインフラ単位を定義
    • 例: homeassistant.mydomain.com → 192.168.1.3/32
    • 対象にアクセス ポリシーを付与して特定ユーザーのみアクセス可能にする

Access Policies: アクセス制御

  • トンネル、ルート、ターゲットを構成した後、Access Policyでアクセス権限を設定
  • ポリシー構成要素
    • Include: アクセス許可条件(OR)
    • Require: 必ず満たすべき条件(AND)
    • Action: Allow / Deny / Bypass / Service Auth
  • 例1 – メールアドレスベースのアクセス制御
    • 特定のメールアドレスのみアクセスを許可
    • GitHubログイン方式で認証を制限可能
  • 例2 – Warp接続時はログイン省略
    • Gatewayセレクターを使ってZero Trust Warp接続時はログイン画面を省略
    • Warp未接続時にはGitHubログインを要求

Warpクライアントの配布と登録

  • Settings → Warp Clientで登録ポリシーを設定
    • GitHub認証および特定メールアドレスのみ登録を許可
    • WARP認証IDを設定するとGatewayセレクターを使用可能
  • Profile Settingsでクライアント動作を定義
    • プロトコル(MASQUE/WireGuard)、サービスモード、ルーティング除外IPなどを設定
    • Cloudflare CA自動インストール、固有のCGNAT IP割り当て、デバイス状態チェック(Device Posture)の設定が可能
  • Warpクライアントにログイン後、Zero Trustネットワークへの接続が完了
    • その後、192.168.1.3へのリクエストはトンネル経由でルーティングされる

構築結果の要約

  • GitHubおよびメールアドレスベースのログインポリシーでWarpクライアント登録
  • プライベートネットワーク内のトンネルがhomeassistant.mydomain.comへのリクエストを192.168.1.3へ転送
  • 192.168.1.3へのトラフィックはWarp接続時のみトンネル経由でアクセス可能
  • DNSベースの公開アクセスとWarpベースの非公開アクセスの2方式を提供
  • Warp接続時はログインを省略し、未接続時はGitHub認証を要求

追加で扱っていない項目

  • Warp-to-Warpルーティング
  • Zero Trust内部専用のプライベートIP作成
  • SSH認証ポリシー構成
  • Self-Hosted以外のアプリケーション種別

原文に追加情報なし

関連記事

1件のコメント

 
GN⁺ 2025-11-17
Hacker Newsの意見

  • CloudflareはTLS終端ポイントとして動作するため、個人利用には不利
    Tailscale Funnelを使えば証明書は自分のエンドポイントに直接インストールされるが、Cloudflareはトラフィックを途中で復号して再暗号化する
    WARPの個人ネットワークにおけるプライバシー水準はよく分からないが、インターネットトンネリングではプライバシー低下が大きいと考えている
    また、P2P接続 + リレーフォールバック構造は第三者中継なしでも動作するため、はるかに望ましいと思う

    • 最近、TunnelBuddyというプロジェクトを自作した
      友人のマシンをWebRTCベースのexit nodeとして使う構成で、TURN/relayサーバーなしのP2Pのみをサポートしている
      NAT環境によって接続成功率は低いが、トラフィックが第三者サーバーを通らないため、プライバシー保証は確実だ
    • 「Zero Trust」と言いながら、結局はCloudflareを全面的に信頼しなければならない構造なのが皮肉
    • 個人的にはTailscaleのほうを信頼しているが、Cloudflareのカスタムドメインとクライアント不要のアクセス機能は魅力的
      Caddyで似たように構成することもできるが、それでもポートフォワーディングは必要になる
    • awesome-tunnelingリストにあるNetFoundryも良い代替案
      エンドツーエンド暗号化と100以上のPoPによる性能・信頼性の確保が強み
    • connetはP2P + リレーフォールバック構成を目指している
      参加しているピアだけがエンドポイントを公開するため、セキュリティ・プライバシー面で有利
      自分でホスティングすることも、公式サービスを使うこともできる

  • 私は自宅と個人用途でNetbirdを使っている
    Synology NAS、家族のすべてのノートPC・デスクトップ・モバイルに入れており、Tmux環境でリモートデスクトップのように使うのに便利

  • 「すべてのトラフィックがCloudflareネットワークを通る」という一文で読むのをやめた
    Hyprspaceは私が出会ったあらゆるNATを突破してきたし、大企業のインフラなしでもうまく動く

  • これは本当に素晴らしい構成ガイドのように感じる
    Cloudflareがこれを文書化して公式ガイドとして使ってもよさそう

  • TailscaleがNAT環境でP2P接続を確立できないときにもどかしくて、Cloudflare Zero Trust + Warpを学んでみたという記事を読んだ
    しかしCloudflareはそもそもP2Pを試みることすらなく、結局Cloudflareの信頼モデルに切り替えることになる
    動機は理解しにくいが、記事そのものはよく整理されている

    • Cloudflareは世界中に高品質なPoPネットワークを持っているので、実際にはP2Pより品質が良かった
      わが社も全面リモートだが、TailscaleからCloudflareに移行してから性能が向上した
    • Cloudflare経由でもピア間暗号化が維持されるかが重要
      維持されるなら信頼モデルの違いはそれほど大きくないが、Cloudflareはリレー性能が強みなので速度面では有利
      それでもTailscaleのNATホールパンチング能力は優秀なので、可能なら直接接続を好む

  • 個人サービス公開用にtuns.shを使っている
    SSHトンネルベースなので、インストール不要ですぐ使える点が気に入っている

  • 記事もコメントもどちらも有益だった
    ただし本文の画像が壊れていて404エラーになる — 例: targets-config-screen.png

  • CFの神聖視された問題にようやく批判が出てきてうれしい
    Zero Trustモデルの問題点を指摘する議論が必要だと思う

  • 無料のCloudflareアカウントではPlexサーバーを運用できないのが致命的
    関連する規約はこちらで確認できる

    • もしかしてISPからIPv6の提供を受けている？
      私はIPv6ベースでEmbyとJellyfinを友人たちと問題なく使っている
    • 誰が無料で動画ストリーミングトラフィックを提供してくれると期待するのか？
      単純なWebトラフィックと違って、映画1本で数百倍の帯域コストが発生する
    • 私の無料アカウントではcloudflared tunnelでJellyfinが問題なく動いている
      彼女の仕事用ノートPCにはTailscaleをインストールできないので、この方法が役に立った
    • 実際にはトラフィックが多くなければ規約が厳格に適用されない
    • 私もJellyfinに使っているが、ここ数か月問題なく動作している

  • Cloudflareの利用はベンダーロックイン (vendor lock-in) ではないのかという疑問がある
    Tailscaleには少なくともそうしたロックインはないと思う

    • でもTailscaleも結局商用ベンダーだと知って驚いた
      オープンソースのプロジェクトだと思っていたが、そうではなかった