概要
ネットワークの生産性とセキュリティを維持するためには、内部リソースへのシームレスなアクセスを確保することが重要です。 しかし、さまざまな要因がアクセスを妨げ、ユーザーエクスペリエンスの低下やワークフローの妨害を引き起こす可能性があります。 このプレイブックは、Cato Cloud 内部リソースへの WAN アクセス問題のトラブルシューティングのための包括的なガイドを提供することを目的としています。
症状
内部リソースへのアクセスの失敗は、いくつかの形で現れる可能性があります。 管理者は次の症状に注意を払うべきです：
内部サーバー ドメイン名が解決できません
内部サーバーに到達できません
WAN ファイアウォールルールの不一致
SDP クライアントが内部リソースに到達できません
リモートポートフォワード（RPF）リソースに到達できません
LAN モニタリングホストに到達できません
考えられる原因
ルーティングの問題
DNS フォワーディングの誤設定
WAN ファイアウォールの誤設定
SDP クライアントのネットワークとの重複
セキュリティ介入
宛先ホストの接続性の問題
初期評価
注：
トラブルシューティング目的で一時的に作成されても、イベントトラッキングが有効になっている WAN ファイアウォールルールがあることを確認してください。
ブラウザ アクセス経由でサーバーに到達する問題については、ブラウザ アクセスの問題のトラブルシューティングをご覧ください
CMAでそれぞれのプリセットを選択して、WAN ファイアウォール、IPS、およびマルウェアイベントを確認してください。 フィルターを設定して興味のあるトラフィックを絞り込み、フローが WAN ファイアウォールまたは IPS/AM エンジンによってブロックされたかどうかを確認します。 ルール フィールドにはトラフィックと一致するルールが表示されます。
次の初期評価手順に従って、適切なトラブルシューティングセクションを確認してください：
nslookup または dig コマンドをコマンドラインから実行して、サーバードメイン名が解決できるかどうか確認してください。 DNS 応答が得られない場合は、サーバードメイン名解決問題のトラブルシューティング に移動します
サーバーの IP アドレスに到達できるかどうか、ping コマンドを実行して確認してください。 このテストを実行する前に、ICMP が WAN ファイアウォールルールで許可されていることを確認してください。 ping の応答がない場合は、到達不能な内部サーバーのトラブルシューティング に移動します
IPS またはマルウェアイベントがこれらのエンジンのいずれかが内部サーバーへのアクセスをブロックしていることを示している場合は、偽陽性の IPS/マルウェアブロックを解決してください
WAN ファイアウォールイベントで一致するルールが予想されるものかを確認してください。 予想されていない場合は、ファイアウォールルールの不一致のトラブルシューティング を続行します
SDP クライアントのみが影響を受け、サイト後ろのユーザーには影響がない場合、SDPクライアントが内部リソースに到達していない場合のトラブルシューティング を参照してください
影響を受けた内部リソースがリモートポートフォワード経由でアクセスされた場合、RPF内部リソースのトラブルシューティングを参照してください
影響を受けたサーバーが LAN 監視により監視されている場合、到達不能な LAN モニタリングホストのトラブルシューティングをご確認ください
問題のトラブルシューティング
管理者が遭遇するかもしれない症状をトラブルシューティングするための手順は以下に列挙されています。 これらの手順は、直面する問題の可能性のある原因を特定することを目的としています。 解決手順は後のプレイブックで強調されます。
監査ログの確認
監査証跡を確認し、内部リソースへのアクセスに影響を与えた可能性のある変更済みログがあるかどうかを確認してください。 これには、WANファイアウォールルール、AM/IPS 設定、および TLS 検査が含まれます。
サーバードメイン名解決問題のトラブルシューティング
DNS 解決を確認
内部リソースがそのドメイン名を使って到達可能である場合、nslookupまたはdig コマンドを使用して内部サーバーのドメイン名が解決できるかを確認してください。
アカウントでの内部 DNS 解決には、二つのシナリオがあります：
組織でプライベートDNSサーバーのIP アドレスが使用されている場合、影響を受けたユーザーがDNSサーバーに内部で到達できるか確認してください。 できない場合、DNSサーバーへの接続性をトラブルシューティングし、到達不能な内部サーバーのトラブルシューティングと類似しています
デフォルトの 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 フォワーディングが正しく設定されている必要があります。 Catoが DNS フローを傍受し、ドメイン名を正しく解決できるようにすることも重要です。
DNS フォワーディングは、DNS クエリが特定の DNS サーバを宛先とする場合のみ機能します。DNS フォワーディング問題を解決する方法が説明されています。
到達不能な内部サーバーのトラブルシューティング
Cato ルーティング テーブルの確認
ルーティングテーブルはルートの可用性、メトリックなどを検証するために使用できます：
探索文字列にリソースのIP アドレスを検索し、正しいサイトを経由する既存の一致するルートがあることを確認してください。
ルートが見つからない場合、Catoはこのルートを認識しておらず、この宛先にルーティングできないことを意味します。 この問題の解決方法については、ルーティング問題の解決をご覧ください
同じ宛先にルートがある場合、BGP 動的範囲が他の静的ルートと重複していないことを確認してください。 低いメトリックのルートが優先されます。
BGP は異なるサイトから冗長なルートを広告することもあります。 重み、AS 長さ、または MED を含む低いメトリックのルートが優先されます。 ルーティングテーブルフィールドの理解を参照してください。
メトリック問題の解決方法については、ルーティング問題の解決をご覧ください
IPSec ポリシーベースルーティングの確認
内部リソースが IPSec 経由で到達可能な場合は、IPSEC トラブルシューティング プレイブックに説明されているように、正しい範囲がサイトのIPSecとネットワークセクションに定義されていることを確認してください。
ポリシーベースのルーティングが設定されている場合、すべてのトラフィック セレクターは Cato と IPSec のファイアウォール/ルーターの両方で一致し、内部リソースへの接続が確保されている必要があります。
内部リソースの生存性の確認
内部リソースがソケットやvSocketの背後にある場合、サイトの既知のホストページで最後のホスト アクティビティの値を確認してください。 サイトの既知のホストを表示
最近サイトによって確認されていないホストは、電源がオフになっているかネットワークに接続されていない可能性があります。
WebUIからパケット キャプチャーを実行して、LAN 内で考えられる問題を特定してください。
TLS フローの確認
興味のあるトラフィックが TLS であり、前の手順でトラフィックが許可されていることを確認しました。 トラフィック フローが Cato によって TLS 検査が行われているか確認してください。 これは、TLS 検査フィールドを 1 に設定した FW ルールで見つかることができます。
その場合、Cato ルート証明書を、アカウントに設定されたTLS 検査ポリシーの設定をしたように、送信元デバイスにインストールする必要があります。 そうでない場合、TLS 検査をバイパスして、証明書エラーやリソースへのアクセス問題を防止してください。
WAN ファイアウォール ルールの不一致のトラブルシューティング
ファイアウォールルールを設定する際に、トラフィックが誤ったルールと照合される可能性があります。 このセクションでは、すべての可能な不一致シナリオと、この問題をトラブルシューティングする方法について説明します。
カスタムアプリの確認
興味のあるトラフィックがカスタムアプリと一致することが期待され、FW イベントで見つかったアプリケーションフィールドがこれと一致しない場合、カスタムアプリが正しく設定されていることを確認してください。 カスタムアプリが重複する場合、Catoはカスタムアプリの1つだけをトラフィックとして認識することを覚えておいてください。
この問題を防ぐためには、重なり合うカスタムアプリケーションの解決をご覧ください。
組み込みのアプリケーション/サービスの確認
興味のあるトラフィックが組み込みのアプリケーションまたはサービスと一致することが期待され、トラフィックが誤ったファイアウォールルールと一致する場合は、次を確認してください：
『誤った』一致するファイアウォールルールにどのアプリケーションやサービスが設定されているか。
これらのアプリケーション/サービスのいずれかが、FW イベントの 関連アプリ フィールドに一覧されているかどうか。
アプリ/サービスの識別は、プロトコルを識別することから始まり、関連アプリ フィールドに含まれるすべての可能な一致可能アプリケーションの特定から始まる複数ステップのプロセスです。 フロー内で識別された '関連アプリ' アプリケーションは、アプリケーション フィールドの最終アプリとは関係なくファイアウォールルールと一致します。
次の例では、SMB トラフィックがルール #1 と一致し、ルール #2 ではない。 これは、ルール #1 が最終アプリが SMB であるにもかかわらず、関連アプリ に含まれる TCP サービスを含んでいるためです。
この予想される動作を解決するには、ファイアウォールルールの順序付けをご覧ください
設定されたドメイン名の確認
ファイアウォール ルールにドメインまたは FQDN オブジェクトが含まれている場合、FW イベントの ドメイン名 フィールドに何があるか確認してください。 ファイアウォール ルール内のドメイン/FQDN オブジェクトは、このフィールドと同じでなければなりません。
FQDN は完全修飾ドメインの完全一致であることを念頭に置いてください。 例えば、FQDN example.com はexample.com. のみと一致します。
一方、ドメイン はすべてのサブドメインと一致するトップレベル（TLD）またはセカンドレベルドメイン（SLD）です。 例えば、ドメインexample.com は www と一致します。example.com および host.example.com。
Cato が HTTP、TLS、または DNS フローから正しいドメイン名を決定できない場合がある可能性があります。 これらのタイプの問題を解決するには、ドメイン名の不一致解決 を参照してください
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 リソースに接続できないの説明に従ってください。
macOS および iOS ユーザーが内部ドメインを解決できない
macOS Ventura および iOS ユーザーが Cato 経由で内部リソースに到達できないとして説明されているように、SDPクライアントがドメイン名を使用して内部リソースに接続できない場合でも、IP アドレスを使用してそれに到達できる場合、エンドポイントによって
この問題を解決するには、DNS フォワーディング問題の解決をご覧ください。 または、Cato DNS サーバー (10.254.254.1) を CMA デバイスで唯一の DNS サーバーとして定義できます。
Android ユーザーが内部ドメインを解決できない
Cato経由で内部リソースに到達できないAndroidデバイスで説明されているように、SDPクライアントがドメイン名を使用して内部リソースに接続できないが、IPアドレスを使用して到達できる場合、デバイスによって使用される自動プライベートDNSのために、DNSフォワーディングが失敗している可能性があります（デフォルトの動作）。 これは現在Catoではサポートされていません。
この問題を解決するには、DNSフォワーディング問題の解決を参照してください。 あるいは、デバイス上でプライベートDNSを無効にすることもできます。
RPF内部リソースのトラブルシューティング
RPFイベント分析
CMA の RPF プリセットを選択して RPF イベントを確認する イベントが生成されていることを確認し、外部Cato IPが利用可能であることを確認します。 宛先IPアドレスは、RPFルールで設定された外部パブリックIPであることに注意。
注：
着信RPFイベントには、ユーザーによって開始されていない場合でも、ユーザー表示名が表示されることがあります。 これは期待される動作です。
Catoプラットフォームのイベントフィールドは、トンネル、ホスト、ユーザーエージェントのメタデータを取得し、トラフィックフローに基づいています。 したがって、ユーザーがソケットやトンネルの背後にあるデバイスにマッピングされている場合、インバウンドトラフィックでもその名前がイベントに表示される可能性があります。
これは、ファイアウォールやルーティングポリシーが（方向を意識して）トラフィックを解釈する方法とは異なりますが、イベント相関の通常の動作です。
ジオブロックイベント分析
内部サーバーの内部IPアドレスを宛先とするイベントを確認する。 ジオブロック制限によって内部サーバーへの接続が妨げられていないことを確認する。 そうである場合、ジオ制限ポリシーを編集し、ソース国を許可する。
内部リソースのアライブネスの確認
サイトの既知のホストページから最後に確認されたアクティビティの値を確認する。 サイトの既知のホストを表示するを参照
最近サイトで確認されていないホストがオフになっているか、ネットワークに接続されていない可能性があります。
WebUIからパケットキャプチャを実行し、LAN内の可能な問題を特定する。
到達不能なLAN監視ホストのトラブルシューティング
接続イベント分析
CMAでLANホスト到達不能プリセットを選択して接続イベントを確認する 定義されたLANホストに到達できなくなるとホスト到達不能イベントが生成される。
ローカルホスト到達可能性の確認
定義されたローカルホストがソケットWebUIからpingできることを確認する。 pingが成功した場合、次の内容を確認する：
LAN監視プローブは10.254.254.1から送信されるICMPパケットであるため、監視ホストが応答するためにソケットLANゲートウェイへのルートがあることを確認することが重要です。
デバイスがローカルファイアウォールを実行している場合、ICMPは10.254.254.1のIPアドレスから許可されなければなりません。
WebUIからパケットキャプチャを実行し、LAN内の可能な問題を特定する。
発見された問題を解決する
ルーティング問題の解決
ルーティングテーブルに内部リソースへのルートが見つからない場合、次の項目を確認し解決する：
BGPがサイトで構成されている場合、隣接ノードによってルートがアドバタイズされていることを確認。 BGPステータスの表示を参照。 ローカルルーターがアドバタイズしているBGPプレフィックスを確認し、Catoがそれを受信していることを確認することが重要です。
BGPセッションがダウンしている場合、切断問題をトラブルシュートする。 BGPセッションが切断されていますを参照
範囲をホストしているサイトが利用可能であることを確認する。 サイト接続性のトラブルシューティングを参照
ルーティングテーブルに表示されるルートメトリックが間違ったルーティング決定を引き起こしている場合、次の項目を確認し解決する：
トンネルメトリック値は通常Catoにより設定されます。 冗長ルートは、同じ種類のサイト例（IPSecまたはソケットサイト）から発信された場合、同じトンネルメトリックを持つべきです。
CMAのネットワーク > サイト > サイト設定 > BGPで重み値を構成することができます。 このページで設定されたメトリック値は、ルーティングテーブルに重みとして表示されます。 サイトのメトリックを変更することで、冗長ルートの間違ったルーティング決定を修正します。
AS長およびメトリック識別メトリック値は、外部ルーターから受信されます。 必要に応じて、これらのデバイス上で修正される必要があります。
偽陽性IPS/マルウェア対策ブロックの解決
興味のあるトラフィックがIPS/AMによってブロックされた場合、IPSとマルウェア対策設定の両方に関してスコープWANを持つ許可リストを追加できます。
重複するカスタムアプリケーションの解決
カスタムアプリケーションに正しいIPアドレス、ドメイン、ポート、プロトコルが含まれていることを確認します。 カスタムアプリを識別するために選択されたロジックはないため、他のカスタムアプリと重複しないようにカスタムアプリを一意に定義する必要があります。 より詳細な情報は、カスタムアプリケーションを使用するを参照
ファイアウォールルールの順序付け
ファイアウォールルールは、その順序に従って評価されるため、一般的なルールの上により具体的なルールを定義することが重要です。 例として、カスタムアプリケーション、組み込みアプリケーション、ドメイン、FQDN、またはカスタムサービスを定義するファイアウォールルールをカテゴリ、カスタムカテゴリ、またはサービスを含むファイアウォールルールの上に配置する必要があります。
以下のスクリーンショットでは、ルール#1はtwitter.comのIP範囲を含むカスタムサービスを含み、アプリケーションカテゴリを含むルール#2の上に配置されています。 ルール#1はルール#2より具体的であるため、twitter.com宛のトラフィックにはより良い一致となります これにより、TCP加速も無効化され、ルール#1がシンプルなルールであることから、オフクラウドまたはAlt-WANルーティングの問題が解決されます。
ドメイン名の不一致問題の解決
ファイアウォールドメイン/FQDNに基づくルールの不一致問題は次の方法で解決されます：
プロトコルがHTTP/Sの場合、Catoは次のソースを使用して宛先ドメインを判断できます：
HTTPホスト名ヘッダー（TLSインスペクションが有効な場合）
TLSハンドシェイク中のSNIフィールド
DNS解決、ドメイン名がDNSクエリおよび応答から学習される場合
ファイアウォールルールで指定されたドメインがこれらすべてのソースで一貫していることを確認することが重要です。 最も一致したドメイン名（上から下に評価）がファイアウォールイベントでドメイン名として表示されることに注意。
SSHやSMBなど、ドメインをプレーンテキストで送信しない他のプロトコルの場合、CatoはDNSインターセプションだけに頼ってトラフィックをドメインやFQDNと関連付けます。 プライベートDNSを使用する場合は、DNSクエリ/応答がCatoを通るようにする必要があるため、特に重要です。 DNSおよびCatoアカウントのベストプラクティスを参照
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クライアントに適用されます。
Catoサポートへのケースの提出
上記のトラブルシューティング手順の結果と共にサポートチケットを提出してください。 以下の情報をチケットに含めてください：
経験した問題の詳細、およびユーザーへの総合的な影響。
関連するファイアウォールイベントとファイアウォールルール設定。
問題を再現してサポートセルフサービスを実行します。 ツールによって生成されたチケット番号を含める。
SDPクライアントを使用してCatoに接続する影響を受けたユーザーがいる場合、SDPクライアントを使用して問題を記録してください