内部リソースへのアクセスのトラブルシューティング

概要

ネットワークでの生産性とセキュリティを維持するために、内部リソースへのシームレスなアクセスを確保することは重要です。 しかし、さまざまな要因がアクセスを妨げる可能性があり、ユーザーの体験を悪化させ、ワークフローが阻害されることに繋がります。 このプレイブックは、Cato Cloud内の内部リソースへのWANアクセスの問題をトラブルシューティングするための包括的なガイドを提供することを目的としています。

症状

内部リソースへのアクセスに失敗することは、いくつかの方法で現れる可能性があります。 管理者は次の症状に注目するかもしれません：

• 内部サーバーのドメイン名が解決できない
• 内部サーバーに到達できない
• WANファイアウォールルールの不一致
• SDPクライアントが内部リソースに到達できない
• リモートポートフォワーディング（RPF）リソースに到達できない
• LANモニタリングホストに到達できない

可能な原因

• ルーティングの問題
• DNSフォワーディングの誤設定
• WANファイアウォールの誤設定
• SDPクライアントのネットワークとの重複
• セキュリティ介入
• 宛先ホストの接続性の問題

初期評価

CMAで該当するプリセットを選択して、WANファイアウォール、IPS、およびアンチマルウェアイベントを確認します。 興味のあるトラフィックを絞り込み、WANファイアウォールまたはIPS/AMエンジンによってフローがブロックされたかどうかを確認するためにフィルターを設定します。 ルールフィールドには、トラフィックに一致する該当ルールが表示されます。

これらの初期評価手順に従って、適切なトラブルシューティングセクションを確認することを確認してください：

• コマンドラインからnslookupまたはdigコマンドを実行して、サーバーのドメイン名が解決可能かどうかを確認します。 DNS応答が受信されない場合は、サーバードメイン名解決の問題のトラブルシューティングに進みます
• pingコマンドを実行して、サーバーIPアドレスに到達できるかどうかを確認します。 このテストを実行する前に、WANファイアウォールルールでICMPが許可されていることを確認してください。 もしping応答が受信されない場合、アクセス不可能な内部サーバーのトラブルシューティングに進んでください
• もしIPSまたはアンチマルウェアイベントがいずれかのエンジンが内部サーバーへのアクセスをブロックしていることを示す場合、偽陽性のIPS/アンチマルウェアブロックを解決するに進んでください
• WANファイアウォールイベントで一致したルールが期待されるものであるか確認してください。 そうでない場合は、ファイアウォールルールの不一致のトラブルシューティングを続行してください
• もしSDPクライアントだけが影響を受けており、サイトの背後のユーザーが影響を受けていない場合、SDPクライアントが内部リソースに到達しない問題のトラブルシューティングに進んでください
• もし影響を受けた内部リソースがリモートポートフォワーディングを使用してアクセスされている場合、RPF内部リソースのトラブルシューティングに進んでください
• もし影響を受けたサーバーがLANモニタリングによって監視されている場合、アクセス不可能なLANモニタリングホストのトラブルシューティングを確認してください

問題のトラブルシューティング

管理者が遭遇する可能性のある症状をトラブルシューティングする手順を以下に示します。 これらの手順は直面している問題の可能性のある原因を特定することを目的としています。 解決手順は後ほどプレイブックで強調されます。

監査証跡ログの確認

監査証跡を確認して、内部リソースへのアクセスに影響を与えた可能性のある変更済みログがないか確認してください これにはWANファイアウォールのルール、AM/侵入防御システム設定、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ルールで見つかります。

その場合、TLSインスペクションポリシーの構成で説明されているように、Catoルート証明書をソースデバイスにインストールする必要があります。 それ以外の場合は、TLS検査をバイパスして、証明書エラーやリソースへの潜在的なアクセスの問題を防ぎます。

WANファイアウォールルールの不一致のトラブルシューティング

ファイアウォールルールを構成する際に、トラフィックが誤ったルールに対して評価される可能性があります。 このセクションでは、すべての可能な不一致シナリオとこの問題のトラブルシューティング方法をカバーします。

カスタムアプリケーションの確認

興味深いトラフィックがカスタムアプリケーションに一致することが期待され、FWイベントで見つかったアプリケーションフィールドが一致しない場合、カスタムアプリが正しく構成されていることを確認してください。 重複するカスタムアプリが存在する場合、Catoはのみトラフィックをカスタムアプリの1つとして識別することを心に留めてください。 

