トラフィックがファイアウォールルールと一致に失敗

問題

この記事では、同じ宛先に行くにもかかわらず、ある接続がカトによってブロックされ、他の接続が許可される理由について説明します。

例として、以下のイベント探索は、同じ送信元が同じ宛先IPに同じプロトコルで接続を試みたインスタンスを示しています。しかし、1つの接続はブロックされ、もう1つは許可されました。

トラブルシューティング

このセクションでは、カトによって接続が異なるように扱われる可能性のあるいくつかの一般的なシナリオを探ります。これらのシナリオを理解することは、接続の最適化や効果的なトラブルシューティングのために不可欠です。それでは、それぞれを以下で詳しく掘り下げましょう。

1. Asymmetric Routing

Catoが完全なフローを可視化できない場合、データを適切なアプリケーションに正確に分類するのに必要な情報が不足する可能性があります。その結果、HTTPSのような特定のプロトコルを許可するファイアウォールルールが存在しても、非対称ルーティングによってフローが誤ってTCPとして分類されてしまう可能性があります。残念ながら、この誤分類によって許可されたファイアウォールルールと一致しないため、接続がブロックされる可能性があります。さらに調査するために、問題が発生しているときに送信元から宛先までのトレースルートを実施し、逆方向でも実施することが推奨されます。順方向および逆方向のパスを比較することで、これが実際に問題の原因であるかどうかを検証できます。

2. Overlapping Custom Application

カスタムアプリケーションを含む影響を受ける接続を扱う場合、その定義を徹底的に検討することが重要です。過度に単純化されたカスタムアプリケーションの定義が、カトがアプリケーションを一貫して識別するのを妨げる原因となる可能性があります。ファイアウォールルールがカスタムアプリへの接続を許可していても、カスタムアプリの定義方法により識別が一貫しなくなり、接続が断続的にブロックされる可能性があります。したがって、カスタムアプリケーションを対象とする接続を扱う際は、一貫した動作を確保するために、カスタムアプリケーションとの接続作業に記載されたベストプラクティスを遵守することをお勧めします。

3. User Awareness Delay

ユーザーが最初にCatoネットワークに接続すると、ADベースおよびアイデンティティエージェントベースのユーザー認識機構は、ソースIPアドレスを対応するユーザー名にマッピングするために数秒を要します。この短期間中、初期のユーザートラフィックは予期しないファイアウォールルールの下で処理されることがあります。しかし、ユーザー認識がユーザー名を正しく特定すると、適切なファイアウォールルールが適用されます。

4. ルール内のFQDN

カトによって見た目が似ているにもかかわらず、(ブロックまたは許可される)接続が異なる扱いを受けるもう一つの一般的なシナリオは、ファイアウォールルールやカスタムカテゴリ/アプリケーションで完全修飾ドメイン名（FQDN）が使用される場合です。詳細に入る前に、2つのイベントを確認しましょう。どちらも同じ送信元IPアドレスから同じ宛先IPアドレスとポートに向かっており、異なる結果に—1つは許可され、もう1つはブロックされています。

ファイアウォールルールを見直す

与えられた例では、接続はWANファイアウォールルールに基づいてブロックまたは許可されます。

さらに調査するためには、次のステップに従ってください：

CMA内のWANファイアウォールセクションに移動し、関連するルールを検索します。
ルール1がモニタ（許可）イベントに対応することが明らかになります。このルールは、特に「内部ウェブサーバー」カテゴリーの接続を許可します。ルールをクリックすると、「内部ウェブサーバー」がカスタムカテゴリから来ていることがわかります。
対照的に、ルール5はブロックイベントと一致します。これは、HTTP(s)プロトコルトラフィックと他のサービスをブロックするように設計されています。

アプリケーション/カテゴリを確認してください

今やファイアウォールルールから「内部ウェブサーバー」カスタムカテゴリへの一致に基づいて接続が許可されたことがわかったので、さらに調査してこの一致の条件を理解しましょう。

リソース > カテゴリ > カスタムカテゴリに移動します
カスタムカテゴリのリストで、「内部ウェブサーバー」カテゴリーを探して選択します。
カテゴリの詳細内で、「内部ウェブサーバー」カテゴリのメンバーがwebserver.dyow-homelab.comの完全修飾ドメイン名(FQDN)と一致していることを確認します。
これはFQDNと一致する接続が許可されることを示します。（Catoがホスト名を正しく識別するために、DNSクエリ/レスポンスを確認する必要があります）
正確なFQDNと一致しない接続は拒否されます。例えば、訪問したウェブサイトが「www.webserver.dyow-homelab.com」を含む場合（DNSクエリに従って）、CMAで定義済みのFQDNの完全修飾ドメイン名とは一致しません。この問題を解決するためには、代わりにドメインオブジェクトを定義できます。これにより、定義されたドメインを含むすべてのサブドメインに一致します。 Cato WANファイアウォールを参照してください。
上記のブロックされた接続例では、ユーザーがFQDNの代わりに宛先IPアドレスを使用してサーバーにアクセスしようとしました。この場合、DNSクエリ/レスポンスがないため、Catoはホスト名を識別できず、ルールと一致しませんでした。
前段のDNSリクエストなしで直接IPアクセスが発生する状況では、CatoはそのDNSキャッシュを利用して、指定されたIPにドメインを一致させようとします。キャッシュにドメインが含まれていない場合、Catoはそれをホスト名またはFQDNに関連付けることができません。その結果、上述の例では接続がブロックされます。
したがって、FQDN の完全修飾ドメイン名に基づいて一致するようにファイアウォールルールが設定されている場合、顧客は中断のない接続性を確保するためにドメイン名を使用してサーバーにアクセスする必要があります。

注: 内部DNSサーバーを使用中の場合、送信先DNSサーバーがどのように設定済みでも、すべてのDNSクエリがCatoクラウドを通るようにしてください。 DNSのベストプラクティスについては、DNSとCatoアカウントのベストプラクティスを参照してください

代替案

サイトをドメイン名でアクセスし、DNSクエリ/応答が実際にCatoを通っているにもかかわらず、ファイアウォールルールの不一致が発生し続ける場合、次の解決策を実施できます：

ユーザーのPC上のDNSキャッシュがPoPのDNSキャッシュと異なる場合、CatoはサーバーIPとFQDNを関連付けません。内部DNSサーバーを使用している場合、DNS TTL（タイム・トゥー・リブ）を短縮することで、PCにDNSクエリをより頻繁に生成させることができます。
ファイアウォールルールで使用されたカスタムアプリ/カテゴリに、サーバーに一致するIP/ポートの組み合わせを使用してください。上記の例では、カスタムアプリをIPアドレス192.168.2.25およびポート8080に設定します。これにより、DNSキャッシュの不一致やCato Cloud上でのDNSクエリの欠落があっても、ルールマッチングが強制されます。