네트워크 규칙 평가 문제 해결

개요

정확한 네트워크 규칙 평가가 정보에 입각한 라우팅 결정을 내리는 데 중요합니다. 이 문제 해결 가이드는 다양한 일반적인 증상을 포괄적으로 다루고, 잠재적인 원인을 탐색하며, 네트워크 규칙 평가와 관련된 문제를 해결하기 위한 체계적인 단계를 제공합니다.

증상

네트워크 규칙에 따라 트래픽을 평가하는 데 실패하면 여러 방식으로 나타날 수 있습니다. 관리자는 다음 증상을 확인할 수 있습니다:

  • 공인 소스 IP 오류
  • 네트워크 규칙 불일치
  • 잘못된 WAN 인터페이스 선택됨
  • TCP 가속이 적용되거나 건너뜀
  • QoS 우선순위 불일치
  • 클라우드 외부 또는 대체 WAN이 트래픽 연결을 끊음

가능한 원인

  • 사용자 정의 또는 내장 애플리케이션 불일치
  • 도메인 불일치
  • 잘못 선택된 송신 PoP
  • 비정상적인 WAN 연결
  • 차단되거나 식별되지 않은 앱이 고정된 QoS 우선순위를 유도함
  • 잘못된 네트워크 규칙 순서

초기 평가

참고

참고: 문제 해결 목적이든 임시로 생성하든 상관없이 구성된 네트워크 규칙과 일치할 것으로 예상되는 트래픽을 포함하는 이벤트 추적 활성화됨 방화벽 규칙이 있는지 확인하십시오.

CMA에서 인터넷 방화벽 또는 WAN 방화벽 프리셋을 선택하여 방화벽 이벤트를 검토하십시오. 관심 있는 트래픽을 좁히기 위해 필터를 설정하십시오. 문제의 가능한 근본 원인을 식별하는 데 도움이 되는 관련 앱, 애플리케이션, Cato 애플리케이션, 송신 PoP 이름, 공인 소스 IP, 목적지 IP, 도메인 이름, 네트워크 규칙 및 TCP 가속과 같은 관련 필드를 분석하십시오.

사용자가 보고한 증상을 식별하여 적절한 문제 해결 섹션을 검토하십시오:

문제 해결

공인 소스 IP 오류 문제 해결

송신 규칙 구성 방법에서 설명한 대로 제한된 인터넷 서비스를 액세스하기 위해 특정 소스 공인 IP를 정의해야 하는 경우가 있습니다. 서비스에서 예상치 못한 소스 공인 IP를 보고하면, 아래 단계를 따르세요.

다중 송신 IP 검토

다수의 송신 IP 주소를 가진 네트워크 규칙의 경우, Cato Cloud는 소스와 지리적으로 가장 가까운 PoP의 송신 IP 주소를 사용합니다. 첫 번째 송신 IP 주소가 사용 불가하면, Cato Cloud는 자동으로 두 번째 송신 IP 주소로 이동합니다. 다음 스크린샷은 두 개의 송신 IP 주소를 가진 네트워크 규칙의 예시를 보여줍니다.

이 예에서, 네트워크 규칙은 뉴욕 PoP 또는 시카고 PoP에서 트래픽을 송신할 수 있습니다. 소스가 물리적으로 뉴욕 PoP에 더 가까운 경우, 카토는 뉴욕 PoP에서 특정 트래픽을 송신하려고 시도할 것입니다. 뉴욕 PoP에서 목적지에 접근할 수 없는 경우, 카토는 시카고 PoP에서 트래픽을 송신합니다.

이 동작을 변경하려면 송신 PoP 선택 변경을 참조하십시오.

사용 불가 송신 IP들

네트워크 규칙에 단일 송신 IP가 포함된 경우, 구성과 다른 Cato 공인 IP를 사용하여 트래픽을 송신할 수 있습니다. 송신 IP와 관련된 PoP가 유지 관리 기간 동안 일시적으로 사용 불가인 경우 이러한 상황이 발생할 수 있습니다. 이 상황은 특히 VoIP 애플리케이션에 있어 중요할 수 있습니다.

이 동작을 변경하려면 송신 PoP 선택 변경을 참조하십시오.

네트워크 규칙 변경 사항 확인

네트워크 규칙이 최근에 송신 IP 주소로 편집된 경우. 새롭게 생성된 트래픽 흐름만이 새 송신 IP를 사용할 것임을 명심하세요. 기존의 트래픽 흐름은 생성 시 사용된 송신 IP를 유지할 것입니다.

