WARP 基本動作

Cloudflare Zero Trust で WARP クライアントエージェントを使うときの基本動作は以下のようになります。

DNS クエリについては Gateway の DNS resolver に対して DoH で Wireguard トンネルの外で投げる形です。

そのため、下記ドキュメントにある通り DoH IP への通信をファイアウォールで許可する必要があります。

Cloudflare Zero Trust における DNS クエリの扱い

基本動作から諸々の設定を鑑みた場合の動作は以下のようになります。

例えば、ブラウザの Secure DNS 設定や CLI ツールの種類によっては WARP クライアントの Local DNS proxy まで到達しないケースもあります。

また、その後の Local Domain Fallback 設定によって　DNS フィルタリングをバイパスする（させる）ケースがあります。

Resolver Policies

DNS フィルタリングをバイパスしてしまうことは、ログの機会を逸し、透明性の観点からも必ずしも良いことではありません。

そのため、Resolver Policies を使って解決できる課題がいくつかあります。

2024年5月時点では Only available on Enterprise plans となっています。

Cloudflare Tunnel や Magic WAN トンネルを経由した Private DNS 名前解決に DNS ポリシーを適用できる
- Local Domain Fallback でもPrivate DNS 名前解決自体は実現可能ですが、DNS ポリシーをバイパスするため、名前解決に関するフィルタリングやログができません。一方で Resolver Policies を使えば、Private DNS 名前解決に加えて DNS ポリシーによるフィルタリングやログが可能です。
エージェントレスな接続方式でも、プライベートウェブアプリに到達できる
- Proxy Endpoint や Clientless Web Isolation のエージェントレスアクセスからも Private DNS 名前解決ができるようになるため、Cloudflare Tunnel や Magic WAN トンネル先のプライベート IP に対してウェブアクセスが可能になります。
1.1.1.1 以外のパブリックリゾルバ（8.8.8.8 や 9.9.9.9 等）を利用できる
- どうしても 1.1.1.1 で名前解決できない場合には、必要になることがあるかもしれず、取れる選択肢があることは重要です。

テスト

以下のような構成でテストします。

Resolver Policies 設定

ホスト名が resolve-private.example.com なら、カスタムリゾルバ 10.146.0.10 を使います。

動作確認（WARP）

resolve-private.example.com にアクセスすると、サーバーの IP アドレスが 10.146.0.11 と名前解決されてアクセスしたことがわかります。
また、Cloudflare Gateway の証明書が表示されたため、Cloudflare のフォワードプロキシ経由でのアクセスと確認できます。
ウェブサーバーから見たときのソース IP は 10.146.0.12 となりますが、これはコネクタサーバーにおける cloudflared によって SNAT がおこなわれた形となり、想定した通りの結果です。

ログ（WARP）

gateway-dns-log.json

{
  "ApplicationID": 0,
  "ColoCode": "NRT",
  "ColoID": 382,
  "CustomResolveDurationMs": 18,
  "CustomResolverAddress": "10.146.0.10:53",
  "CustomResolverPolicyID": "f867d359-06ef-4fbb-99a6-587c91b7c94e",
  "CustomResolverPolicyName": "resolve-private.example.com 10.146.0.10",
  "CustomResolverResponse": "Success",
  "Datetime": "2024-05-26T15:07:52Z",
  "DeviceID": "05ebdb78-19ec-11ef-a2cc-a206d6485a19",
  "DeviceName": "xxxxx",
  "DstIP": "162.159.36.1",
  "DstPort": 443,
  "Email": "non_identity@xxxxx.cloudflareaccess.com",
  "IsResponseCached": false,
  "Location": "Nuro",
  "LocationID": "76c7ca27-5d1c-4c1b-a3b3-e841a538921f",
  "MatchedCategoryIDs": [],
  "MatchedCategoryNames": [],
  "MatchedIndicatorFeedIDs": [],
  "MatchedIndicatorFeedNames": [],
  "Policy": "",
  "PolicyID": "",
  "Protocol": "https",
  "QueryCategoryIDs": [],
  "QueryCategoryNames": [],
  "QueryIndicatorFeedIDs": [],
  "QueryIndicatorFeedNames": [],
  "QueryName": "resolve-private.example.com",
  "QueryNameReversed": "com.example.resolve-private",
  "QuerySize": 60,
  "QueryType": 1,
  "QueryTypeName": "A",
  "RCode": 0,
  "RData": [
    {
      "type": "1",
      "data": "D3Jlc29sdmUtcHJpdmF0ZQdraGF5YW1hB2NvbXBhbnkAAAEAAQAADhAABAqSAAs="
    }
  ],
  "ResolvedIPs": [
    "10.146.0.11"
  ],
  "ResolverDecision": "allowedOnNoPolicyMatch",
  "SrcIP": "x.x.x.x",
  "SrcPort": 0,
  "TimeZone": "",
  "TimeZoneInferredMethod": "noScheduleConfigured",
  "UserID": "b7761faf-27e6-4d08-a35a-802db584b739"
}

