プライベートネットワークのトラブルシューティング

Cloudflare One Client を実行しているエンドユーザーが、Cloudflare Tunnel 背後のプライベートネットワークへ接続できないときは、このトラブルシューティング手順に従います。

Cloudflare One Client の GUI には Connected と Your Internet is protected が表示されるはずです。

Cloudflare One Client が Disconnected のまま、または Connected と Disconnected を頻繁に切り替える場合は、WARP に接続できない を参照してください。

この手順は、ユーザーがプライベートホスト名（例: wiki.internal.local）でアプリケーションにアクセスする場合だけ必要です。

• プライベート DNS に カスタムリゾルバーポリシー を使っている場合は、Gateway DNS ログ（Insights > Logs > DNS query logs）を開き、そのホスト名への DNS クエリを検索します。

• プライベート DNS に Local Domain Fallback を使っている場合は、Gateway Network ログ（Insights > Logs > Network logs）を開き、DNS サーバー IP 宛てのポート 53 トラフィックを検索します。

関連する Gateway ログがない場合、WARP がプライベート DNS サーバーへクエリを転送できていません。リゾルバーポリシーまたは Local Domain Fallback の設定を確認し、WARP の DNS リクエスト処理 を参照してください。

次に、Gateway Network ログ（Insights > Logs > Network logs）に、宛先 IP へのトラフィックがあるか確認します。

Cloudflare One Client は接続しているのにネットワークログがない場合、プライベートネットワーク IP が Cloudflare One Client 経由でルーティングされていません。デバイスの ルーティングテーブルを検索 し、アプリケーションの IP アドレスを確認すると確かめられます。アプリケーションへのトラフィックは、Cloudflare One Client インターフェイス経由になるはずです。別のインターフェイスが使われている場合は、Split Tunnel の設定を確認 します。

Gateway のブロックイベントがあったか確認します。

1. Insights > Logs を開き、DNS query logs、Network logs、または HTTP request logs を選びます。
2. 次のフィルターを適用します。
   • Email: ユーザーのメールアドレス
   • Event: Blocked
   • Date Time Range: ユーザーがアプリケーションにアクセスした期間

ユーザーがいずれかのポリシーに一致しているか、または想定より優先度の高いポリシーに一致しているかを確認します。

1. 実際に適用されたポリシーを特定します。
   1. Insights > Logs を開き、DNS query logs、Network logs、または HTTP request logs を選びます。
   2. 次のフィルターを適用します。
      • Email: ユーザーのメールアドレス
      • Date Time Range: ユーザーがアプリケーションにアクセスした期間
   3. 検索ボックスで、宛先 IP または FQDN で絞り込みます。
   4. 結果でログを選び、Policy Name の値を控えます。
2. Traffic policies > Firewall policies を開き、一致したポリシーと想定ポリシーの 適用順 を比較します。
3. Gateway ログの値と、想定ポリシーの条件を比較します。
   • 不一致が ID に関係する場合は、ユーザーレジストリを確認 し、IdP から Gateway へ渡される値を検証します。Cloudflare は、ユーザーが Cloudflare One Client に登録したときにレジストリを更新します。ユーザーの ID が古い場合は、クライアントを再認証するよう依頼します（Profile > Account information > Re-authenticate）¹。

• 不一致がデバイスポスチャに関係する場合は、そのユーザーデバイスの ポスチャチェック結果を確認 します。ポリシーで設定したポスチャチェックにデバイスが合格していることを確認します。

Traffic policies > Traffic settings で、TCP、UDP、ICMP トラフィックに対して Allow Secure Web Gateway to proxy traffic が有効であることを確認します。UDP は DNS トラフィックとその他の UDP パケットのプロキシに必要です。ICMP は ping などの管理機能に必要です。

トンネルのログストリームを確認 します。アプリケーションへのリクエストが見えない場合は、Cloudflare Tunnel に適切な静的ルートを追加していることを確認します。

cloudflared ホストマシンから、アプリケーションへ直接接続できることを確認します。

telnet test.example.com 443

PS C:\Users\JohnDoe> Test-NetConnection test.example.com -port 443

tcpdump や Wireshark などのパケットキャプチャツールを使い、ユーザーデバイスからのトラフィックが cloudflared に届き、アプリケーションへルーティングされているかも追跡できます。アプリケーションへのトラフィックの送信元 IP は、cloudflared ホストになります。

1. アプリケーションサーバーに、cloudflared ホストマシンからのリクエストをブロックするローカルファイアウォールがないか確認します。

2. アプリケーションサーバーが、ユーザーデバイスへ接続を開始する必要があるか確認します。必要な場合、これは cloudflared の制限です。双方向トラフィックを有効にするには、代わりに Cloudflare Mesh を導入 します。

TLS 検査 に問題がある場合、ユーザーはブラウザーでアプリケーションにアクセスすると Insecure Upstream エラーになります。ブラウザー以外からアクセスすると、エラーにならないことがほとんどです。

Logpush を有効にしているお客様は、Gateway HTTP データセット で、526 HTTP ステータスコードが多いホスト名を確認できます。

TLS 検査をトラブルシューティングします。

1. アプリケーションへのすべてのトラフィックで TLS 検査を無効にする、一時的な Gateway HTTP ポリシーを作成します。例:

   Selector	Operator	Value	Action
   Destination IP	in	10.2.3.4/32	Do Not Inspect

2. Do Not Inspect ポリシーでユーザーが接続できるようになった場合、アプリケーションが使う TLS 証明書が公開 CA に信頼されており、自己署名ではないことを確認します。Cloudflare Gateway は、自己署名証明書を使うアプリケーションと TLS をネゴシエートできません。詳細は TLS 検査の制限 を参照してください。

   回避策は次のとおりです。

   • オプション 1: このアプリケーション向けに恒久的な Do Not Inspect HTTP ポリシー を作成します。
   • オプション 2: 検査に 独自の証明書インフラ を使うお客様は、Allow Pass Through ポリシー を作成できます。プロキシがアプリケーションからの TLS ネゴシエーションを受け入れ、Do Not Inspect ポリシーなしでリクエストが流れます。
   • オプション 3: アプリケーションが HTTPS またはほかの一般的なプロトコルを使う場合は、Cloudflare Tunnel に 公開アプリケーション を追加し、noTLSVerify を true にします。これで cloudflared が自己署名証明書を信頼します。