このページでは、ネットワークでアプリケーション レイヤ（レイヤ 7）インスペクションを設定する際に発生する可能性のある一般的な問題のトラブルシューティング方法について説明します。これらの問題は、セキュリティ プロファイル、セキュリティ プロファイル グループ、ファイアウォール エンドポイント、またはファイアウォール ポリシーに関連している可能性があります。
一般的なトラブルシューティングの手順
ネットワークのレイヤ 7 インスペクションに関連する一般的な構成エラーをトラブルシューティングするには、次のセクションで説明するタスクを完了します。
ファイアウォール ポリシー ルールのロギングを有効にする
ファイアウォール ポリシーでレイヤ 7 インスペクション ファイアウォール ルールのロギングを有効にするには、次の操作を行います。
Google Cloud コンソールで [ファイアウォール ポリシー] ページに移動します。
レイヤ 7 インスペクションのファイアウォール ルールを含むファイアウォール ポリシーの名前をクリックします。
[優先度] 列で、ログを有効にするファイアウォール ポリシー ルールの優先度をクリックします。
[編集] をクリックします。
[ログ] で [オン] を選択します。
[保存] をクリックします。
レイヤ 7 インスペクションのファイアウォール ルールを含むすべてのネットワーク ファイアウォール ポリシーと階層型ファイアウォール ポリシーについて、上記の手順を繰り返します。
ファイアウォール ポリシー ルールの構成を確認する
- レイヤ 7 インスペクションのファイアウォール ルールを含むファイアウォール ポリシーが、仮想マシン（VM）ワークロードが配置されている Virtual Private Cloud（VPC）ネットワークに関連付けられていることを確認します。詳細については、ポリシーをネットワークに関連付けるをご覧ください。
- VM ワークロードが存在する VPC ネットワークにファイアウォール エンドポイントが関連付けられていることを確認します。
- ルールの適用順序を確認して、トラフィックに適用されるルールが正しい順序になっていることを確認します。詳細については、ポリシーとルールの評価順序をご覧ください。
- ネットワークと VM インスタンスのレベルで有効なファイアウォール ルールを確認します。レイヤ 7 インスペクションのファイアウォール ルールに含まれるファイアウォール ポリシー ルールが、ネットワーク トラフィックでヒットしていることを確認します。
すべての接続が許可または拒否されるが、インターセプトされない
このシナリオは、レイヤ 7 インスペクションのファイアウォール ルールのコンポーネントがすべて構成されていて、トラフィックがインターセプトされず、脅威や悪意のあるアクティビティが検査されない場合に発生します。
この問題を解決する方法は次のとおりです。
- 検査するファイアウォール エンドポイントと VM ワークロードが同じゾーンにあることを確認します。
- ファイアウォール ポリシー ルールのロギングが有効になっていることを確認します。詳細については、このドキュメントのファイアウォール ポリシー ルールのロギングを有効にするをご覧ください。
Google Cloud コンソールで [ファイアウォール ポリシー] ページに移動します。
レイヤ 7 インスペクションのルールを含むファイアウォール ポリシーをクリックします。
[ヒットカウント] 列で、ファイアウォール ルールに使用された一意の接続数を表示します。
ヒット数がゼロの場合、ルールはトラフィックに適用されません。設定が正しいかどうかを確認するには、このドキュメントの一般的なトラブルシューティングの手順をご覧ください。
ヒット数がゼロでない場合は、その数をクリックして [ログ エクスプローラ] ページに移動し、次の手順を行います。
connection、disposition、remote locationの個々のログを開いて表示します。dispositionがinterceptedとfallback_action = ALLOWに設定されていない場合は、このドキュメントの一般的なトラブルシューティングの手順のセクションに従って、設定が正しいかどうかを確認してください。
上り（内向き）ファイアウォール ポリシー ルールが受信トラフィックをインターセプトしない
このシナリオは、レイヤ 7 インスペクションのファイアウォール ルールが着信トラフィックに適用されていない場合に発生します。これは、着信トラフィックがレイヤ 7 インスペクションのファイアウォール ポリシー ルールに到達する前に、他のファイアウォール ルールと一致する場合に発生します。
この問題を解決する方法は次のとおりです。
- レイヤ 7 インスペクションでファイアウォール ポリシー ルールのロギングが有効になっていることを確認します。詳細については、このドキュメントのファイアウォール ポリシー ルールのロギングを有効にするをご覧ください。
- レイヤ 7 インスペクションのファイアウォール ルールを含むファイアウォール ポリシーが、VM ワークロードが配置されている VPC ネットワークに関連付けられていることを確認します。詳細については、ポリシーをネットワークに関連付けるをご覧ください。
- VM ワークロードが存在する VPC ネットワークにファイアウォール エンドポイントが関連付けられていることを確認します。
- レイヤ 7 インスペクションのファイアウォール ルールが適用されていることを確認するには、ルールで定義した送信元と送信先に基づいて接続テストを実行します。接続テストを実施する方法については、接続テストを作成して実行するをご覧ください。
- ルールが着信トラフィックに適用される順序を確認します。この順序を変更するには、ポリシーとルールの評価の順序を変更するをご覧ください。
接続の一部またはすべてで脅威が検出されなかった
このシナリオは、トラフィックが暗号化されている場合や、脅威を検出するように脅威防止ポリシーが設定されていない場合に発生する可能性があります。
トラフィックが暗号化されている場合は、ネットワークで Transport Layer Security（TLS）インスペクションが有効になっていることを確認します。TLS インスペクションを有効にする方法については、TLS インスペクションを設定するをご覧ください。
TLS インスペクションが有効になっている場合は、クライアントから表示されるメッセージと、Cloud Next Generation Firewall が脅威をブロックしたときに表示されるエラー メッセージを区別します。詳細については、エラー メッセージをご覧ください。
脅威防止ポリシーでこの脅威を検出するように設定されていることを確認します。
- セキュリティ プロファイルを確認し、この脅威に対するオーバーライド アクションが想定どおりに設定されていることを確認します。
- セキュリティ プロファイルにオーバーライド アクションを追加して、脅威をキャプチャします。
侵入防止サービスのファイアウォール ルールが正しく構成されていない
このシナリオは、有効なファイアウォール エンドポイントがない場合、または VM ワークロードが配置されている VPC ネットワークにエンドポイントが関連付けられていない場合に発生します。デフォルトのフォールバック アクションとして、Cloud NGFW はトラフィックを許可し、ファイアウォール ログに apply_security_profile_fallback_action = ALLOW を追加します。ファイアウォール ログを表示するには、ログを表示するをご覧ください。
この問題を解決する方法は次のとおりです。
ネットワークのレイヤ 7 インスペクションでファイアウォール ポリシー ルールのロギングを有効にするには、このドキュメントのファイアウォール ポリシー ルールのロギングを有効にするをご覧ください。
次のフィルタを使用して、ログベースの指標、ログベースのアラート、またはその両方を作成します。
jsonPayload.rule_details.action="APPLY_SECURITY_PROFILE_GROUP" jsonPayload.rule_details.apply_security_profile_fallback_action="ALLOW"
このフィルタにより、インシデントの詳細が生成されます。これにより、概要のほかに、ログの一致条件、通知レートの制限、インシデントの自動閉鎖期間、ログラベル、ログの重大度を確認できます。
エラー メッセージ
このセクションでは、TLS の信頼が不適切である場合や、Cloud NGFW が脅威をブロックした場合に表示される一般的なエラー メッセージについて説明します。TLS インスペクションを設定する方法については、TLS インスペクションを設定するをご覧ください。
ファイアウォール ポリシー ルールがブロックされている
SSH セッション中に、クライアントから次のようなエラー メッセージが表示される場合があります。
curl: (56) OpenSSL SSL_read: Connection reset by peer, errno 104
このエラーを解決するには、ログを表示して検証します。詳細については、ファイアウォール ルール ロギングの使用をご覧ください。
信頼の構成に誤りがある
SSH セッション中に、クライアントから次のようなエラー メッセージが表示される場合があります。
curl: (35) OpenSSL SSL_connect: Connection reset by peer in connection
このエラーは、信頼の構成に問題があることを示します。この問題は、構成が正しくないか、認証局（CA）が存在しないことが原因で発生します。このエラーを解決するには、Certificate Authority Service を有効にします。
次のステップ
- 侵入防止サービスに関するコンセプトについては、侵入防止サービスの概要をご覧ください。
- ファイアウォール ポリシー ルールのコンセプトについては、ファイアウォール ポリシー ルールをご覧ください。
- 費用を確認するには、Cloud NGFW の料金をご覧ください。