ネットワークルール評価トラブルシューティング

概要

正確なネットワークルール評価の確保は、情報に基づいたルーティング決定を行うために重要です。このトラブルシューティングガイドは、さまざまな一般的な症状を包括的に解決し、潜在的な原因を探り、ネットワークルール評価に関連する課題を解決する体系的な手順を提供することを目指します。

症状

ネットワークルールに対するトラフィックの評価失敗は、さまざまな形で現れる可能性があります。管理者は次の症状に気付くことがあります：

不正なパブリック送信元IP
ネットワークルール不一致
誤ったWANインタフェースが選択されました
TCPアクティブなアクセラレーションが適用されているかスキップされています
QoS優先度不一致
オフクラウドまたはアルタナティブWANがトラフィック接続を中断します

可能な原因

カスタムまたはビルトインアプリケーションの不一致
ドメイン不一致
誤った出力PoPが選ばれた
健康でないWAN接続
ブロックまたは未識別アプリが固定されたQoS優先度につながる
誤ったネットワークルール順序

初期評価

注意

注: トラブルシューティングのために一時的に作成された場合でも、トラッキング有効のファイアウォールルールを必ず作成して、設定済みのネットワークルールに一致すると期待されるトラフィックを含むようにしてください。

CMAでインターネットファイアウォールまたはWANファイアウォールプリセットを選択してファイアウォールイベントを確認します。興味のあるトラフィックを絞り込むフィルターを設定します。問題の可能性のある根本原因を特定するために役立つ関連アプリ、アプリケーション、フローで使用されているアプリケーション、出力PoP名、パブリック送信元IP、宛先IP、ドメイン名、ネットワークルール、およびTCPアクセラレーションのような関連分野を分析します。

ユーザーによって報告された症状を特定して、適切なトラブルシューティングセクションを確認することを確認してください：

ウェブアプリケーションはネットワークルールに構成されたものと異なる公共送信元IPアドレスを報告する可能性があります。ファイアウォールイベントの出力PoP名および公共送信元IPフィールドが期待されたものではない場合、不正な公共送信元IPのトラブルシューティングを参照してください
ファイアウォールイベントのネットワークルールフィールドが予想されるものであるか確認します。そうでない場合は、ネットワークルールの不一致トラブルシューティングを続行してください
トラフィックフローが設定されたプライマリWANリンクを使用していない場合、またはネットワークルールのプライマリトランスポートセクションで設定されたようにバランスが取れていない場合は、誤って選択されたWANインタフェースのトラブルシューティングを参照してください
ファイアウォールイベントのTCPアクセラレーションフィールドがネットワークルールで設定された期待される値ではない場合は、強制またはスキップされたTCPアクセラレーショントラブルシューティングを参照してください
トラフィックにファイアウォールイベントに従って誤ったQoS優先度255が割り当てられている場合は、QoS優先度の不一致トラブルシューティングを参照してください
ネットワークルールでトランスポートとしてオフクラウドまたはアルタナティブWANが選択されている場合にTLS接続が失敗する場合は、オフクラウドまたはAlt-WANがトラフィック接続を遮断するトラブルシューティングを参照してください

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

誤ったパブリック送信元IPのトラブルシューティング

イグレスルールの設定方法で説明されているように、制限付きインターネットサービスにアクセスするために特定の送信元パブリックIPを定義する必要がある場合があります。サービスが予期しない送信元パブリックIPを報告する場合は、以下の手順に従ってください。

複数のイグレスIPのレビュー

複数のイグレスIPアドレスを持つネットワークルールについては、Cato Cloudは地理的に送信元に最も近いPoPのイグレスIPアドレスを使用します。最初の出力IPアドレスが利用不可の場合、Cato Cloudは自動的に2番目の出力IPアドレスへの移行します。次のスクリーンショットは、2つのイグレスIPアドレスを持つネットワークルールの例を示しています。

この例では、ネットワークルールはニューヨークPoPまたはシカゴPoPからトラフィックをイグレスすることができます。送信元が物理的にニューヨークPoPに近い場合、CatoはニューヨークのPoPから特定のトラフィックをイグレスしようとします。ニューヨークPoPから目的地に到達できない場合、CatoはシカゴPoPからトラフィックをイグレスします。

この動作を変更するには、イグレスPoP選択の変更を参照してください。

利用不可のイグレスIP

ネットワークルールに単一の出力IPが含まれる場合、設定されているものとは異なるCatoのパブリックIPを使用してトラフィックが出力される可能性があります。このような場合、メンテナンスウィンドウ中に出力IPに関連付けられたPoPが一時的に利用不可能になることがあります。この状況は、特にVoIPアプリケーションにとって重大である可能性があります。

この動作を変更するには、Egress PoP Selection Changeを参照してください。

ネットワークルールの変更を確認