この問題を防ぐには、重複するカスタムアプリケーションの解決セクションを参照してください。

組み込みアプリケーション/サービスの確認

興味深いトラフィックが組み込みアプリケーションまたはサービスに一致すると期待され、トラフィックが誤ったファイアウォールルールに一致している場合は、次のことを確認してください：

• 「誤った」一致ファイアウォールルールに設定されているアプリケーションまたはサービスはどれですか。
• これらのアプリケーション/サービスのいずれかが関連アプリフィールドにリストされているかどうか。

アプリ/サービスの識別は、プロトコルを識別し、関連アプリフィールドに含まれるすべての可能な一致アプリケーションを特定することから始まる複数ステップのプロセスです。 フローで識別された任意の「関連アプリ」アプリケーションは、最終的なアプリ（アプリケーションフィールド）の決定に関係なく、ファイアウォールルールに一致します。

以下の例では、SMBトラフィックはルール#1ではなくルール#2に一致します。 これは、ルール#1がTCPサービス（関連アプリに含まれる）を含んでいるためです。最終的なアプリケーション（アプリケーションフィールド）はSMBです。

この期待される動作を解決するには、ファイアウォールルールの順序を参照してください

設定済みのドメイン名を確認する

ファイアウォールルールにドメインまたは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を指し示し、その結果、接続が失敗します。

リモートサイトは、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アドレスを使用して到達できる場合、エンドポイントでDoH（HTTPS経由のDNS）またはDoT（TLS経由のDNS）が使用されているため、DNSフォワードが失敗している可能性があります。 Catoは現在、DoH/DoTをサポートしていません。

この問題を解決するには、DNS フォワーディング問題を解決するを参照してください。 または、Cato DNSサーバー (10.254.254.1) をCMA内でエンドポイント向けの唯一のDNSサーバーとして定義することができます。

Androidユーザーが内部ドメインを解決できない

AndroidデバイスがCatoを介して内部リソースに到達できないで説明されているように、SDPクライアントがドメイン名を使用して内部リソースに接続できないが、IPアドレスを使用して到達できる場合、デバイスが使用する自動プライベートDNS（デフォルト動作）により、DoH/DoTがDNS解決のために強制されるため、DNSフォワードが失敗している可能性があります。 これには現在Catoのサポートがありません。

この問題を解決するには、DNS フォワーディング問題を解決するを参照してください。 または、デバイスでプライベートDNSを無効にすることができます。

RPF内部リソースのトラブルシューティング

RPFイベントの分析

CMAでRPFプリセットを選択してRPFイベントを確認します。 イベントが生成されていることを確認し、それにより外部Cato IPが利用可能であることを確認します。 宛先IPアドレスがRPFルールで設定された外部公開IPであることに注意してください。

ジオブロックイベント分析

内部サーバーの内部IPアドレスを宛先とするイベントを確認してください。 内部サーバーへの接続を妨げる地理的制限がないことを確認してください。 もしそうなら、地理的制限ポリシーを編集して発信元の国を許可してください。

内部リソースの生存確認

サイト上の既知のホストページから最終確認済み活動の値を確認してください。 サイトの既知のホストを表示を参照してください

サイトで最近確認できなかったホストは、電源がオフになっているか、ネットワークに接続されていない可能性があります。

WebUIからパケットキャプチャを実行し、LAN内の可能な問題を特定してください。

到達不能なLANモニタリングホストのトラブルシューティング

接続イベントの分析

CMAでLANホストに到達不能プリセットを選択して接続イベントを確認してください。定義されたLANホストにアクセスできなくなった場合、ホスト到達不能イベントが生成されます。

ローカルホストの到達可能性をチェックする

定義済みのローカルホストがソケットWebUIからpingできることを確認してください。 Pingが成功した場合、以下のことを確認してください：

• LANモニタリングのプローブは10.254.254.1からのICMPパケットであるため、監視対象のホストがソケットLANゲートウェイへの戻りルートを持っていることを確認することが重要です。
• デバイスがローカルファイアウォールを実行している場合、10.254.254.1のIPアドレスからのICMPを許可する必要があります。

WebUIからパケットキャプチャを実行し、LAN内の可能な問題を特定してください。

発見された問題の解決

ルーティング問題の解決

ルーティングテーブルに内部リソースへのルートが見つからない場合、以下の事項を確認し、解決してください：

