このプレイブックでは、LANモニタリングが設定されている際にCato Cloudがサイトの背後にあるホストに到達できない場合の問題解決手順を説明します。
LANモニタリング機能では、サイト背後のホストをIPアドレスとホストの障害閾値(連続失敗するICMPテストの最大数)で定義できます。 Cato Cloud内のPoPがホストにICMPテストを送信し、指定された数のICMPテストに応答しない場合、ホストはダウンとみなされ、イベントが自動的に生成されます。 ホストが到達不能の場合、メール通知を送信することも選択できます。
ホストとPoP間の接続が回復すると、ホストが到達可能であることを示す新しいイベントが生成されます。
詳細については、サイト用LANモニタリングの操作を参照してください。
Cato管理画面の管理者が監視されているホストが監視PoPで到達不能になったことを確認するためのさまざまな方法を以下に示します。
-
XDRインシデント検出ページに移動し、ネットワークXDRプリセットを使用してLANモニタリングホスト到達不能ストーリーを見つけます。
ストーリーは現在のサイトの状態、インシデントタイムラインなどの情報を提供します。
-
LANモニタリングイベントとアクションホスト到達不能
-
LANホスト到達不能プリセットフィルターを使用し、必要に応じて時間枠を調整します。
-
-
LANモニタリングメール通知
-
LANモニタリングルールに対してメール通知が有効になっている場合、メールはメールリストに送信されます(非管理者を含むことができます)
-
サイトオペレーションストーリーに対応する際には、まず問題が進行中であることを確認し、次に問題をトラブルシューティングし、最後に問題が解決されたことを確認することが重要です。
このセクションでは、ホストが到達不能である理由を確認するために使用できるさまざまなCatoツールについて説明します。
LANモニタリングイベントプリセットの使用
LANモニタリングプリセットイベントフィルターを使用することで、該当するホストに関連する最後のイベントを確認できます。 このイベントの後に接続が回復したことを示すイベントが続かない場合、ホストはまだ到達不能であることが示唆されます。
現在のステータスを確認するためのストーリー閲覧
ストーリー自体もホストの到達不能が続いているかを確認するために使用できます。 ストーリーの現在のステータスはダッシュボードに表示されます。 ストーリーステータスがオープンの場合、このイベントがまだ進行中であることを示しています。
ステップ2 - ホスト接続のトラブルシューティング
このセクションでは、この種のインシデントに対して構造的なトラブルシューティングアプローチを採用するために使用できるCato内のツールについて説明します。 これらの手順は一般的に順番に従うべきですが、これらのチェックの結果が次のステップが何であるかを決定するかもしれません。
Cato管理画面の監査トレイルページの変更をレビューし、この問題に関連する構成があるか確認します。 ホストステータスの変更につながる構成があれば、変更を元に戻すことを検討してください。
既知のホスト
CMAの既知のホストページ(ネットワーク > サイト > {site name} > サイトモニタリング > 既知のホスト)を使用して、サイト内で確認される個別のエンドポイントに関する情報を収集できます。 この情報には、そのホストから送信される最後のパケットが見られたのがどれほど前かが含まれます。
通常、LANモニタリングの一環としてICMPパケットに応答する監視ホストは、このタイマーを常に更新し続けます。 上記の例はホストの接続性が失われたタイミングを示唆しています。 これにより追加のコンテキストが提供される場合があります。 この時間枠がホスト接続性に影響を及ぼす可能性がある予期されるメンテナンスウィンドウや電力イベント、またはローカル環境でのネットワーク変更に一致するかどうか確認してください。
ソケットWebUIを使用してLANインターフェースからホストにpingを実行できます。 詳細については、ソケットWebUIツールの使用を参照してください。
-
ソケットWebUIからこの設定でホストにpingを実行してください。
-
ルート経由 - LAN
-
ホスト名/IP - 到達不能なホストのIPアドレス
pingに応答がない場合、問題はルーティングに関連しているか、またはホストが一般的に到達不能、電源が入っていない、あるいはpingに応答するように設定されていない可能性があります。
-
-
-
ソケットWebUIツールを使用して、問題のホストに対するpingが進行中の間にLANインターフェースのPCAPを取得します。 ソケットとホストの間で双方向のpingがあるかどうか確認してください。
上記の例は、問題のホストの物理アドレスのARPに対してソケットからの応答がないことを示しています。 これはホストがソケットLANと同じローカルネットワーク上にあるが、ホストがレイヤー2で応答していないことを示唆しています。 この結果に対して、ホストが電源が入っていてARP要求に応答する準備ができていることを確認してください。
上記の例は、監視されているホストに対してソケットとPoPの元のLANモニタリングで設定されたICMP要求の両方を示しています。 送信元アドレス10.254.254.1とPoPによって送信されたICMP LANモニタリング要求の時間差(10秒)に注意してください。 ICMP要求が送信されているという事実は、これらの要求を送信するために次のホップまたはエンドホストのMACアドレスが利用されていることを示しています。 このMACアドレスが、監視されているホストがレイヤー3の境界の背後に存在することを示唆しているか、ソケットのLANネットワークにローカルに存在しているか確認してください。
- 監視されているホストがレイヤー3の境界の背後にある場合、そのホップでICMP要求がどのように処理されているか調査を開始します。 ホストからのICMP応答がそのレイヤー3の境界デバイスに到達している場合、おそらくそのレイヤー3の境界でのルーティング問題である可能性があります。
- 監視されているホストがソケットのLANネットワーク内にある場合、おそらくデバイスが電源が入っていないか、ICMPに応答するように設定されていないか、応答できない可能性があります。
-
ホストの問題を改善した後、それが到達可能であることを確認し、Cato Cloudに接続していることを確認してください。
ホストとCato Cloud間の接続が回復した後、ホスト到達可能イベントが生成されます。 イベントを表示するためにアクション IS ホスト到達可能イベントフィルターを手動で設定できます。
Catoサポートへのケースの提出
このプレイブックを実行した後、問題を解決できない場合は、Catoサポートにチケットを提出した方が良いでしょう。 この際、迅速な解決のために、上記の手順を通じて得たすべての洞察を含めることが重要です。
サポートチケットの提出をご覧ください。
0件のコメント
サインインしてコメントを残してください。