위의 동작은 SIP 흐름이 오랜 시간 동안 활성 상태를 유지하는 VoIP 트래픽에 일반적입니다. 이 문제를 해결하기 위해서는 VoIP 전화를 재부팅하여 새 SIP 흐름을 생성하고 업데이트된 네트워크 규칙의 송신 IP에 따라 경로를 지정합니다.

네트워크 규칙 불일치 문제 해결

네트워크 규칙을 구성할 때 트래픽이 잘못된 네트워크 규칙에 따라 평가될 수 있습니다. 이 섹션은 모든 가능한 불일치 시나리오와 이 문제를 해결하는 방법을 다룹니다.

방화벽 이벤트 분석

방화벽 이벤트에서 관련 앱, 애플리케이션, Cato 애플리케이션, 목적지 IP, 도메인 이름네트워크 규칙 같은 관련 필드를 식별하십시오. 이 정보는 네트워크 규칙 불일치의 이유를 해결하는 데 도움이 될 것입니다.

네트워크 규칙 예외 확인

네트워크 규칙에 추가된 예외를 식별하십시오. 트래픽 흐름이 추가된 예외와 일치하는 경우, 네트워크 규칙은 무시되고 규칙 조회는 매칭 항목이 발견될 때까지 남은 규칙 기반에서 계속됩니다.

사용자 정의 애플리케이션 검증

흥미로운 트래픽이 사용자 정의 애플리케이션과 일치할 것으로 예상되며, FW 이벤트에서 발견된 애플리케이션 필드가 일치하지 않는다면, 사용자 정의 앱이 올바르게 구성되어 있는지 확인하십시오. 중첩 사용자 정의 앱이 있는 경우, Cato는 트래픽을 하나의 사용자 정의 앱으로만 식별함을 명심하십시오. 

이 문제를 방지하려면, 중첩 사용자 정의 애플리케이션 해결 섹션을 참조하십시오.

내장된 애플리케이션 검증

흥미로운 트래픽이 내장된 애플리케이션과 일치할 것으로 예상되지만 트래픽이 잘못된 네트워크 규칙과 일치하는 경우, 다음 사항을 확인하십시오.

  • '잘못된' 매칭 네트워크 규칙에 구성된 애플리케이션은 무엇입니까.
  • 이 애플리케이션 중 관련 앱 필드에 나열된 것이 있는지 확인하십시오.

애플리케이션 식별은 프로토콜을 식별하는 것으로 시작하여 관련 앱 필드에 포함된 일치할 수 있는 모든 애플리케이션을 식별하는 다단계 프로세스입니다. 흐름에서 식별된 모든 '관련 앱' 애플리케이션은 최종 앱(애플리케이션 필드) 결정과 무관하게 네트워크 규칙과 일치합니다.

아래 예시에서 portal.azure.com에 대한 접근은 규칙 #7 대신 규칙 #8과 일치합니다. 이는 규칙 #7Microsoft Azure 애플리케이션(관련 앱에 포함됨)을 포함하기 때문입니다. 최종 애플리케이션(애플리케이션 필드)은 Azure Front Door입니다.

예상되는 동작을 해결하기 위해, 네트워크 규칙 순서를 참조하십시오

도메인 이름 확인

네트워크 규칙에 도메인 또는 FQDN 객체가 포함된 경우, FW 이벤트의 도메인 이름 필드를 확인하십시오. 네트워크 규칙의 도메인/FQDN 객체는 이 필드와 동일해야 합니다.

정규화된 도메인 이름(FQDN)은 완전한 도메인의 정확한 매치임을 명심하십시오. 예를 들어, 정규화된 도메인 이름(FQDN) example.com은 단지 example.com.에만 일치합니다.

반면에, 도메인은 모든 서브도메인과 일치하는 최상위(TLD) 또는 2차(SLD) 도메인입니다. 예를 들어, 도메인 example.com은 www.example.comhost.example.com과 일치합니다.

HTTP, TLS, 또는 DNS 흐름에서 올바른 도메인 이름을 카토가 결정할 수 없는 사례가 있을 수 있습니다. 이러한 유형의 문제를 해결하려면 도메인 이름 문제 해결을 참조하십시오

잘못 선택된 WAN 인터페이스 문제 해결

이 섹션은 두 WAN 인터페이스가 활성/활성 배포에 구성된 상태에서 전송으로 카토가 선택된 시나리오를 설명합니다. 정책 기반 라우팅에 대한 추가 정보는 카토가 최적의 전송 또는 링크를 선택하는 방법을 참조하십시오

참고