• サイトにBGPが設定されている場合、隣接ノードがルートを広告していることを確認してください。 BGPステータスを見るを参照してください。 ローカルルーターが広告するBGPプレフィックスを確認し、Catoがそれを受け取っているか確認することが重要です。
• BGPセッションがダウンしている場合は、切断問題をトラブルシュートしてください。 BGPセッションが切断されました
• 範囲をホストしているサイトが利用可能であることを確認してください。 サイト接続性のトラブルシューティング

ルーティングテーブルで表示されるルートメトリックが誤ったルーティングを引き起こしている場合は、次を確認して解決してください：

• トンネルメトリック値は通常Catoによって設定されます。 冗長ルートは、IPSecまたはソケットサイトのような同じ種類のサイトから発信される限り、同一のトンネルメトリックを持っている必要があります。
• 重み値はCMAのネットワーク > サイト > サイト設定 > BGPで設定できます。 このページで設定したメトリック値は、ルーティングテーブルで重みとして表示されます。 サイトのメトリックを変更すると、冗長ルートの誤ったルーティング決定を修正できます。
• AS長とメトリック識別のメトリック値は、外部ルーターから受信されます。 必要に応じて、このデバイスでそれらを変更する必要があります。

偽陽性のIPS/アンチマルウェアブロックの解決

興味深いトラフィックがIPS/AMによってブロックされる場合、WANの範囲を用いてIPSとアンチマルウェアの設定に許可リストを追加できます。

重複するカスタムアプリケーションの解決

カスタムアプリケーションに正しいIPアドレス、ドメイン、ポート、およびプロトコルが含まれていることを確認してください。 識別のために選択されたカスタムアプリケーションに関する論理は存在しないため、他のカスタムアプリケーションとの重複を回避するために、カスタムアプリケーションは一意に定義される必要があります。 詳細については、カスタムアプリケーションの操作を参照してください

ファイアウォールルールの順序

ファイアウォールルールはその順序に沿って評価されるため、より一般的なルールの上に、より具体的なルールを定義することが重要です。 例として、カスタムアプリケーション、ビルトインアプリケーション、ドメイン、FQDN、またはカスタムサービスを定義するファイアウォールルールは、カテゴリ、カスタムカテゴリ、またはサービスを含むファイアウォールルールの上に置かれるべきです。

以下のスクリーンショットで、ルール1はtwitter.comのIP範囲を含むカスタムサービスを含み、アプリケーションカテゴリを含むルール2の上に配置されています。 ルール #1 はルール #2 よりも具体的で、twitter.com へのトラフィックにより適した一致となります。これにより、TCP 加速を無効にし、オフクラウドまたは Alt-WAN ルーティングの問題を解決します。ルール #1 はシンプルなルールです。

ドメイン名不一致の問題を解決する

ドメイン/FQDN を基にしたファイアウォールルールの一致問題は次のように解決できます：

• HTTPプロトコルなどのプロトコルの場合、Catoは以下のソースを使用して宛先ドメインを判断できます。

  • HTTPプロトコル ホスト名ヘッダー (TLSインスペクションが有効化されている場合)

  • TLSハンドシェイク中のSNI項目

  • DNS解決、ドメイン名がDNSクエリと対応から学習される場所

• ファイアウォールルールに指定されたドメインが、これらすべてのソースで一貫していることを確認することが重要です。 注意: ファイアウォールイベントでは、最も適合するドメイン名(上から下へ評価)のみがドメイン名として表示されます。 

• 他のプロトコル、例えば、SSHやSMBのように、ドメインをプレーンテキストで送信しない場合、CatoはトラフィックをドメインまたはFQDN の完全修飾ドメイン名に関連付けるためにDNSインターセプションのみに依存します。 プライベート 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 間で異なる場合があります。 例えば、中国とシドニーです。

DNS フォワーディングでは DoH (DNS over HTTPS) および DNS over TLS はサポートされていないため、ファイアウォールルールでブロックし、DNS クエリを UDP/53 に移動させる必要があります。 このソリューションは特に macOS、iOS、そして Android の SDP クライアントに適用されます。

Cato サポートへの案件の提出

上記のトラブルシューティング手順の結果を含めたサポートチケットを提出してください。 チケットには次の情報を含めてください：

• 経験した問題の詳細およびユーザーへの全体的な影響。
• 関連するファイアウォールイベントおよびファイアウォールルール構成。
• 問題を再現して、サポートセルフサービスを実行します。 ツールによって生成されたチケット番号を含めてください。
• 影響を受けたユーザーがSDPクライアントを使用してCatoに接続する場合、SDPクライアントを使用して問題を記録してください