트래픽이 방화벽 규칙에 일치하지 않음

이슈

이 기사에서는 같은 목적지로 가는 경우에도 특정 연결은 Cato에 의해 차단되고 다른 연결은 허용되는 이유를 설명합니다．

예를 들어, 아래의 이벤트 탐색은 동일한 소스가 동일한 대상 IP 및 동일한 프로토콜에서 연결을 시도한 사례를 보여줍니다． 그러나 하나의 연결이 차단되는 동안 다른 연결이 허용되었습니다．

문제 해결

이 섹션에서는 Cato가 연결을 다르게 처리할 수 있는 몇 가지 일반적인 시나리오를 탐색합니다． 이러한 시나리오를 이해하는 것은 연결을 최적화하고 문제를 효과적으로 해결하는 데 필수적입니다． 아래에서 각각의 시나리오를 자세히 살펴보겠습니다．

1. 비대칭 라우팅

카토가 전체 플로우를 보지 못하는 경우, 데이터를 적절한 애플리케이션으로 정확히 분류할 충분한 정보를 얻지 못할 수 있습니다． 결과적으로 특정 프로토콜（예: HTTPS）을 허용하는 방화벽 규칙이 있어도 비대칭 라우팅으로 인해 플로우가 TCP로 잘못 분류될 수 있습니다． 불행히도 이러한 잘못된 분류로 인해 허용된 방화벽 규칙과 일치하지 않아 연결이 차단될 수 있습니다． 더 깊이 조사하려면 문제가 발생할 때 소스에서 목적지로, 그리고 목적지에서 소스로 트레이스라우트를 수행하는 것이 좋습니다． 정방향 및 역방향 경로를 비교함으로써 이것이 문제의 원인인지 확인할 수 있습니다．

2. 중첩된 사용자 정의 애플리케이션

사용자 정의 애플리케이션이 연관된 영향을 받는 연결을 처리할 때는 정의에 대한 철저한 검토가 필수적입니다． 너무 단순화된 사용자 정의 애플리케이션의 정의는 카토가 애플리케이션을 일관되게 식별하지 못하게 할 수 있습니다． 방화벽 규칙이 사용자 정의 앱으로의 연결을 허용하더라도 사용자 정의 앱이 정의된 방식 때문에 식별이 일관되지 않게 되면서 연결이 간헐적으로 차단됩니다． 따라서 사용자 정의 애플리케이션으로 향하는 연결을 처리할 때는 일관된 동작을 보장하기 위해 사용자 정의 애플리케이션 작업에 명시된 모범 사례를 따를 것을 권장합니다．

3. 사용자 인식 지연

사용자가 처음 Cato 네트워크에 연결하면, AD 기반 및 Identity-Agent 기반 사용자 인식 메커니즘은 소스 IP 주소를 해당 사용자 이름에 매핑하는 데 몇 초가 걸립니다. 이 짧은 기간 동안 초기 사용자 트래픽은 예상치 못한 방화벽 규칙에 따라 처리될 수 있습니다. 그러나 사용자 인식이 사용자 이름을 성공적으로 식별하면 적절한 방화벽 규칙이 적용됩니다.

4. 규칙 내의 FQDN

표면적으로 비슷한 연결이 카토에 의해 다르게 처리(차단 또는 허용)되는 또 다른 일반적인 시나리오는 방화벽 규칙 또는 사용자 정의 카테고리/앱에서 정규화된 도메인 이름(FQDN)을 사용하는 경우입니다． 세부 사항을 자세히 살펴보기 전에 두 가지 이벤트를 검사해 봅니다. 두 이벤트 모두 동일한 소스 IP 주소에서 동일한 IP 주소 및 포트로 전송되지만 결과는 다릅니다. 하나는 허용되고 다른 하나는 차단됩니다．

방화벽 규칙 검토

주어진 예에서 연결은 WAN 방화벽 규칙에 따라 차단되거나 허용됩니다．

더 깊이 조사하려면 다음 단계를 따르십시오：

• CMA 내 WAN 방화벽 섹션으로 이동하여 관련 규칙을 검색합니다．