ネットワークルールが最近出力IPアドレスで編集された場合。新しく生成されたトラフィックフローのみが新しい出力IPを使用することを念頭に置いてください。既存のトラフィックフローは、フローが作成された時点で関連付けられた出力IPを保持します。

上記の動作は、SIPフローが長時間アクティブな状態を保つVoIPトラフィックで一般的です。この問題を解決するには、VoIP電話を再起動することで、新しいSIPフローの作成がトリガーされ、更新されたネットワークルールの出力IPに従ってルーティングされるようにします。

ネットワークルールの不一致のトラブルシューティング

ネットワークルールを設定する際、トラフィックが誤ったネットワークルールに対して評価される可能性があります。このセクションでは、すべての可能性のある不一致のシナリオとこの問題のトラブルシューティング方法について説明します。

ファイアウォールイベント分析

ファイアウォールイベントから、関連アプリケーション、アプリケーション、Cato アプリ、宛先IP、ドメイン名、およびネットワークルールなどの関連項目を特定します。この情報は、ネットワークルールの不一致の理由をトラブルシューティングするのに役立ちます。

ネットワークルールの例外を確認

ネットワークルールに追加された例外を特定します。トラフィックフローが追加された例外と一致する場合、ネットワークルールは無視され、ルールの見つけるまでルールベースの残り部分が継続されます。

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

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

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

ビルトインアプリケーションの確認

興味のあるトラフィックがビルトインアプリケーションに一致することを期待しており、トラフィックが誤ったネットワークルールに一致している場合、次を確認してください：

どのアプリケーションが「間違った」一致ネットワークルールに設定されていますか。
これらのアプリケーションのいずれかがファイアウォールイベントの関連アプリフィールドにリストされているかどうか。

アプリ識別は複数のステップからなるプロセスであり、プロトコルの識別から始まり、その後は関連アプリフィールドに含まれるすべての可能な一致アプリケーションを含みます。フロー内で識別された「関連アプリ」アプリケーションは、最終アプリ（アプリケーションフィールド）の決定に関係なく、ネットワークルールと一致します。

以下の例では、portal.azure.comへのアクセスは、ルール#7ではなくルール#8と一致します。これは、最終アプリケーション（アプリケーションフィールド）がAzure Front Doorであるにもかかわらず、ルール#7にMicrosoft Azureアプリケーション（関連アプリに含まれる）が含まれているためです。

この期待される動作を解決するには、ネットワークルールの順序付けを参照してください

ドメイン名の確認

ネットワークルールにドメインまたはFQDNオブジェクトが含まれている場合、ファイアウォールイベントのドメイン名フィールドが何かを確認してください。ネットワークルールのドメイン/FQDNオブジェクトはこのフィールドと同じでなければなりません。

FQDNは完全な修飾ドメイン名の正確な一致であることを忘れないでください。例えば、FQDN example.com は example.com. だけに一致します。

一方、ドメインは、すべてのサブドメインに一致するトップレベル（TLD）またはセカンドレベルドメイン（SLD）です。例えば、ドメインexample.comはwww.example.comとhost.example.comに一致します。

CatoがHTTP、TLS、またはDNSフローから正しいドメイン名を判断できない場合がある。このタイプの問題を解決するには、ドメイン名問題の解決を参照してください

選択された誤ったWANインターフェースのトラブルシューティング

このセクションでは、Catoがトランスポートとして選択され、アクティブ/アクティブの展開で両方のWANインターフェースが構成されているシナリオについて説明します。ポリシーベースのルーティングに関する詳細については、Catoがベストトランスポートまたはリンクを選択する方法を参照してください

注意

注意: ファイアウォールルールのISP名および送信元ISP IPフィールドは、トラフィックが使用するWANリンクを判断するための良い指標とは限りません。これは、トラフィックフローがそのライフタイム中に複数回トンネルを変更できるためです。

ネットワークルールトランスポート設定の確認

アクティブ/アクティブ配置を達成するためには、プライマリインタフェースの役割を自動に設定するか、以下のスクリーンショットに示されているように両方のプライマリおよびセカンダリインタフェースの役割を構成する必要があります。セカンダリインタフェースの役割をなしに設定すると、プライマリインタフェースが利用不可になった場合にトラフィックフェイルオーバーが発生しません。ソケットインタフェースを介したトラフィックのルーティングを参照してください

ネットワークアナリティクスの確認

平均スループットウィジェットでは、各WANリンクの平均帯域幅利用率が表示されます。これは、ネットワークルールが正しいWAN接続を選択しているか、トラフィックを適切にバランスさせていることを確認する指標として機能します。下のスクリーンショットでは、ネットワークルールがWAN2をプライマリトランスポートとして選択するように変更されています。

