問題
この文書は、同じ宛先に行きながらも、Catoによってある接続がブロックされ、他が許可される理由を説明します。
例えば、以下のイベント探索は、同じソースが同じプロトコルで同じ宛先IPに接続しようとしたインスタンスを示しています。 しかし、一方の接続はブロックされ、もう一方は許可されました。
トラブルシューティング
このセクションでは、Catoによって接続が異なる扱いをされる可能性のあるいくつかの一般的なシナリオを探ります。 これらのシナリオを理解することは、接続を効果的に最適化およびトラブルシューティングするために重要です。 各項目を以下で掘り下げましょう。
1. 非対称ルーティング
Catoがフロー全体を視認できない場合、データを適切なアプリケーションに正確に分類するための十分な情報が不足している可能性があります。 したがって、特定のプロトコル、例えばHTTPSを許可するファイアウォールルールが存在したとしても、非対称ルーティングによってフローが誤ってTCPとして分類される場合があります。 この誤分類が接続のブロックを招きます。ファイアウォールルールに一致しないためです。 さらに調査するためには、問題が発生しているときにソースから宛先までのトレースルート、そしてその逆を実行することをお勧めします。 フォワードとリバースのパスを比較することによって、これが本当に問題の原因であるかを確認することができます。
2. 重複するカスタムアプリケーション
カスタムアプリケーションを含む影響を受けた接続を扱う場合、その定義の詳細な調査が重要です。 カスタムアプリケーションの定義があまりにも単純化されすぎていると、Catoが一貫してアプリケーションを識別することができなくなります。 カスタムアプリへの接続を許可するファイアウォールルールが存在する場合、カスタムアプリの定義により識別が一貫性を欠き、接続の断続的なブロックを招く可能性があります。 そのため、カスタムアプリケーションを対象とした接続を扱う際には、カスタムアプリケーションとの連携のベストプラクティスに従うことをお勧めします。
3. ユーザー認識遅延
ユーザーが初めてCatoネットワークに接続するとき、ADベースおよびアイデンティティエージェントベースのユーザー認識メカニズムが対応するユーザー名にソースIPアドレスをマップするのに数秒かかります。 この短時間では、初期ユーザーのトラフィックが予期しないファイアウォールルールの下で処理される可能性があります。 しかし、ユーザー意識がうまくユーザー名を識別したら、適切なファイアウォールルールが適用されます。
4. アプリ識別タイムアウト (HTTP/1.1)
モダンブラウザはページの読み込み性能を向上させるために、複数のTCP接続 を HTTP/1.1 経由で同時にオープンします。 これらの接続の一部は確立された後に一時的にアイドル状態になり、HTTPリクエストがすぐに送信されないため、宛先のホスト名がまだ表示されません。 Catoがソケットサイトを介してトラフィックを処理する際、各接続が到着するたびに評価されます。 評価時に宛先ホスト名が存在しない場合、そのトラフィックはFQDNまたはドメインを一致条件として使用するファイアウォールルールと一致しません。たとえそのようなルールが正しく設定されていてもです。
これは期待される動作であり、Socketサイト（オフィスモード）を通して処理されるHTTP/1.1トラフィックに特有のものです。 これは、SDPクライアントには発生しません。SDPクライアントは、トラフィックが転送される前に宛先のコンテキストを提供します。 以下はこの問題を引き起こす条件です：
HTTP専用ウェブサイト
ブラウザは予備のTCP接続を開きます（HTTP/1.1の動作 — Chromeは最大6つの並列接続を開きます）
その予備接続で1秒以内にHTTP GETが送信されません
提案された解決策
Firefoxを使用している場合、
network.http.max-persistent-connections-per-serverを1に設定します。about:configの下でファイアウォールルールを更新して、宛先のIPアドレスを使用し、FQDNまたはドメインではなくします。
代替案として、宛先サーバーがサポートしている場合、HTTP/2はこの動作を排除します。なぜなら、単一の多重化接続を使用し、アイドル状態の並列TCP接続を開かないからです。
5. ルール内のFQDN
Catoが（ブロックまたは許可）扱いする時、ファイアウォールルールやカスタムカテゴリ/アプリで完全修飾ドメイン名（FQDN）が使用されている場合がよくあります。 詳細を掘り下げる前に、2つのイベントを調べてみましょう。どちらも同じソースIPアドレスから発信され、同じIPアドレスとポートを目的としていますが、結果は異なります。一方は許可され、他方はブロックされます。
ファイアウォールルールのレビュー
与えられた例では、接続はWANファイアウォールルールに基づいてブロックまたは許可されます。
さらに調査するには、次のステップに従ってください:
CMA内でWANファイアウォールセクションに移動して関連するルールを検索します。
ルール1が「モニター（許可）」イベントに対応することが明らかです。 このルールは「内部ウェブサーバー」とカテゴライズされた接続を特に許可しています。 ルールにクリックすると、「内部ウェブサーバー」がカスタムカテゴリから来ていることが明らかになります。
対照的に、ルール5はブロックイベントと一致しています。 これは、HTTP(s)トラフィックと他のサービスをブロックするように設計されています。
アプリ/カテゴリのレビュー
ファイアウォールルールから「内部ウェブサーバー」カスタムカテゴリの一致に基づいて接続が許可されたと判断したので、この一致の条件についてさらに調べましょう。
リソース > カテゴリ > カスタムカテゴリに移動します。
カスタムカテゴリのリストで、「内部ウェブサーバー」カテゴリを見つけて選択します。
カテゴリの詳細内で、「内部ウェブサーバー」カテゴリのメンバーが、完全修飾ドメイン名（FQDN）webserver.dyow-homelab.comに一致することが観察されます。
これは、FQDNに一致する接続が許可されることを示しています。 （Catoがホスト名を正しく識別するためには、DNSクエリ/応答が必要です）
正確なFQDNに対応しない接続はすべて拒否されます。 例えば、訪問するウェブサイトに"www"が含まれている場合、DNSクエリに従えば、それはCMAで定義されたFQDNと一致しません。 この問題を解決するには、代わりにドメインオブジェクトを定義することができます。 これにより、定義されたドメインを含むすべてのサブドメインへの一致が可能になります。 Cato WANファイアウォールを参照してください。
上記のブロックされた接続の例では、ユーザーはFQDNではなく宛先IPアドレスを使用してサーバーにアクセスしようとしました。 この場合、DNSクエリ/応答がないため、Catoはホスト名を識別することができず、ルールは一致しません。
DNS要求のない直接IPアクセスが発生する状況では、CatoはDNSキャッシュを利用して指定されたIPにドメインを一致させようとします。 キャッシュにドメインが含まれていない場合、Catoはそれを関連付けることができません。 その結果、上述の接続例はブロックされます。
したがって、許可ファイアウォールルールが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クラウド上のDNSクエリの欠落があっても、ルールの一致が強制されます。