• 규칙 1이 모니터링(허용) 이벤트와 일치함이 명백해집니다． 이 규칙은 "내부 웹 서버"로 분류된 연결을 특정적으로 허용합니다． 규칙을 클릭하면 "내부 웹 서버"가 사용자 정의 카테고리에서 온 것임을 알 수 있습니다．

• 반면에 규칙 5는 차단 이벤트와 일치합니다． 이 규칙은 HTTP(s) 트래픽과 기타 서비스를 차단하도록 설계되었습니다．

앱/카테고리 검토

• 자원 > 카테고리 > 사용자 정의 카테고리로 이동합니다.

• 사용자 정의 카테고리 목록에서 "내부 웹 서버" 카테고리를 찾고 선택합니다.

• 카테고리 세부 정보에서 "내부 웹 서버" 카테고리의 구성원이 webserver.dyow-homelab.com의 정규화된 도메인 이름(FQDN)과 일치함을 볼 수 있습니다.

• 이것은 FQDN과 일치하는 연결이 허용될 것임을 나타냅니다. (Cato가 호스트명을 정확하게 식별하기 위해서는 DNS 질의/응답을 확인해야 합니다)
  

• 모든 연결이 정확한 정규화된 도메인 이름(FQDN)과 일치하지 않으면 거부됩니다． 예를 들어, 방문한 웹사이트에 "www"가 포함된 경우, 즉 www.webserver.dyow-homelab.com (DNS 쿼리에 따라), 이는 CMA에 정의된 정규화된 도메인 이름(FQDN)과 일치하지 않습니다. 이 문제를 해결하기 위해 도메인 객체를 대신 정의할 수 있습니다． 이렇게 하면 정의된 도메인을 포함하는 모든 서브도메인과 일치할 수 있습니다． Cato WAN 방화벽을 참조하세요．
  
• 위의 차단된 연결 예시에서 사용자는 목적지 IP 주소를 사용하여 서버에 액세스하려고 했습니다． 이 경우 DNS 질의/응답이 없기 때문에 Cato는 호스트명을 식별할 수 없었고, 규칙은 일치하지 않았습니다.
• DNS 요청 없이 직접 IP 접근이 발생하는 상황에서는, Cato가 주어진 IP에 도메인을 일치시키려고 시도하기 위해 DNS 캐시를 사용합니다． 캐시에 도메인이 없으면, Cato는 호스트명이나 정규화된 도메인 이름과 연관시킬 수 없습니다． 결과적으로, 앞서 언급한 예시의 연결은 차단됩니다．
• 따라서, 정규화된 도메인 이름(FQDN)에 기반하여 일치하도록 허용 방화벽 규칙이 구성되었을 때, 고객은 방해 없는 연결성을 보장하기 위해 서버에 도메인 이름을 사용하여 접근해야 합니다.
  
  참고: 내부 DNS 서버를 사용 중인 경우, 구성된 목적지 DNS 서버에 관계없이 모든 DNS 쿼리가 Cato Cloud를 통해 라우팅되도록 해야 합니다. DNS 모범 사례에 대해서는 DNS 및 Cato 계정 모범 사례를 참조하세요 

대안 솔루션

사이트에 도메인 이름을 사용하여 접속하고 DNS 질의/응답이 실제로 Cato를 통과한 후에도 방화벽 규칙 불일치가 계속 발생하는 경우, 다음 솔루션을 구현할 수 있습니다：

• 사용자의 PC의 DNS 캐시가 PoP에서의 DNS 캐시와 다를 수 있으며, 이는 Cato가 서버 IP를 정규화된 도메인 이름과 연관시키지 않는 문제를 초래할 수 있습니다． 내부 DNS 서버를 사용하는 경우, DNS TTL(수명 기간)을 줄여 PC가 더 자주 DNS 질의를 생성하도록 강제할 수 있습니다．
• 방화벽 규칙에 사용된 사용자 정의 앱/카테고리에서 서버와 일치하는 IP/포트 조합을 사용하세요． 위의 예시에서, 사용자 정의 앱을 IP 주소 192.168.2.25 및 포트 8080로 설정하십시오． 이렇게 하면 DNS 캐시 불일치 또는 Cato Cloud 상에서의 누락된 DNS 질의가 있는 경우에도 규칙 일치를 강제할 수 있습니다．