特にパケットロス、ジッター、距離に関してWANリンクのパフォーマンスをモニタリングすることが重要です。アクティブ/アクティブトラフィック分散で説明されているように、あるリンクが最小リンク品質のしきい値を満たしていない場合、健康でないと見なされ、トラフィック分散には選ばれません。たとえそのWANリンクがプライマリトランスポートとして選ばれていてもです。

ソケットWebUIの確認

ソケットがリンクを健康でないと考えているかどうかを確認する簡単な方法は、ソケットWebUIのモニタリングページをチェックすることです。レイテンシー、ジッター、またはパケットロスのメトリックが最低要件を満たしていない場合、不健康な値は赤でマークされます。

以下の例では、WAN1のレイテンシーが非常に高く、これによりソケットはリンクを健康でないと見なします。この問題はあなたのISPに話し合うべきです。

WANリンク設定の確認

すべてのアクティブ/アクティブリンクが健康であるなら、各WANリンクの帯域幅設定をCMAで確認してください。以下の例では、WAN1リンクは100 Mbpsの下り/上り帯域幅で構成され、WAN2リンクは20 Mbpsの下り/上りで構成されています。これにより、WAN1に100:20または5:1の比率で、双方の下りと上り方向により多くのトラフィックが送信されます。

TCPアクセラレーションの強制またはスキップのトラブルシューティング

Cato TCPアクセラレーションの説明で議論されているように、ネットワークルールでTCPアクセラレーションが有効にされると、WAN越しにTCP接続を加速できます。この機能は通常、特定のシナリオで強制され、たとえルール内のアクティブTCPアクセラレーションオプションがチェックオフされても、管理者は無効化できない場合があります。このセクションでは、これらのシナリオと、必要に応じて機能を無効にする方法について説明します。

TCPアクセラレーションが強制される場合

ネットワークルールで出力IPまたは出力ロケーションを使用する場合、TCPアクセラレーションが適用されます。これにより、PoPがプロキシとして機能するよう強制され、その結果、ルールに一致するすべてのトラフィックフローにTCPアクセラレーションが適用されます。ネットワークルール内のチェックボックスはグレーアウトされます。

次の場合、ネットワークルールでTCPアクセラレーションを無効にしても機能が無効になりません：

アカウントにTLSインスペクションが有効化されており、TLSバイパスされている場合でもすべてのTLSトラフィックにTCPアクセラレーションが有効になります。これは、PoPがトラフィックを検査し、悪意のあるファイルや脅威を検出するためにプロキシとして機能する必要があるためです。
TCPアクセラレーションが無効になっている一致するネットワークルールの上に、複雑なネットワークルールが存在します
TCPアクセラレーションが無効になっているネットワークルール自体が複雑です。

複雑なネットワークルール（NGルールとも呼ばれる）は、Socket自体が評価できないネットワークルールです。したがって、SocketはトラフィックをPoPに送信する必要があり、その結果、TCPアクセラレーションを有効にする正しいネットワークルールが選択されます。含むことができるのは: アプリケーション, アプリケーションカテゴリ, サービス, カスタムアプリケーション, またはドメイン/FQDNオブジェクト。

一方、簡単なルールにはSocketが評価でき、PoPの関与を必要としない以下のエンティティを含むことができます：

送信元/宛先フィールドには: サイト, IPアドレス, ネットワークインタフェース, IP範囲, またはすべて。
アプリ/カテゴリフィールドには: ポート範囲またはカスタムサービス。

TCPアクセラレーションがスキップされる場合

TCPアクセラレーションはTCPトラフィックにのみ適用されます。ネットワークルールで有効化されているか、前のセクションで説明したように強制されているが、CMAイベントのTCPアクセラレーションフィールドが0の場合、Cato Cloud上での非対称ルーティングによりトラフィックフローがオープンモードとして検出されている可能性があります

カトにおける非対称ルーティングで説明されているように、オープンモードはCato CloudがTCPフローの開始（3つのハンドシェイク）を認識していない接続モードであり、TCPアクセラレーションの適用を妨げます。オープンモードフローの作成の根本的な原因を特定するために、Catoサポートと協力して作業することをお勧めします。

TCPアクセラレーションの無効化

TCPアクセラレーションを無効にするには、ネットワークルールの順序付けに記載されているように、出力IPやロケーションを含まない単純なルールをネットワークルールベースの最上部に置くことができます。上記のように、トラフィックがTLSである場合は、アカウント全体のTLSインスペクションを無効化する必要があります。

QoS優先度の不一致のトラブルシューティング

フローがQoS優先度255に割り当てられるときで説明されているように、ネットワークルールで設定されたQoS優先度がFWイベントに示される優先度と異なる場合があります。

QoS優先度255はBW管理のデフォルトの優先度と見なされます。ネットワークルールの帯域幅の優先度設定に関わらず、フローがQoS優先度255に割り当てられる理由はいくつかあります:

