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

概観

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

症状

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

不正なパブリック送信元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アプリケーションにとって重大である可能性があります。

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

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

ネットワークルールが最近出力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トラフィックにのみ適用されます。ネットワークルールでTCP加速が有効であり、前のセクションで説明されているように強制されている場合、しかしCMAイベントでTCP加速フィールドが0の時、Catoクラウド上で非対称ルーティングが発生し、トラフィックフローがオープンモードとして検出された可能性があります

Catoクラウド上の非対称ルーティングで説明されているように、オープンモードはTCPフローの開始時（3ウェイハンドシェイク）をCatoクラウドが認識していない接続モードであり、そのためTCP加速が適用されません。オープンモードフローの生成の根本原因を特定するために、Catoサポートと協力することをお勧めします。

TCP加速を無効化する

TCP加速を無効にするためには、Egress IPまたはロケーションを含まない単純なルールをネットワークルールベースの最上部に配置することができます。詳細はネットワークルールの注文を参照してください。上述したように、トラフィックがTLSの場合、TLSインスペクションはアカウント全体で無効化されなければなりません。

QoS優先度のミスマッチをトラブルシューティングするため

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

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

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

オフクラウドまたはアルトWANでトラフィック接続が断続する問題のトラブルシューティング

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

フロー分析

トラフィックが正しくオフクラウドまたはアルトWAN経由でルーティングされている場合、それらのトラフィックフローはCMAでFWイベントを生成しません。なぜならこのトラフィックはPoPを通過しないからです。

オフクラウドまたはアルトWAN経由でトラフィックが成功裏にルーティングされていることを確認する方法のひとつは、Socket WebUIのSDWANタブから確認することです。アクティブなトラフィックフローを識別し、選択されたNICの下で興味のあるトラフィックのための選択されたトランスポートが表示されます。予想されるトランスポートが選択されていない場合、オフクラウドまたはアルトWANが正しく設定されていることを確認してください。

ネットワークルールの注文の確認

オフクラウドまたはアルトWANリンク上のTLS接続失敗で説明されているように、トラフィックがTLSであってTLSインスペクションが有効になっている場合、ネットワークルールの注文がオフクラウドまたはアルトWANリンクを介してトラフィックフローを確保するための重要な要素です。

ネットワークルールが複雑なルールの下にあるとき、ソケットはネットワークルールを評価し、パケットをオフクラウドまたはアルトWAN経由でルートすることができません。この予想される動作を解決するには、ネットワークルール注文を参照してください

見つかった問題の解決

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

カスタムアプリケーションには正しいIPアドレス、ドメイン、ポート、プロトコルを含めることを確認してください。識別のために選ばれるカスタムアプリには論理がないため、カスタムアプリは他のカスタムアプリとの重複を避けるために、ユニークに定義されなければなりません。詳細はカスタムアプリケーションの使用を参照してください

ネットワークルールの注文

ネットワークルールはその順序に従って評価されることを念頭に置いてください。そのため、より一般的なルールの上により詳細なルールを定義することが重要です。例えば、カスタムアプリケーション、ビルトインアプリケーション、ドメイン、FQDN、カスタムサービスを定義するネットワークルールは、カテゴリ、カスタムカテゴリ、またはサービスを含むネットワークルールの上に配置する必要があります。

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

ドメイン名の問題の解決

ドメイン/FQDNに基づくネットワークルールの一致問題は、以下のように解決できます：

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

Egress PoP選択の変更

アカウントのすべてのEgressルールを宛先に最も近いPoP（標準の動作では送信元に近いPoPではなく）経由でルートしたい場合は、ケースをCatoサポートへ立ち上げることでCato Networks Supportにお問い合わせください。

SIPプロトコルを利用するVoIPアプリケーションで常に同じEgress IPを使用する必要がある場合は、事前設定の詳細でSIPトラフィック用優先IPオプションを有効にします。

異なるVoIPプロトコルまたはその他のアプリケーションで常に同じEgress IPを使用する必要がある場合は、ケースをCatoサポートへ立ち上げることでCato Networks Supportにお問い合わせください。

ケースをCatoサポートへ立ち上げる

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

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