WARP - 診断ログで Cloudflare WARP を理解する

こんにちは。Cloudflare の Jess です。

ようこそ。この動画は WARP のトラブルシューティングです。warp-diag の読み方を

学びます。発展回なので、なじみのない概念が出てきた場合は、

WARP の基本編もあります。そちらで前提を確認できます。

いつものとおり、サポートチームも対応します。

この動画で扱う内容は次のとおりです。

warp-diag ファイルとは何か。

warp-diag ファイルのダウンロードと操作方法、

warp-status ファイル、warp-settings ファイル、daemon.log ファイル、

そして分析の補足ヒントです。

始めましょう。warp-diagファイルとは何でしょうか。

デバイスの接続状態に関する重要な情報が入っています。

設定と WARP のログです。

問題のトラブルシューティングでは、まず見るべきファイルです。

各ファイルの役割は異なり、含まれる情報も決まっています。

warp-diag の実行時に作られるログと出力の組み合わせです。

WARP のファイルはどこにあるのでしょうか。

WARP をインストールすると、warp-diag というコマンドラインツールも

入ります。ターミナルで warp-diagを実行するだけで、zip

ファイルが生成され、ユーザーのデスクトップに置かれます。

warp-diag を実行するたびに、新しいログ一式が生成されます。

では、warp-diag が出力したファイルを展開し、中身を

テキストエディターで開きます。ここでは VS Codeを使いますが、ほかのエディターでも問題ありません。

この動画では、初期のトラブルシューティングに特に役立つ

そして daemon.log です。各ファイルを順に説明し、トラブルシューティングに

役立つ理由をお伝えします。

まず warp-status を見てみましょう。

このファイルはわかりやすいです。

warp-diag 実行時点のクライアント状態が入っています。

接続状態は、よく使うコマンドラインツールの出力を分析するときに

役立ちます。たとえばインターフェース一覧、

ルーティングテーブルの表示、現在の DNS 設定です。

以上です。次は warp-settingsです。

このファイルには、デバイスに現在適用されている設定がすべて入っています。

モードやデバイスプロファイルなどです。

ダッシュボードで行った設定が、実際にローカルへ

適用されているかを確認できます。

想定外の値がないか、このファイルは必ず確認します。

たとえば、トラブルシューティング対象のユーザーが特定の

デバイスプロファイル（office users など）を使う想定で、社内ネットワークに

接続しているとします。まずwarp-settings に正しい

プロファイル ID があるか確認します。プロファイル ID が想定どおりでなければ、

Cloudflare のデバイスプロファイル設定で定義したルールに、

そのユーザーが一致していない可能性があります。

また、デバイスプロファイル設定を変更した場合は、

このファイルで、ユーザーにその更新が届いているかを確認できます。

たとえば、デバイスプロファイルのトンネリング方式を MASQUE に変更し、

WireGuard の代わりにしたとします。ユーザーがその更新を受け取り、

実際に MASQUE で接続しようとしているかを確認できます。

daemon.log はかなり詳細で、WARP で起きていることがすべて入ります。

デバッグログなどです。

ファイルを開く前に、WARP の daemon とは何かを確認します。

WARP のバックグラウンドプロセスで、OS によっては service

とも呼ばれます。

WARP をインストールすると、daemon（バックグラウンドプロセス）と

GUI の両方が入ります。GUI は、ここで見えているインターフェースです。

GUI、warp-diag、warp-cli は、いずれも daemon と通信できます。

daemon.log は複数あり、名前は時系列です。

ではファイルを見ていきます。

様子を確認します。WARP が起動すると、バージョン情報を出力します。

そこから始めます。次の文字列を検索します。「warp_service:

Version:」です。いちばん新しいエントリを探します。

それが現在のセッションです。

warp-diag は継続的に改善されているため、この動画で紹介した文字列は

将来、少し変わる可能性があります。

登録情報には、WARP クライアントの接続に必要な情報がすべて含まれ、

マシン上に安全に保存されます。

GUI が登録情報の欠落を検出すると、設定によっては取得を

試みます。そうでなければ、missing registration と表示します。

登録情報が読み込まれると、WARP は接続を試みます。

ただし、自動接続が設定されている場合のみです。

そうでなければ、以前接続していた場合にのみ接続を試みます。

登録のあと、WARP は API 経由でデバイスプロファイルをリモート取得します。

使うデバイス設定とモードが含まれます。

重要な点として、デバイスプロファイルはローカルの設定ファイルでも

上書きされます。MDM プロバイダーが使うファイルです。

Intune や Kandji などです。

Cloudflare の MDM 設定の詳細は、

ドキュメントを参照してください。

この時点で、どのコンポーネントが接続するかはモードで決まります。

モードに Tunnel コンポーネントが含まれる場合、たとえば Secure Web Gateway without DNS

filtering では、「Initiate WARP」が出ます。モードに DNS コンポーネントが含まれる場合、

たとえば Gateway with DoH では、「Initiate DNS」が出ます。

両方を含む Gateway with WARP では、最終的に両方が出ます。

それぞれ見ていきましょう。

まず Initiate WARP です。Tunnelコンポーネントを含むモード向けです。

Tunnel コンポーネントにはファイアウォールが含まれます。

まずファイアウォールでトンネルのエンドポイントを許可し、接続を

エンドユーザーができるだけ早くつながるようにするためです。

この処理を Happy Eyeballs と呼びます。

接続後、ネットワークインターフェースが作られ、ルーティングテーブルと

ファイアウォールの更新が始まります。スプリットトンネルの exclude または include

エントリに従います。エントリはドメインまたは IP です。

IP については、WARP はすぐにルーティングテーブルを更新します。

ドメインについては DNS 解決に依存し、解決が終わってから

ルーティングテーブルを更新します。

トンネル内とトンネル外です。

次は Initiate DNS です。DNSコンポーネントを含むモード向けです。

DNS では、WARP 自身をシステムの既定 DNS プロバイダーに設定し、

すべての DNS リクエストを DNS over HTTPS（DoH）で Cloudflare へ転送します。

そのために、次の手順がすべて成功する必要があります。

まず、DoH エンドポイントへの接続を試みます。

次に、その DoH エンドポイントからDNS 応答を受け取ります。

接続チェックを行います。これはエンドツーエンドのテストで、WARP が DNS リクエストを

正しく受け取り、解決のためにCloudflare へ転送し、

有効な応答を受け取っていることを確認します。

トラブルシューティングを楽にする補足のヒントです。

テキストエディターの検索機能で、次のような語句をすばやく探します。

error、DNS、disconnected です。

同じエントリの繰り返しなど、パターンにも注目します。

特定の問題を示すことがあります。

最後に、warp-settings、

warp-status、daemon.log を突き合わせると、全体像が見えてきます。

たとえば warp-status がdisconnected の場合、

daemon.log でエラー詳細を、warp-settings で設定ミスを確認します。

問題によっては、より具体的な情報が入った別ファイルもあります。

warp-diag は継続的に改善されているため、将来さらにファイルが増える可能性があります。

どのファイルに何が入るかの最新情報は、

トラブルシューティングガイドを参照してください。これで warp-diag の基本は理解できました。

この手順を試しても問題が続く場合は、

遠慮なくサポートチームへご連絡ください。

いつでも対応します。

ご視聴ありがとうございました。またお会いしましょう。