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プロファイル設定の適用。 |
| DoH ↗ | HTTPS | DNSポリシーの強制のために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ルーティングルールを適用するかを学びます。実装の詳細は、デスクトップクライアントとモバイルクライアントで異なります。
デスクトップクライアントは、デバイス上のすべてのWARP機能を処理するサービス/デーモンと、ユーザーがデーモンと対話しやすくするためのGUIラッパーの2つのコンポーネントで構成されています。
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
- macOSおよびLinux:
その後、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に設定されているはずです。
scutil --dnsDNS 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)Windowsでは、PowerShellウィンドウを開き、ipconfigを実行します。DNSサーバーはWARPのローカルDNSプロキシIPに設定されているはずです。
PS C:\> ipconfigWindows IP Configuration
Unknown adapter CloudflareWARP:
Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Cloudflare WARP Interface Tunnel Physical Address. . . . . . . . . : DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes IPv6 Address. . . . . . . . . . . : 2606:4700:110:8f79:145:f180:fc4:8106(Preferred) Link-local IPv6 Address . . . . . : fe80::83b:d647:4bed:d388%49(Preferred) IPv4 Address. . . . . . . . . . . : 172.16.0.2(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.255 Default Gateway . . . . . . . . . : DNS Servers . . . . . . . . . . . : 127.0.2.2 127.0.2.3 NetBIOS over Tcpip. . . . . . . . : EnabledLinuxでは、/etc/resolv.confファイルを確認します。DNSサーバーはWARPのローカルDNSプロキシIPに設定されているはずです。
cat /etc/resolv.conf# This file was generated by cloudflare-warp.nameserver 127.0.2.2nameserver 127.0.2.3nameserver fd01:db8:1111::2nameserver fd01:db8:1111::3search <DNS-SEARCH-DOMAIN>options edns0options trust-adWARPをオンにすると、WARPはデバイス上でトラフィックがWARPトンネルの内外に送信されるかを制御するために3つの変更を行います:
- 仮想ネットワークインターフェースを作成します。
- あなたのSplit Tunnelルールに従ってオペレーティングシステムのルーティングテーブルを修正します。
- あなたのSplit Tunnelルールに従ってオペレーティングシステムのファイアウォールを修正します。
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インターフェースが表示されます。
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>Windowsでは、ipconfigを実行します。WARPがオンのとき、IPアドレス172.16.0.2を持つCloudflareWARPというアダプターが表示されます。
PS C:\> ipconfigWindows IP Configuration
Unknown adapter CloudflareWARP:
Connection-specific DNS Suffix . : Description . . . . . . . . . . . : Cloudflare WARP Interface Tunnel Physical Address. . . . . . . . . : DHCP Enabled. . . . . . . . . . . : No Autoconfiguration Enabled . . . . : Yes IPv6 Address. . . . . . . . . . . : 2606:4700:110:8f79:145:f180:fc4:8106(Preferred) Link-local IPv6 Address . . . . . : fe80::83b:d647:4bed:d388%49(Preferred) IPv4 Address. . . . . . . . . . . : 172.16.0.2(Preferred) Subnet Mask . . . . . . . . . . . : 255.255.255.255 Default Gateway . . . . . . . . . : DNS Servers . . . . . . . . . . . : 127.0.2.2 127.0.2.3 NetBIOS over Tcpip. . . . . . . . : EnabledLinuxでは、ifconfigまたはip addrを実行します。WARPがオンのとき、IPアドレス172.16.0.2を持つutunインターフェースが表示されます。
ip addr<redacted>3: CloudflareWARP: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1280 qdisc mq state UNKNOWN group default qlen 500 link/none inet 172.16.0.2/32 scope global CloudflareWARP valid_lft forever preferred_lft forever inet6 2606:4700:110:8a2e:a5f7:a8de:a1f9:919/128 scope global valid_lft forever preferred_lft forever inet6 fe80::117e:276b:8a79:c498/64 scope link stable-privacy valid_lft forever preferred_lft foreverWARPは、GatewayにどのIPトラフィックが送信されるかを制御するためにシステムのルーティングテーブルを編集します。ルーティングテーブルは、特定のIPアドレスへのパケットを処理するネットワークインターフェースを示します。デフォルトでは、Split Tunnel除外リストにあるIPおよびドメインを除いて、すべてのトラフィックがWARPの仮想インターフェースを通じてルーティングされます。
ルーティングテーブルがあなたのSplit Tunnelルールと一致していることを確認できます:
macOSでルーティングテーブル全体を表示するには、netstat -rを実行します。
ドメインまたはIPアドレスをルーティングテーブルで検索することもできます。この例では、google.comへのトラフィックがこのデバイスのWARP仮想インターフェースであるutun3を通じて送信されることがわかります:
route get google.com route to: lga25s81-in-f14.1e100.netdestination: 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から除外され、デフォルトインターフェースを使用します:
route get 169.254.0.0 route to: 169.254.0.0destination: 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 -210842Windowsでルーティングテーブル全体を表示するには、netstat -rを実行します。
IPアドレスをルーティングテーブルで検索することもできます。この例では、1.1.1.1へのトラフィックがWARP仮想インターフェースを通じて送信されることがわかります:
PS C:\> Find-NetRoute -RemoteIPAddress "1.1.1.1" | Select-Object InterfaceAlias -Last 1InterfaceAlias--------------CloudflareWARP対照的に、このDHCPアドレスはWARPから除外され、デフォルトインターフェースを使用します:
PS C:\> Find-NetRoute -RemoteIPAddress "169.254.0.0" | Select-Object InterfaceAlias -Last 1InterfaceAlias--------------Wi-FiLinuxでルーティングテーブル全体を表示するには、ip -6 route show table allまたはip -4 route show table allを実行します。
IPアドレスをルーティングテーブルで検索することもできます。この例では、1.1.1.1へのトラフィックがWARP仮想インターフェースを通じて送信されることがわかります:
ip route get 1.1.1.11.1.1.1 dev CloudflareWARP table 65743 src 172.16.0.2 uid 1000 cache対照的に、このDHCPアドレスはWARPから除外され、デフォルトインターフェースを使用します:
ip route get 169.254.0.0169.254.0.0 dev ens18 src 172.24.8.6 uid 1000 cacheWARPはオペレーティングシステムのファイアウォールを変更して、あなたのスプリットトンネルルールを強制します。これは、サービスがルーティングテーブルをバイパスして別のインターフェースを通じてトラフィックを直接送信しようとした場合に備えて、保護の層を追加します。たとえば、203.0.113.0へのトラフィックがGatewayによって検査されるべき場合、utun以外のすべてのインターフェースで203.0.113.0をブロックするファイアウォールルールを作成します。
iOSおよびAndroid/ChromeOSでは、Cloudflare One AgentはVPNクライアントとして自動的にインストールされ、すべてのトラフィックをキャプチャしてルーティングします。このアプリは、iOSおよびAndroidの公式VPNフレームワークに基づいて構築されています。詳細については、AppleのNetworkExtensionドキュメント ↗およびGoogleのAndroid開発者ドキュメント ↗を参照してください。
ChromeOSは、ネイティブのChromeアプリを実行するのではなく、仮想マシン内でAndroidアプリを実行することに注意してください。