Catoは各フローのネットワークプロファイルを評価し、特定のアプリケーションがまだ識別されていない場合にQoS優先度255が割り当てられます。
最初のパケット（フローが識別される前）はQoS優先度255に割り当てられます。
ブロックされたフローにはQoS優先度255が割り当てられます。

クラウド外またはAlt-WANの接続を破るトラフィック接続のトラブルシューティング

このセクションでは、WANネットワークルールが主要なトランスポートとしてオフクラウドまたはAlt-WANで設定されているときに、サイト間でTLS接続が確立されないシナリオについて説明します。この問題をトラブルシューティングするには、以下の手順に従ってください。

フロー分析

トラフィックが正しくクラウド外またはAlt-WANを経由してルーティングされると、このトラフィックがPoPを通過しないため、CMAでFWイベントが生成されることはありません。

トラフィックが成功裏にクラウド外またはAlt-WANを経由してルーティングされていることを確認する1つの方法は、ソケットWebUIのSDWANタブからです。アクティブなトラフィックフローを識別し、選択したNICの下で、関心のあるトラフィックのために選択されたトランスポートを確認します。期待されるトランスポートが選択されていない場合、オフクラウドまたはAlt-WANが正しく設定されていることを確認します。

ネットワークルールの順序の確認

クラウド外またはAlt-WANリンクでのTLS接続の失敗で説明されているように、トラフィックがTLSでTLS検査が有効な場合、ネットワークルールの順序は、クラウド外またはAlt-WANリンクでのトラフィックフローを確保するための重要な要素です。

トラフィックがヒットするネットワークルールが複雑なルールの下にある場合、ソケットはネットワークルールを評価してクラウド外またはAlt-WAN経由でパケットをルーティングできません。この予想される動作を解決するには、ネットワークルールの順序を参照してください

発見された問題の解決

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

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

ネットワークルールの順序

ネットワークルールはその順序に基づいて評価されるため、一般的なルールよりも先に特定のルールを定義することが重要です。例えば、カスタムアプリケーション、組み込みアプリケーション、ドメイン名、FQDN の完全修飾ドメイン名、またはカスタムサービスを定義するネットワークルールは、カテゴリ、カスタムカテゴリ、またはサービスを含むネットワークルールよりも上に配置する必要があります。

以下のスクリーンショットでは、ルール 1にはtwitter.comのためのIP範囲を含むカスタムサービスが含まれており、アプリケーションカテゴリが含まれるルール 2の上に配置されています。ルール 1はルール 2よりも特定のものであり、twitter.com.に向けられたトラフィックにより良く適合します。これによりTCPの無効化を伴い、オフクラウドやAlt-WANルーティングの問題がルール 1が単純なルールであることから解決されます。

ドメイン名の問題の解決

ドメイン名/FQDN の完全修飾ドメイン名に基づくネットワークルールの一致問題は次のように解決できます：

HTTP/Sのようなプロトコルの場合、Catoは次のソースを使用して宛先ドメインを判断できます。
- HTTPプロトコルホスト名ヘッダー （TLSインスペクションが有効な場合）
- TLSハンドシェイクの間のSNIフィールド
- DNS解決、ドメイン名はDNSクエリと応答から学習されます。
ネットワークルールに指定されたドメインが、これらすべてのソースで一貫していることを確認することが重要です。注意：最もよく一致するドメイン名（上から下まで評価）が、ファイアウォールイベントでドメイン名として表示されます。
SSHやSMBなどの他のプロトコルでは、ドメインをプレーンテキストで送信しないため、CatoはトラフィックをドメインまたはFQDNに関連付けるためにDNSインターセプションに専ら依存します。プライベートDNSを使用する際には特に重要です。DNSクエリ/応答がCatoを通過するようにする必要があります。 DNSおよびCatoアカウントのベストプラクティスを参照してください

出力PoPの選択変更

アカウントのすべての出力量ルールをソースに最も近い（デフォルトの動作）ではなく、宛先に最も近いPoPを介してルーティングしたい場合、Catoサポートにケースを掲げることでCato Networksサポートに連絡してください。

SIPプロトコルを使用して同じ出力IPを常に使用する必要のあるVoIPアプリケーションの場合、設定の詳細設定でSIPトラフィックの選択IPオプションを有効にします。

異なりVoIPプロトコルまたは他のアプリケーションが常に同じ出力IPを使用することを要求する場合、Catoサポートにケースを掲げることでCato Networksサポートに連絡してください。

Catoサポートへのケースの提出

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

経験した問題の詳細とユーザーへの全体的な影響。
関連するファイアウォールイベントとネットワークルールの設定。
問題を再現して、サポートセルフサービスを実行します。ツールによって生成されたチケット番号を含む。