コンテンツにスキップ

WARPアーキテクチャ

このガイドでは、Cloudflare WARPクライアントがデバイスのオペレーティングシステムとどのように相互作用し、Gateway with WARPモードでトラフィックをルーティングするかを説明します。

Gateway with DoHモードでは、IPトラフィック情報は適用されません。Secure Web Gateway without DNS filteringモードでは、DNSトラフィック情報は適用されません。

概要

WARPクライアントは、組織がエンドユーザーデバイスがアクセスできるアプリケーションを詳細に制御できるようにします。クライアントは、デバイスからCloudflareのグローバルネットワークにDNSおよびネットワークトラフィックを転送し、そこでZero Trustポリシーがクラウドで適用されます。すべてのオペレーティングシステムで、WARPデーモンはデバイスとCloudflareの間に3つの接続を維持します。

接続プロトコル目的
デバイスオーケストレーションHTTPSユーザー登録の実行、デバイスの姿勢の確認、WARPプロファイル設定の適用。
DoHHTTPSDNSポリシーの強制のためにGatewayにDNSリクエストを送信します。
WARPトンネル (via WireGuard or MASQUE)UDPネットワークポリシーの強制、HTTPポリシーの強制、およびプライベートネットワークアクセスのためにGatewayにIPパケットを送信します。
flowchart LR
subgraph Device
W[WARP client] -.-> D
D[DNS proxy]
W -.-> V[Virtual interface]
end
subgraph Cloudflare
A[Zero Trust account]
subgraph Gateway
G[DNS resolver]
N[L3/L4 firewall]
end
end
W<--デバイスオーケストレーション-->A
D<--DoH-->G
V<--WARPトンネル-->N
N --> O[(アプリケーション)]

あなたのSplit Tunnel設定は、WARPトンネルを通じて送信されるトラフィックを決定します。あなたのLocal Domain Fallback設定は、DoHを介してGatewayに送信されるDNSリクエストを決定します。DoHエンドポイントおよびデバイスオーケストレーションAPIエンドポイントへのトラフィックは、Split Tunnelルールに従いません。これらの接続は常にWARPトンネルの外で動作します。

次に、WARPがオペレーティングシステムをどのように構成して、Local Domain FallbackおよびSplit Tunnelルーティングルールを適用するかを学びます。実装の詳細は、デスクトップクライアントとモバイルクライアントで異なります。

Windows、macOS、およびLinux

デスクトップクライアントは、デバイス上のすべてのWARP機能を処理するサービス/デーモンと、ユーザーがデーモンと対話しやすくするためのGUIラッパーの2つのコンポーネントで構成されています。

DNSトラフィック

WARPをオンにすると、WARPはデバイス上にローカルDNSプロキシを作成し、これらのIPアドレスにポート53(DNSトラフィック用に指定されたポート)をバインドします:

  • IPv4: 127.0.2.2 および 127.0.2.3
  • IPv6:
    • macOSおよびLinux: fd01:db8:1111::2 および fd01:db8:1111::3
    • Windows: ::ffff:127.0.2.2

その後、WARPはオペレーティングシステムを構成して、すべてのDNSリクエストをこれらのIPアドレスに送信します。デバイス上のすべてのネットワークインターフェースは、DNS解決のためにこのローカルDNSプロキシを使用します。言い換えれば、すべてのDNSトラフィックはWARPクライアントによって処理されます。

あなたのLocal Domain Fallback設定に基づいて、WARPはDNSポリシーの強制のためにGatewayにリクエストを転送するか、プライベートDNSリゾルバーにリクエストを転送します。

  • Gatewayへのリクエストは、私たちのDoH接続(WARPトンネルの外)を介して送信されます。
  • プライベートDNSリゾルバーへのリクエストは、あなたのSplit Tunnel設定に応じてトンネルの内外に送信されます。詳細については、WARPクライアントがDNSリクエストを処理する方法を参照してください。
flowchart LR
D{{DNSリクエスト}}-->L["ローカルDNSプロキシ <br> (127.0.2.2 および 127.0.2.3)"]-->R{ローカルドメインフォールバック?}
R -- はい --> F[プライベートDNSリゾルバー]
R -- いいえ --> G[Cloudflare Gateway]

オペレーティングシステムがWARPのローカルDNSプロキシを使用していることを確認できます:

macOSでは、ターミナルウィンドウを開き、scutil --dnsを実行します。DNSサーバーはWARPのローカルDNSプロキシIPに設定されているはずです。