참고: FW 규칙의 ISP 이름소스 ISP IP 필드는 트래픽이 사용하는 WAN 링크를 결정하는 좋은 지표가 아닐 수 있습니다. 이는 트래픽 흐름이 수명 동안 여러 번 터널을 변경할 수 있기 때문입니다.

네트워크 규칙 전송 구성 검토

활성/활성 배포를 이루려면, 기본 인터페이스 역할을 자동으로 설정하거나, 아래 스크린샷과 같이 기본 및 보조 인터페이스 역할 모두를 구성해야 합니다. 보조 인터페이스 역할을 없음으로 설정하면 기본 인터페이스가 사용 불가능할 때 트래픽 장애 조치가 이루어지지 않습니다. 소켓 인터페이스를 통한 트래픽 라우팅을 참조하십시오

네트워크 분석 검토

평균 처리량 위젯은 각 WAN 링크의 평균 BW 사용량을 보여줍니다. 이는 네트워크 규칙이 올바른 WAN 연결을 선택하고 있거나 트래픽을 적절히 균형을 맞추고 있는지 확인하는 지표로 사용할 수 있습니다. 아래 스크린샷에서 네트워크 규칙은 WAN2를 주요 전송 수단으로 선택하도록 수정되었습니다.

패킷 손실, 지터, 거리 측정을 위해 WAN 링크 성능을 모니터링하는 것이 중요합니다. Active/Active 트래픽 배포에서 설명한 바와 같이, 링크가 최소 링크 품질 임계값을 충족하지 않으면 비정상으로 간주되어 트래픽 배포에 선택되지 않습니다. 비록 WAN 링크가 주요 전송 수단으로 선택되더라도 말입니다.

소켓 WebUI 검토

소켓이 링크를 비정상적으로 간주하는지를 확인하기 위한 쉬운 방법은 소켓 WebUI의 모니터링 페이지입니다. 지연 시간, 지터 또는 패킷 손실 메트릭이 최소 요구 사항을 충족하지 않으면 비정상 값이 빨간색으로 표시됩니다.

아래 예시에서 WAN1은 꽤 높은 지연 시간을 가지며 이는 소켓이 링크를 비정상적이라고 간주하게 만듭니다. 이 문제는 귀하의 ISP와 상의해야 합니다.

WAN 링크 구성 점검

모든 활성/활성 링크가 정상적이라면, CMA에서 각 WAN 링크의 대역폭 구성을 확인하세요. 아래 예시에서, WAN1 링크는 100 Mbps의 하향/상향 대역폭으로 구성되고, WAN2 링크는 20 Mbps의 하향/상향 대역폭으로 구성됩니다. 이로 인해 하향 및 상향 방향 모두에서 100:20 또는 5:1 비율로 WAN1에 더 많은 트래픽이 전송됩니다.

TCP 가속이 적용되거나 건너뛰어진 문제 해결

Cato TCP 가속 및 모범 사례 설명에서 논의된 바와 같이, 네트워크 규칙에서 TCP 연결을 가속하여 WAN을 통해 가속할 수 있습니다. 이 기능은 특정 시나리오에서 강제로 적용되며 규칙의 활성 TCP 가속 옵션을 선택 해제해도 관리자는 이를 비활성화할 수 없습니다. 이 섹션에서는 해당 시나리오와 필요할 때 기능을 비활성화하는 방법을 설명합니다.

TCP 가속이 강제 적용될 때

네트워크 규칙에서 송신 IP 또는 송신 위치를 사용할 때 TCP 가속이 강제 적용됩니다. 이는 PoP가 프록시로 작동하도록 강제해서 규칙에 일치하는 모든 트래픽 흐름에 TCP 가속을 적용합니다. 네트워크 규칙의 체크박스가 회색으로 표시됩니다.

다음과 같은 경우 네트워크 규칙에서 TCP 가속을 비활성화해도 기능이 비활성화되지 않습니다:

  • 계정에서 TLS 검사가 활성화되어 있으면, TLS 트래픽이 우회되어도 모든 TLS 트래픽에 TCP 가속이 활성화됩니다. 이는 PoP가 트래픽을 악성 파일과 위협을 검사하기 위해 프록시로 작동해야 하기 때문입니다.
  • 복잡한 네트워크 규칙이 TCP 가속이 비활성화된 일치하는 네트워크 규칙 위에 존재합니다
  • TCP 가속이 비활성화된 네트워크 규칙 자체가 복잡합니다.

