ベストプラクティス
Cloudflare TunnelをZero Trust Web Accessに展開する際は、以下のベストプラクティスに従うことをお勧めします。
可用性の追加ポイントとして、ネットワーク内の別のホストマシンにcloudflaredレプリカを追加します。
アプリケーションの管理を容易にするために、アプリケーションを公開する際の公開ホスト名を標準化します。顧客が公開ホスト名を管理する方法のいくつかの例を以下に示します。
- 内部アプリケーション用に、主要な公開ウェブサイトのサブドメインを委任します（例：
tools.dev.customer.com）。 - 内部DNSインフラストラクチャが公開利用可能な場合、内部の主要DNSレコードをCloudflareに登録し、このドメインを公開ホスト名ルートに使用します。これにより、同一のプライベートおよびパブリックホスト名でアプリケーションを提示できます。
- 接続するツールの種類に基づいてホスト名を生成する内部ロジックを指定します。たとえば、プロダクションリソース専用に割り当てられたUS-Eastデータセンターにアプリケーションのセットがある場合、
tools.us-east.prod.ztproject.comのサブドメインを作成できます。
公開ホスト名ルートがHTTPSアプリケーションを提供する場合、証明書の不一致による接続問題を軽減するためにNo TLS Verifyを有効にすることをお勧めします。No TLS Verifyは、cloudflaredとオリジンサービス間のTLS検証を無効にし、cloudflaredはオリジンサービスが提供する任意の証明書を受け入れます。この設定は、ユーザーのブラウザとcloudflaredホスト間のトラフィックには影響を与えず、常に暗号化されます。
ターゲットアプリケーションがロードバランサーなどの背後にある場合、HTTP Host Headerをサービスホスト名に設定する必要があるかもしれません。オリジンサービスとcloudflaredの間のロードバランサーはトラブルシューティングが難しい場合があり、通常、リクエストヘッダーを追加することで、ロードバランサーがトラフィックを特定する方法に一致させることで問題を解決できます。
Cloudflareダッシュボードで通知を有効にすることで、トンネルの健康状態を監視します。
最新の機能とバグ修正を取得するために、cloudflaredを定期的に更新することをお勧めします。