動作確認（Clientless Web Isolation）

Clientless Web Isolation 経由でも同様の動作を確認できます。

これによりエージェント不要で社内ウェブアプリへのアクセスが可能になります。

ログ（Clientless Web Isolation）

DstIP や SrcIP が WARP アクセスとは異なって見えることがわかります。

gateway-dns-log.json

{
  "ApplicationID": 0,
  "ColoCode": "NRT",
  "ColoID": 22,
  "CustomResolveDurationMs": 21,
  "CustomResolverAddress": "10.146.0.10:53",
  "CustomResolverPolicyID": "f867d359-06ef-4fbb-99a6-587c91b7c94e",
  "CustomResolverPolicyName": "resolve-private.example.com 10.146.0.10",
  "CustomResolverResponse": "Success",
  "Datetime": "2024-05-26T15:46:29Z",
  "DeviceID": "00000000-0000-0000-0000-000000000000",
  "DeviceName": "",
  "DstIP": "",
  "DstPort": 443,
  "Email": "user1@example.com",
  "IsResponseCached": false,
  "Location": "Nuro",
  "LocationID": "76c7ca27-5d1c-4c1b-a3b3-e841a538921f",
  "MatchedCategoryIDs": [],
  "MatchedCategoryNames": [],
  "MatchedIndicatorFeedIDs": [],
  "MatchedIndicatorFeedNames": [],
  "Policy": "",
  "PolicyID": "",
  "Protocol": "https",
  "QueryCategoryIDs": [],
  "QueryCategoryNames": [],
  "QueryIndicatorFeedIDs": [],
  "QueryIndicatorFeedNames": [],
  "QueryName": "resolve-private.example.com",
  "QueryNameReversed": "com.example.resolve-private",
  "QuerySize": 60,
  "QueryType": 1,
  "QueryTypeName": "A",
  "RCode": 0,
  "RData": [
    {
      "type": "1",
      "data": "D3Jlc29sdmUtcHJpdmF0ZQdraGF5YW1hB2NvbXBhbnkAAAEAAQAADhAABAqSAAs="
    }
  ],
  "ResolvedIPs": [
    "10.146.0.11"
  ],
  "ResolverDecision": "allowedOnNoPolicyMatch",
  "SrcIP": "0.0.0.0",
  "SrcPort": 0,
  "TimeZone": "",
  "TimeZoneInferredMethod": "noScheduleConfigured",
  "UserID": "4b79fcad-0452-41be-99c0-73f777b31a6f"
}

Gateway activity logs

以下の画面からもログを確認できます。

まとめ

今後は Private DNS を使う場合には Resolver Policies が推奨となりそうです。

どうしてもローカル端末からでしかアクセスできないようなドメインに関してのみ、Local Domain Fallback を使う、といった住み分けになりそうです。

構成さえ理解すれば、技術的には特に難しくないかなと思うのでぜひ使ってみてください。

参考：DNS ポリシーの評価

参考リンク

/etc/hosts が反映されない？安心してください。反映されてますよ。 #Yosemite - Qiita
Firefox ブラウザツール
- about:networking#dnslookuptool
  - Firefox is ignoring Windows hosts file : r/firefox
- about:networking#dns
  - Firefox ignores /etc/hosts on Macos | Firefox Support Forum | Mozilla Support
- Firefox のキャッシュを消去するには | Firefox ヘルプ