복잡한 네트워크 규칙(또는 NG 규칙)은 소켓 자체에서 평가할 수 없는 규칙입니다. 따라서 소켓은 PoP로 트래픽을 보내 올바른 네트워크 규칙을 선택해야 하고, 이로 인해 TCP 가속이 활성화됩니다. 애플리케이션, 애플리케이션 카테고리, 서비스, 사용자 정의 애플리케이션, 또는 정규화된 도메인 이름(FQDN) 객체를 포함할 수 있습니다.

반면, 소켓에 의해 평가되며 PoP의 개입이 필요하지 않은 다음과 같은 엔터티를 간단한 규칙에 포함할 수 있습니다:

  • 출발지/목적지 필드에: 사이트, IP 주소, 네트워크 인터페이스, IP 범위, 또는 모든 것.
  • 앱/카테고리 필드에: 포트 범위 또는 사용자 정의 서비스.

TCP 가속을 건너뛰는 경우

TCP 가속은 TCP 트래픽에만 적용됩니다. 네트워크 규칙에서 TCP 가속이 활성화되었거나 이전 부분에서 설명한 대로 강제 적용되었지만, CMA 이벤트의 TCP 가속 필드가 0인 경우, Cato Cloud의 비대칭 라우팅으로 인해 트래픽 흐름이 열림 모드로 감지될 수 있습니다

Cato 상의 비대칭 라우팅에서 설명한 바와 같이, 열림 모드는 Cato Cloud가 TCP 플로우의 시작(3방향 핸드셰이크)을 인식하지 못하는 연결 모드로, TCP 가속이 적용되지 않습니다. 열림 모드 흐름 생성을 위한 근본 원인을 파악하기 위해 Cato 지원 팀과 함께 작업할 것을 권장합니다.

TCP 가속 비활성화

네트워크 규칙 순서에 설명된 대로, 송신 IP나 위치가 없는 간단한 규칙을 네트워크 규칙의 맨 위에 놓을 때 TCP 가속을 비활성화할 수 있습니다. 위에서 언급한 것처럼, 트래픽이 TLS인 경우 계정 전체에 대해 TLS 검사를 비활성화해야 합니다.

QoS 우선순위 불일치 문제 해결

흐름이 QoS 우선순위 255로 할당되는 경우에서 설명한 것처럼 네트워크 규칙에 구성된 QoS 우선순위가 FW 이벤트에 표시된 우선순위와 다른 경우가 있을 수 있습니다.

QoS 우선순위 255는 BW 관리의 기본 우선순위로 참조됩니다. 네트워크 규칙의 대역폭 우선순위 구성과 상관없이 흐름이 QoS 우선순위 255로 할당될 수 있는 여러 가지 이유가 있습니다:

  • Cato는 각 흐름의 네트워크 프로필을 평가하며, 특정 애플리케이션이 아직 식별되지 않은 경우 QoS 우선순위 255를 할당합니다.
  • 첫 번째 패킷(흐름이 식별되기 전)이 QoS 우선순위 255로 할당됩니다.
  • 차단된 흐름은 QoS 우선순위 255로 할당됩니다.

클라우드 외부 또는 Alt-WAN 연결 문제 해결  

이 섹션은 WAN 네트워크 규칙이 주요 전송으로 클라우드 외부 또는 Alt-WAN으로 구성된 경우, 사이트 간 TLS 연결을 설정할 수 없는 시나리오를 다룹니다. 이 문제를 해결하려면 아래 단계를 따르십시오.

흐름 분석

트래픽이 클라우드 외부 또는 Alt-WAN을 통해 올바르게 라우팅되면 이 트래픽이 PoP를 통하지 않기 때문에 CMA에서 FW 이벤트가 생성되지 않습니다.

트래픽이 클라우드 외부 또는 Alt-WAN을 통해 성공적으로 라우팅되었는지 확인하는 방법 중 하나는 소켓 웹UI의 SDWAN 탭에서 확인하는 것입니다. 활성 트래픽 흐름을 식별하고 선택된 NIC 아래에서 관심 있는 트래픽에 대해 선택된 전송을 볼 수 있습니다. 예상 전송이 선택되지 않은 경우, 클라우드 외부 또는 Alt-WAN이 올바르게 구성되었는지 확인하십시오.

네트워크 규칙 순서 검증

클라우드 외부 또는 Alt-WAN 링크에서 TLS 연결 실패에서 설명된 바와 같이, 트래픽이 TLS이고 TLS 검사가 활성화된 경우 네트워크 규칙 순서는 클라우드 외부 또는 Alt-WAN 링크에서의 트래픽 흐름을 보장하는 중요한 요소입니다.