Terminal window
scutil --dns
DNS configuration (for scoped queries)
resolver #1
search domain[0] : <DNS-SEARCH-DOMAIN>
nameserver[0] : 127.0.2.2
nameserver[1] : 127.0.2.3
if_index : 15 (en0)
flags : Scoped, Request A records
reach : 0x00030002 (Reachable,Local Address,Directly Reachable Address)
resolver #2
nameserver[0] : 127.0.2.2
nameserver[1] : 127.0.2.3
nameserver[2] : fd01:db8:1111::2
nameserver[3] : fd01:db8:1111::3
if_index : 23 (utun3)
flags : Scoped, Request A records, Request AAAA records
reach : 0x00030002 (Reachable,Local Address,Directly Reachable Address)

IPトラフィック

WARPをオンにすると、WARPはデバイス上でトラフィックがWARPトンネルの内外に送信されるかを制御するために3つの変更を行います:

flowchart LR
P{{IPパケット}}-->R["OSルーティングテーブル"]-->F["OSファイアウォール"] --> S{Split Tunnelsから除外されている?}
S -- はい --> A[(アプリケーション)]
S -- いいえ --> U["仮想インターフェース<br> (172.16.0.2)"] --> G[Cloudflare Gateway]

仮想インターフェース

仮想インターフェースは、オペレーティングシステムが物理インターフェース(ネットワークインターフェースコントローラー(NIC)など)を論理的に細分化し、IPトラフィックをルーティングするための別々のインターフェースに分割することを可能にします。WARPの仮想インターフェースは、デバイスとCloudflareの間のWireGuard/MASQUE接続を維持します。デフォルトでは、そのIPアドレスは172.16.0.2としてハードコーディングされています。Override local interface IPを使用して、デバイスごとにユニークなIPを割り当てることができます。

オペレーティングシステム上のすべてのネットワークインターフェースのリストを表示するには:

macOSでは、ifconfigを実行します。WARPがオンのとき、IPアドレス172.16.0.2を持つutunインターフェースが表示されます。

Terminal window
ifconfig
<redacted>
utun3: flags=8051<UP,POINTOPOINT,RUNNING,MULTICAST> mtu 1280
inet 172.16.0.2 --> 172.16.0.2 netmask 0xffffffff
inet6 fe80::f6d4:88ff:fe82:6d9e%utun3 prefixlen 64 scopeid 0x17
inet6 2606:4700:110:8c7d:7369:7526:a59b:5636 prefixlen 128
nd6 options=201<PERFORMNUD,DAD>

ルーティングテーブル

WARPは、GatewayにどのIPトラフィックが送信されるかを制御するためにシステムのルーティングテーブルを編集します。ルーティングテーブルは、特定のIPアドレスへのパケットを処理するネットワークインターフェースを示します。デフォルトでは、Split Tunnel除外リストにあるIPおよびドメインを除いて、すべてのトラフィックがWARPの仮想インターフェースを通じてルーティングされます。

ルーティングテーブルがあなたのSplit Tunnelルールと一致していることを確認できます:

macOSでルーティングテーブル全体を表示するには、netstat -rを実行します。

ドメインまたはIPアドレスをルーティングテーブルで検索することもできます。この例では、google.comへのトラフィックがこのデバイスのWARP仮想インターフェースであるutun3を通じて送信されることがわかります:

Terminal window
route get google.com
route to: lga25s81-in-f14.1e100.net
destination: 136.0.0.0
mask: 248.0.0.0
interface: utun3
flags: <UP,DONE,PRCLONING>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 1280 0

対照的に、このDHCPアドレスはWARPから除外され、デフォルトインターフェースを使用します:

Terminal window
route get 169.254.0.0
route to: 169.254.0.0
destination: 169.254.0.0
mask: 255.255.0.0
interface: en0
flags: <UP,DONE,CLONING,STATIC>
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
0 0 0 0 0 0 1500 -210842

システムファイアウォール

WARPはオペレーティングシステムのファイアウォールを変更して、あなたのスプリットトンネルルールを強制します。これは、サービスがルーティングテーブルをバイパスして別のインターフェースを通じてトラフィックを直接送信しようとした場合に備えて、保護の層を追加します。たとえば、203.0.113.0へのトラフィックがGatewayによって検査されるべき場合、utun以外のすべてのインターフェースで203.0.113.0をブロックするファイアウォールルールを作成します。

iOS、Android、およびChromeOS

iOSおよびAndroid/ChromeOSでは、Cloudflare One AgentはVPNクライアントとして自動的にインストールされ、すべてのトラフィックをキャプチャしてルーティングします。このアプリは、iOSおよびAndroidの公式VPNフレームワークに基づいて構築されています。詳細については、AppleのNetworkExtensionドキュメントおよびGoogleのAndroid開発者ドキュメントを参照してください。

ChromeOSは、ネイティブのChromeアプリを実行するのではなく、仮想マシン内でAndroidアプリを実行することに注意してください。