--- title: "内部リソースへのアクセス トラブルシューティング" slug: "access-to-internal-resources-troubleshooting" updated: 2026-07-30T01:30:05Z published: 2026-07-30T01:30:05Z canonical: "knowledge.catonetworks.com/access-to-internal-resources-troubleshooting" --- > ## Documentation Index > Fetch the complete documentation index at: https://knowledge.catonetworks.com/llms.txt > Use this file to discover all available pages before exploring further. # 内部リソースへのアクセス トラブルシューティング ## 概要 ネットワークの生産性とセキュリティを維持するためには、内部リソースへのシームレスなアクセスを確保することが重要です。 しかし、さまざまな要因がアクセスを妨げ、ユーザーエクスペリエンスの低下やワークフローの妨害を引き起こす可能性があります。 このプレイブックは、Cato Cloud 内部リソースへの WAN アクセス問題のトラブルシューティングのための包括的なガイドを提供することを目的としています。 ## 症状 内部リソースへのアクセスの失敗は、いくつかの形で現れる可能性があります。 管理者は次の症状に注意を払うべきです： - 内部サーバー ドメイン名が解決できません - 内部サーバーに到達できません - WAN ファイアウォールルールの不一致 - SDP クライアントが内部リソースに到達できません - リモートポートフォワード（RPF）リソースに到達できません - LAN モニタリングホストに到達できません ## 考えられる原因 - ルーティングの問題 - DNS フォワーディングの誤設定 - WAN ファイアウォールの誤設定 - SDP クライアントのネットワークとの重複 - セキュリティ介入 - 宛先ホストの接続性の問題 ## 初期評価 > [!NOTE] > 注： > > トラブルシューティング目的で一時的に作成されても、**イベントトラッキングが有効**になっている WAN ファイアウォールルールがあることを確認してください。 > > ブラウザ アクセス経由でサーバーに到達する問題については、[ブラウザ アクセスの問題のトラブルシューティング](/v1/docs/browser-access-portal-troubleshooting)をご覧ください CMAでそれぞれのプリセットを選択して、WAN ファイアウォール、IPS、およびマルウェアイベントを確認してください。 フィルターを設定して興味のあるトラフィックを絞り込み、フローが WAN ファイアウォールまたは IPS/AM エンジンによってブロックされたかどうかを確認します。 **ルール** フィールドにはトラフィックと一致するルールが表示されます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17173684051613.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A30%3A57Z&se=2026-11-10T17%3A30%3A57Z&sr=c&sp=r&sig=Dr8W%2BbHUY%2BJNahYXdOalKdtTpRjZpCe17lhUPq0J1z0%3D) 次の初期評価手順に従って、適切なトラブルシューティングセクションを確認してください： - *nslookup* または *dig* コマンドをコマンドラインから実行して、サーバードメイン名が解決できるかどうか確認してください。 DNS 応答が得られない場合は、[サーバードメイン名解決問題のトラブルシューティング](/v1/docs/access-to-internal-resources-troubleshooting#troubleshooting-server-domain-name-resolution-issues) に移動します - サーバーの IP アドレスに到達できるかどうか、*ping* コマンドを実行して確認してください。 このテストを実行する前に、ICMP が WAN ファイアウォールルールで許可されていることを確認してください。 ping の応答がない場合は、[到達不能な内部サーバーのトラブルシューティング](/v1/docs/access-to-internal-resources-troubleshooting#troubleshooting-unreachable-internal-server) に移動します - IPS またはマルウェアイベントがこれらのエンジンのいずれかが内部サーバーへのアクセスをブロックしていることを示している場合は、[偽陽性の IPS/マルウェアブロックを解決](/v1/docs/access-to-internal-resources-troubleshooting#resolving-false-positive-ipsantimalware-blocks)してください - WAN ファイアウォールイベントで一致するルールが予想されるものかを確認してください。 予想されていない場合は、[ファイアウォールルールの不一致のトラブルシューティング](/v1/docs/access-to-internal-resources-troubleshooting#troubleshooting-wan-firewall-rule-mismatch) を続行します - SDP クライアントのみが影響を受け、サイト後ろのユーザーには影響がない場合、[SDPクライアントが内部リソースに到達していない場合のトラブルシューティング](/v1/docs/access-to-internal-resources-troubleshooting#troubleshooting-sdp-client-not-reaching-internal-resources) を参照してください - 影響を受けた内部リソースがリモートポートフォワード経由でアクセスされた場合、[RPF内部リソースのトラブルシューティング](/v1/docs/access-to-internal-resources-troubleshooting#troubleshooting-rpf-internal-resources)を参照してください - 影響を受けたサーバーが LAN 監視により監視されている場合、[到達不能な LAN モニタリングホストのトラブルシューティング](/v1/docs/access-to-internal-resources-troubleshooting#troubleshooting-rpf-internal-resources)をご確認ください ## 問題のトラブルシューティング 管理者が遭遇するかもしれない症状をトラブルシューティングするための手順は以下に列挙されています。 これらの手順は、直面する問題の可能性のある原因を特定することを目的としています。 解決手順は後のプレイブックで強調されます。 #### 監査ログの確認 [監査証跡](/v1/docs/using-the-audit-trail)を確認し、内部リソースへのアクセスに影響を与えた可能性のある**変更済み**ログがあるかどうかを確認してください。 これには、WANファイアウォールルール、AM/IPS 設定、および TLS 検査が含まれます。 ### サーバードメイン名解決問題のトラブルシューティング #### DNS 解決を確認 内部リソースがそのドメイン名を使って到達可能である場合、*nslookup*または*dig* コマンドを使用して内部サーバーのドメイン名が解決できるかを確認してください。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17229662328861.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A30%3A57Z&se=2026-11-10T17%3A30%3A57Z&sr=c&sp=r&sig=Dr8W%2BbHUY%2BJNahYXdOalKdtTpRjZpCe17lhUPq0J1z0%3D) アカウントでの内部 DNS 解決には、二つのシナリオがあります： - 組織でプライベートDNSサーバーのIP アドレスが使用されている場合、影響を受けたユーザーがDNSサーバーに内部で到達できるか確認してください。 できない場合、DNSサーバーへの接続性をトラブルシューティングし、[到達不能な内部サーバーのトラブルシューティング](/v1/docs/access-to-internal-resources-troubleshooting#troubleshooting-unreachable-internal-server)と類似しています - デフォルトの Cato DNS サーバー 10.254.254.1、アカウント定義の DNS サーバー、またはよく知られたパブリック DNS (8.8.8.8、1.1.1.1、または9.9.9.9) がアカウントで使用されている場合、次のステップで DNS フォワーディングをトラブルシューティングします。 #### DNS フォワーディングの確認 内部ドメイン名（例: *pc1.domain.net*）に依存するトラフィックフローには、CMAで[DNS フォワーディング](/v1/docs/defining-dns-forwarding-rules)が正しく設定されている必要があります。 Catoが DNS フローを傍受し、ドメイン名を正しく解決できるようにすることも重要です。 DNS フォワーディングは、DNS クエリが特定の DNS サーバを宛先とする場合のみ機能します。[DNS フォワーディング問題を解決](/v1/docs/access-to-internal-resources-troubleshooting#resolving-dns-forwarding-issues)する方法が説明されています。 ### 到達不能な内部サーバーのトラブルシューティング #### Cato ルーティング テーブルの確認 ルーティングテーブルはルートの可用性、メトリックなどを検証するために使用できます： - 探索文字列にリソースのIP アドレスを検索し、正しいサイトを経由する既存の一致するルートがあることを確認してください。 - ルートが見つからない場合、Catoはこのルートを認識しておらず、この宛先にルーティングできないことを意味します。 この問題の解決方法については、[ルーティング問題の解決](/v1/docs/access-to-internal-resources-troubleshooting#resolving-routing-issues)をご覧ください - 同じ宛先にルートがある場合、BGP 動的範囲が他の静的ルートと重複していないことを確認してください。 低いメトリックのルートが優先されます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17170685440925.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A30%3A57Z&se=2026-11-10T17%3A30%3A57Z&sr=c&sp=r&sig=Dr8W%2BbHUY%2BJNahYXdOalKdtTpRjZpCe17lhUPq0J1z0%3D) - BGP は異なるサイトから冗長なルートを広告することもあります。 重み、AS 長さ、または MED を含む低いメトリックのルートが優先されます。 [ルーティングテーブルフィールドの理解](/v1/docs/showing-the-routing-table-for-your-account)を参照してください。 - メトリック問題の解決方法については、[ルーティング問題の解決](/v1/docs/access-to-internal-resources-troubleshooting#resolving-routing-issues)をご覧ください #### IPSec ポリシーベースルーティングの確認 内部リソースが IPSec 経由で到達可能な場合は、[IPSEC トラブルシューティング プレイブック](https://support.catonetworks.com/knowledge/editor/01HMH6A9H1WFWKE88MRDP4AQWS/en-us?brand_id=1168669)に説明されているように、正しい範囲がサイトのIPSecとネットワークセクションに定義されていることを確認してください。 ポリシーベースのルーティングが設定されている場合、すべてのトラフィック セレクターは Cato と IPSec のファイアウォール/ルーターの両方で一致し、内部リソースへの接続が確保されている必要があります。 #### 内部リソースの生存性の確認 内部リソースがソケットやvSocketの背後にある場合、サイトの**既知のホスト**ページで最後のホスト アクティビティの値を確認してください。 [サイトの既知のホストを表示](/v1/docs/showing-known-hosts-for-a-site) ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17173713914525.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A30%3A57Z&se=2026-11-10T17%3A30%3A57Z&sr=c&sp=r&sig=Dr8W%2BbHUY%2BJNahYXdOalKdtTpRjZpCe17lhUPq0J1z0%3D) 最近サイトによって確認されていないホストは、電源がオフになっているかネットワークに接続されていない可能性があります。 WebUIから[パケット キャプチャー](/v1/docs/how-to-capture-traffic-on-a-socket)を実行して、LAN 内で考えられる問題を特定してください。 #### TLS フローの確認 興味のあるトラフィックが TLS であり、前の手順でトラフィックが許可されていることを確認しました。 トラフィック フローが Cato によって TLS 検査が行われているか確認してください。 これは、**TLS 検査**フィールドを 1 に設定した FW ルールで見つかることができます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17174181913117.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A30%3A57Z&se=2026-11-10T17%3A30%3A57Z&sr=c&sp=r&sig=Dr8W%2BbHUY%2BJNahYXdOalKdtTpRjZpCe17lhUPq0J1z0%3D) その場合、Cato ルート証明書を、アカウントに設定された[TLS 検査ポリシーの設定](/v1/docs/configuring-tls-inspection-policy-for-the-account)をしたように、送信元デバイスにインストールする必要があります。 そうでない場合、TLS 検査をバイパスして、証明書エラーやリソースへのアクセス問題を防止してください。 ### WAN ファイアウォール ルールの不一致のトラブルシューティング ファイアウォールルールを設定する際に、トラフィックが誤ったルールと照合される可能性があります。 このセクションでは、すべての可能な不一致シナリオと、この問題をトラブルシューティングする方法について説明します。 #### カスタムアプリの確認 興味のあるトラフィックがカスタムアプリと一致することが期待され、FW イベントで見つかった**アプリケーション**フィールドがこれと一致しない場合、カスタムアプリが正しく設定されていることを確認してください。 カスタムアプリが重複する場合、Catoは**カスタムアプリの1つだけを**トラフィックとして認識することを覚えておいてください。 この問題を防ぐためには、[重なり合うカスタムアプリケーションの解決](/v1/docs/access-to-internal-resources-troubleshooting#resolving-overlapping-custom-application)をご覧ください。 #### 組み込みのアプリケーション/サービスの確認 興味のあるトラフィックが組み込みのアプリケーションまたはサービスと一致することが期待され、トラフィックが誤ったファイアウォールルールと一致する場合は、次を確認してください： - 『誤った』一致するファイアウォールルールにどのアプリケーションやサービスが設定されているか。 - これらのアプリケーション/サービスのいずれかが、FW イベントの **関連アプリ** フィールドに一覧されているかどうか。 アプリ/サービスの識別は、プロトコルを識別することから始まり、**関連アプリ** フィールドに含まれるすべての可能な一致可能アプリケーションの特定から始まる複数ステップのプロセスです。 フロー内で識別された '関連アプリ' アプリケーションは、**アプリケーション** フィールドの最終アプリとは関係なくファイアウォールルールと一致します。 次の例では、SMB トラフィックがルール #1 と一致し、ルール #2 ではない。 これは、ルール #1 が最終アプリが *SMB* であるにもかかわらず、**関連アプリ** に含まれる *TCP* サービスを含んでいるためです。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17173713919133.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A30%3A57Z&se=2026-11-10T17%3A30%3A57Z&sr=c&sp=r&sig=Dr8W%2BbHUY%2BJNahYXdOalKdtTpRjZpCe17lhUPq0J1z0%3D)![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17227402106653.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A30%3A57Z&se=2026-11-10T17%3A30%3A57Z&sr=c&sp=r&sig=Dr8W%2BbHUY%2BJNahYXdOalKdtTpRjZpCe17lhUPq0J1z0%3D) この予想される動作を解決するには、[ファイアウォールルールの順序付け](/v1/docs/access-to-internal-resources-troubleshooting#firewall-rule-ordering)をご覧ください #### 設定されたドメイン名の確認 ファイアウォール ルールにドメインまたは FQDN オブジェクトが含まれている場合、FW イベントの **ドメイン名** フィールドに何があるか確認してください。 ファイアウォール ルール内のドメイン/FQDN オブジェクトは、このフィールドと同じでなければなりません。 **FQDN** は完全修飾ドメインの完全一致であることを念頭に置いてください。 例えば、FQDN *example.com* は*example.com.* のみと一致します。 一方、**ドメイン** はすべてのサブドメインと一致するトップレベル（TLD）またはセカンドレベルドメイン（SLD）です。 例えば、ドメイン*example.com* は www と一致します。*example.com* および *host.example.com*。 Cato が HTTP、TLS、または DNS フローから正しいドメイン名を決定できない場合がある可能性があります。 これらのタイプの問題を解決するには、[ドメイン名の不一致解決](/v1/docs/access-to-internal-resources-troubleshooting#resolving-domain-name-mismatching-issues) を参照してください ### SDP クライアントが内部リソースに到達しない場合のトラブルシューティング このセクションでは、SDP クライアントが内部リソースに到達しない場合の問題について説明します。 #### ユーザーの自宅ネットワークサブネットの重複の確認 SDP クライアントがサーバーを ping することを含めて、内部リソースに接続できない場合、ユーザーの自宅ネットワークと内部リソースがあるサイトに IP アドレスの重複がないか確認してください。 そうである場合、クライアントのルーティングテーブルはリモートCatoサイトの背後にある内部サーバーに接続しようとしたときにローカルNICを指し、それにより接続に失敗します。 IP範囲が192.168.0.0/24、192.168.1.0/24、または10.0.0.0/24のリモートサイトは、通常このIP範囲をデフォルトのDHCP設定として使用するホーム ワイヤレス ルーターのIP範囲と簡単に重なる可能性があります。 この問題を解決するには、[SDP クライアントがリモート WAN リソースに接続できない](/v1/docs/sdp-client-fails-to-connect-to-remote-wan-resources)の説明に従ってください。 #### macOS および iOS ユーザーが内部ドメインを解決できない [macOS Ventura および iOS ユーザーが Cato 経由で内部リソースに到達できない](/v1/docs/macos-ventura-and-ios-users-unable-to-reach-internal-resources-via-cato)として説明されているように、SDPクライアントがドメイン名を使用して内部リソースに接続できない場合でも、IP アドレスを使用してそれに到達できる場合、エンドポイントによって（HTTPS経由でのDNS）または（TLS経由でのDNS）が使用されているため、DNSフォワーディングが失敗している可能性があります。 Cato は現在、DoH/DoT をサポートしていません。 この問題を解決するには、[DNS フォワーディング問題の解決](/v1/docs/access-to-internal-resources-troubleshooting#resolving-dns-forwarding-issues)をご覧ください。 または、Cato DNS サーバー (10.254.254.1) を CMA デバイスで唯一の DNS サーバーとして定義できます。 #### Android ユーザーが内部ドメインを解決できない [Cato経由で内部リソースに到達できないAndroidデバイス](/v1/docs/android-devices-unable-to-reach-internal-resources-via-cato)で説明されているように、SDPクライアントがドメイン名を使用して内部リソースに接続できないが、IPアドレスを使用して到達できる場合、デバイスによって使用される**自動プライベートDNS**のために、DNSフォワーディングが失敗している可能性があります（デフォルトの動作）。 これは現在Catoではサポートされていません。 この問題を解決するには、[DNSフォワーディング問題の解決](/v1/docs/access-to-internal-resources-troubleshooting#resolving-dns-forwarding-issues)を参照してください。 あるいは、デバイス上でプライベートDNSを無効にすることもできます。 ### RPF内部リソースのトラブルシューティング #### RPFイベント分析 CMA の **RPF** プリセットを選択して RPF イベントを確認する イベントが生成されていることを確認し、外部Cato IPが利用可能であることを確認します。 宛先IPアドレスは、RPFルールで設定された外部パブリックIPであることに注意。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17229957627293.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A30%3A57Z&se=2026-11-10T17%3A30%3A57Z&sr=c&sp=r&sig=Dr8W%2BbHUY%2BJNahYXdOalKdtTpRjZpCe17lhUPq0J1z0%3D) > [!NOTE] > 注： > > 着信RPFイベントには、ユーザーによって開始されていない場合でも、**ユーザー表示名**が表示されることがあります。 これは**期待される動作**です。 Catoプラットフォームのイベントフィールドは、**トンネル**、**ホスト**、**ユーザーエージェント**のメタデータを取得し、トラフィックフローに基づいています。 したがって、ユーザーがソケットやトンネルの背後にあるデバイスにマッピングされている場合、インバウンドトラフィックでもその名前がイベントに表示される可能性があります。 これは、ファイアウォールやルーティングポリシーが（方向を意識して）トラフィックを解釈する方法とは異なりますが、**イベント相関**の通常の動作です。 #### ジオブロックイベント分析 内部サーバーの内部IPアドレスを宛先とするイベントを確認する。 ジオブロック制限によって内部サーバーへの接続が妨げられていないことを確認する。 そうである場合、[ジオ制限ポリシー](/v1/docs/configuring-ips-and-geo-restriction)を編集し、ソース国を許可する。 #### 内部リソースのアライブネスの確認 サイトの**既知のホスト**ページから**最後に確認されたアクティビティ**の値を確認する。 [サイトの既知のホストを表示する](/v1/docs/showing-known-hosts-for-a-site)を参照 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17173713914525.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A30%3A57Z&se=2026-11-10T17%3A30%3A57Z&sr=c&sp=r&sig=Dr8W%2BbHUY%2BJNahYXdOalKdtTpRjZpCe17lhUPq0J1z0%3D) 最近サイトで確認されていないホストがオフになっているか、ネットワークに接続されていない可能性があります。 WebUIから[パケットキャプチャ](/v1/docs/how-to-capture-traffic-on-a-socket)を実行し、LAN内の可能な問題を特定する。 ### 到達不能なLAN監視ホストのトラブルシューティング #### 接続イベント分析 CMAで**LANホスト到達不能**プリセットを選択して接続イベントを確認する 定義されたLANホストに到達できなくなるとホスト到達不能イベントが生成される。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17197290725021.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A30%3A57Z&se=2026-11-10T17%3A30%3A57Z&sr=c&sp=r&sig=Dr8W%2BbHUY%2BJNahYXdOalKdtTpRjZpCe17lhUPq0J1z0%3D) #### ローカルホスト到達可能性の確認 定義されたローカルホストが[ソケットWebUI](/v1/docs/accessing-the-socket-webui)からpingできることを確認する。 pingが成功した場合、次の内容を確認する： - [LAN監視](/v1/docs/configuring-lan-monitoring-for-a-site)プローブは10.254.254.1から送信されるICMPパケットであるため、監視ホストが応答するためにソケットLANゲートウェイへのルートがあることを確認することが重要です。 - デバイスがローカルファイアウォールを実行している場合、ICMPは10.254.254.1のIPアドレスから許可されなければなりません。 WebUIから[パケットキャプチャ](/v1/docs/how-to-capture-traffic-on-a-socket)を実行し、LAN内の可能な問題を特定する。 ## 発見された問題を解決する ### ルーティング問題の解決 ルーティングテーブルに内部リソースへのルートが見つからない場合、次の項目を確認し解決する： - BGPがサイトで構成されている場合、隣接ノードによってルートがアドバタイズされていることを確認。 [BGPステータスの表示](/v1/docs/configuring-bgp-neighbors-for-a-cato-socket)を参照。 ローカルルーターがアドバタイズしているBGPプレフィックスを確認し、Catoがそれを受信していることを確認することが重要です。 - BGPセッションがダウンしている場合、切断問題をトラブルシュートする。 [BGPセッションが切断されています](/v1/docs/xops-network-playbook-bgp-session-disconnected)を参照 - 範囲をホストしているサイトが利用可能であることを確認する。 [サイト接続性のトラブルシューティング](https://support.catonetworks.com/knowledge/editor/01HNCRM5BBJFDYEHPQNEHPY527/en-us?brand_id=1168669)を参照 ルーティングテーブルに表示されるルートメトリックが間違ったルーティング決定を引き起こしている場合、次の項目を確認し解決する： - トンネルメトリック値は通常Catoにより設定されます。 冗長ルートは、同じ種類のサイト例（IPSecまたはソケットサイト）から発信された場合、同じトンネルメトリックを持つべきです。 - CMAの**ネットワーク > サイト > サイト設定 > BGP**で重み値を構成することができます。 このページで設定されたメトリック値は、ルーティングテーブルに重みとして表示されます。 サイトのメトリックを変更することで、冗長ルートの間違ったルーティング決定を修正します。 - AS長およびメトリック識別メトリック値は、外部ルーターから受信されます。 必要に応じて、これらのデバイス上で修正される必要があります。 ### 偽陽性IPS/マルウェア対策ブロックの解決 興味のあるトラフィックがIPS/AMによってブロックされた場合、IPSとマルウェア対策設定の両方に関してスコープ**WAN**を持つ許可リストを追加できます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17174211153181.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A30%3A57Z&se=2026-11-10T17%3A30%3A57Z&sr=c&sp=r&sig=Dr8W%2BbHUY%2BJNahYXdOalKdtTpRjZpCe17lhUPq0J1z0%3D) ### 重複するカスタムアプリケーションの解決 カスタムアプリケーションに正しいIPアドレス、ドメイン、ポート、プロトコルが含まれていることを確認します。 カスタムアプリを識別するために選択されたロジックはないため、他のカスタムアプリと重複しないようにカスタムアプリを一意に定義する必要があります。 より詳細な情報は、[カスタムアプリケーションを使用する](/v1/docs/working-with-custom-apps)を参照 ### ファイアウォールルールの順序付け ファイアウォールルールは、その順序に従って評価されるため、一般的なルールの上により具体的なルールを定義することが重要です。 例として、カスタムアプリケーション、組み込みアプリケーション、ドメイン、FQDN、またはカスタムサービスを定義するファイアウォールルールをカテゴリ、カスタムカテゴリ、またはサービスを含むファイアウォールルールの上に配置する必要があります。 以下のスクリーンショットでは、ルール#1はtwitter.comのIP範囲を含むカスタムサービスを含み、アプリケーションカテゴリを含むルール#2の上に配置されています。 ルール#1はルール#2より具体的であるため、*twitter.com*宛のトラフィックにはより良い一致となります これにより、TCP加速も無効化され、ルール#1がシンプルなルールであることから、オフクラウドまたはAlt-WANルーティングの問題が解決されます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17173684058013.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A30%3A57Z&se=2026-11-10T17%3A30%3A57Z&sr=c&sp=r&sig=Dr8W%2BbHUY%2BJNahYXdOalKdtTpRjZpCe17lhUPq0J1z0%3D) ### ドメイン名の不一致問題の解決 ファイアウォールドメイン/FQDNに基づくルールの不一致問題は次の方法で解決されます： - プロトコルがHTTP/Sの場合、Catoは次のソースを使用して宛先ドメインを判断できます： - **HTTPホスト名ヘッダー**（TLSインスペクションが有効な場合） - TLSハンドシェイク中の**SNI**フィールド - **DNS解決**、ドメイン名がDNSクエリおよび応答から学習される場合 - ファイアウォールルールで指定されたドメインがこれらすべてのソースで一貫していることを確認することが重要です。 最も一致したドメイン名（上から下に評価）がファイアウォールイベントで**ドメイン名**として表示されることに注意。 - SSHやSMBなど、ドメインをプレーンテキストで送信しない他のプロトコルの場合、Catoは**DNSインターセプション**だけに頼ってトラフィックをドメインやFQDNと関連付けます。 プライベートDNSを使用する場合は、DNSクエリ/応答がCatoを通るようにする必要があるため、特に重要です。 [DNSおよびCatoアカウントのベストプラクティス](/v1/docs/best-practices-for-dns-and-your-cato-account)を参照 - DoH（DNS over HTTPS）およびDNS over TLSは、ドメイン名/アプリケーションの一致にはサポートされていないため、ファイアウォールルールでブロックし、DNSクエリをUDP/53に移行させる必要があります。 ### DNSフォワーディング問題の解決 DNSフォワーディングは以下のDNSサーバーに宛てたDNSクエリでのみ使用できます： - CatoのデフォルトDNSサーバー 10.254.254.1 - **ネットワーク > DNS設定**の下で構成されたアカウントレベルのDNSサーバー - 8.8.8.8、1.1.1.1、9.9.9.9などのよく知られたDNSサーバー。 よく知られたDNSサーバーのリストはPoP間で異なる場合があります。 例えば、中国とシドニー。 DoH（DNS over HTTPS）およびDNS over TLSはDNSフォワーディングにはサポートされていないため、ファイアウォールルールでブロックし、DNSクエリをUDP/53に移行させる必要があります。 このソリューションは、特にmacOS、iOS、およびAndroidのSDPクライアントに適用されます。 ![](https://cdn.document360.io/81d0367c-2b69-4ba8-b412-1c8f46ce677e/Images/Documentation/17176311655325.png?sv=2026-02-06&spr=https&st=2026-11-10T16%3A30%3A57Z&se=2026-11-10T17%3A30%3A57Z&sr=c&sp=r&sig=Dr8W%2BbHUY%2BJNahYXdOalKdtTpRjZpCe17lhUPq0J1z0%3D) ## Catoサポートへのケースの提出 上記のトラブルシューティング手順の結果と共に[サポートチケット](/v1/docs/submitting-a-support-ticket)を提出してください。 以下の情報をチケットに含めてください： - 経験した問題の詳細、およびユーザーへの総合的な影響。 - 関連するファイアウォールイベントとファイアウォールルール設定。 - 問題を再現して[サポートセルフサービス](/v1/docs/support-self-service-supportme-portal)を実行します。 ツールによって生成されたチケット番号を含める。 - SDPクライアントを使用してCatoに接続する影響を受けたユーザーがいる場合、[SDPクライアントを使用して問題を記録](/v1/docs/recording-issues-using-the-cato-client)してください