트래픽이 충돌하는 네트워크 규칙이 복잡한 규칙 아래에 있을 때 소켓은 네트워크 규칙을 평가하고 클라우드 외부 또는 Alt-WAN을 통해 패킷을 라우팅할 수 없습니다. 이 예상된 동작을 해결하려면, 네트워크 규칙 순서를 참조하십시오

발견된 문제 해결

중첩된 사용자 정의 애플리케이션 해결

사용자 정의 애플리케이션에 올바른 IP 주소, 도메인, 포트 및 프로토콜이 포함되어 있는지 확인하십시오. 식별을 위해 선택할 사용자 정의 앱에 논리가 없으므로 다른 사용자 정의 앱과 중복되지 않도록 고유하게 정의해야 합니다. 자세한 정보는 사용자 정의 애플리케이션 작업을 참조하십시오

네트워크 규칙 순서

네트워크 규칙은 순서에 따라 평가되므로, 보다 구체적인 규칙을 일반적인 규칙 위에 정의하는 것이 중요합니다. 예를 들어, 사용자 정의 애플리케이션, 내장 애플리케이션, 도메인, FQDN 또는 사용자 정의 서비스 정의된 네트워크 규칙은 카테고리, 사용자 정의 카테고리 또는 서비스를 포함하는 네트워크 규칙 위에 배치해야 합니다.

아래의 스크린샷에서 규칙 1에는 twitter.com에 대한 IP 범위가 포함된 사용자 정의 서비스가 있으며, 애플리케이션 카테고리를 포함하는 규칙 2 위에 배치되어 있습니다. 규칙 1은 규칙 2보다 더 구체적이며 twitter.com을 대상으로 하는 트래픽에 더 잘 맞습니다. 추가로 TCP 가속이 비활성화되며, 규칙 1이 단순 규칙이므로 모든 클라우드 외부 또는 Alt-WAN 라우팅 문제를 해결할 것입니다.

도메인 이름 문제 해결

도메인/FQDN을 기반으로 한 네트워크 규칙 매칭 문제는 다음과 같이 해결할 수 있습니다:

  • HTTP/S와 같은 프로토콜의 경우, Cato는 다음 소스를 사용하여 목적지 도메인을 결정할 수 있습니다.
    • HTTP 호스트명 헤더 (TLS 검사 활성화됨)

    • SNI 필드는 TLS 핸드셰이크 중에 사용됩니다.

    • DNS 해상도, 여기서 도메인 이름은 DNS 쿼리 및 응답에서 학습됩니다.

  • 네트워크 규칙에 지정된 도메인이 이러한 모든 출처에서 일관되게 유지되는 것이 중요합니다. 도메인 이름과 가장 잘 일치하는 이름(상위에서 하위로 평가됨)만 방화벽 이벤트의 도메인 이름으로 표시됩니다. 

  • SSH나 SMB와 같은 기타 프로토콜의 경우, 도메인을 일반 텍스트로 전송하지 않는다면 Cato는 트래픽을 도메인이나 정규화된 도메인 이름(FQDN)과 연결하기 위해 DNS 인터셉션에 전적으로 의존합니다. 사설 DNS를 사용할 때, DNS 쿼리/응답이 Cato를 통해 전달되도록 보장해야 하므로 특히 중요합니다. 최적의 DNS 및 Cato 계정 사용 방법을 참조하십시오

송신 PoP 선택 변경

출발지(기본 동작)와 가장 가까운 곳이 아닌 목적지와 가장 가까운 PoP를 통해 계정의 모든 송신 규칙을 라우팅하려면, Cato 지원에 케이스 제기하기로 Cato Networks 지원에 문의하십시오.

항상 동일한 송신 IP를 사용해야 하는 SIP 프로토콜을 사용하는 VoIP 애플리케이션의 경우, 고급 설정에서 SIP 트래픽에 대한 선호 IP 옵션을 활성화하십시오.

다른 VoIP 프로토콜 또는 다른 애플리케이션이 항상 동일한 송신 IP 사용을 요구하는 경우, Cato 지원에 사례 생성을 통해 Cato Networks 지원에 문의하십시오.

Cato 지원에 사례 생성

위의 문제 해결 단계 결과로 지원 티켓을 제출하십시오. 다음 정보를 티켓에 포함하십시오:

  • 경험한 문제의 세부 정보 및 사용자에 대한 전체 영향입니다.
  • 관련 방화벽 이벤트 및 네트워크 규칙 구성입니다.
  • 문제를 재현하고 지원 자가 서비스를 실행하십시오. 도구에 의해 생성된 티켓 번호를 포함하십시오.

도움이 되었습니까?

2명 중 2명이 도움이 되었다고 했습니다.

댓글 0개