내부 리소스 접근 문제 해결

개요

내부 자원에 원활하게 접근하는 것은 네트워크에서 생산성과 보안을 유지하는 데 중요합니다. 그러나 다양한 요소가 접근을 방해할 수 있으며, 이는 사용자 경험과 작업 흐름을 저하시킬 수 있습니다. 이 안내서는 Cato Cloud 내에서 내부 자원의 WAN 접근 문제를 해결하기 위한 포괄적인 가이드를 제공하는 것을 목표로 합니다.

증상

내부 자원에 접근할 수 없는 문제는 여러 방식으로 나타날 수 있습니다. 관리자는 다음과 같은 증상을 주목할 수 있습니다:

  • 내부 서버의 도메인 이름을 해석할 수 없습니다
  • 내부 서버에 접근할 수 없습니다
  • WAN 방화벽 규칙 불일치
  • SDP 클라이언트들이 내부 리소스에 접근할 수 없습니다
  • 원격 포트 전달(RPF) 리소스에 연결할 수 없습니다
  • LAN 모니터링 호스트에 접근할 수 없습니다

가능한 원인

  • 라우팅 문제
  • DNS 전달 잘못 구성
  • WAN 방화벽 잘못 구성
  • SDP 클라이언트 네트워크와 중복됨
  • 보안 개입
  • 대상 호스트 연결 문제

초기 평가

참고

참고: WAN 방화벽 규칙(문제 해결 목적을 위해 임시로 생성됨)이 이벤트 추적 활성화됨 상태인지 확인하십시오.

브라우저를 통한 내부 서버 접근과 관련된 문제의 경우, 브라우저 접근 문제 해결를 참조하십시오

CMA에서 해당 프리셋을 선택하여 WAN 방화벽, IPS 및 안티멀웨어 이벤트를 검토하십시오. 흥미로운 트래픽을 좁히기 위해 필터를 설정하고, WAN 방화벽 혹은 IPS/AM 엔진에 의해 흐름이 차단되었는지 확인하십시오. 규칙 필드에는 트래픽에 일치하는 해당 규칙이 표시됩니다.

다음 초기 평가 단계를 통해 적절한 문제 해결 섹션을 검토하십시오:

문제 해결

관리자가 직면할 수 있는 증상을 문제 해결하기 위한 단계는 아래에 나열되어 있습니다. 이 단계는 직면한 문제의 가능한 원인을 식별하기 위함입니다. 해결 단계는 플레이북에서 나중에 강조될 것입니다.

감사 추적 로그 검사

내부 자원에 대한 접근에 영향을 미쳤을 수 있는 감사 추적수정된 로그를 확인하세요. 여기에는 WAN 방화벽 규칙, AM/IPS 설정, 그리고 TLS 검사가 포함됩니다.

서버 도메인 이름 해결 문제 해결

DNS 해결 검사

내부 자원을 도메인 이름을 사용하여 도달하려면, 명령줄에서 nslookup 또는 dig 명령을 사용하여 내부 서버의 도메인 이름이 해결될 수 있는지 확인하세요.

계정에서 내부 DNS 해결을 위한 두 가지 시나리오가 있을 수 있습니다:

  • 조직에서 비공개 DNS 서버 IP 주소를 사용하는 경우, 영향받은 사용자가 내부적으로 DNS 서버에 도달할 수 있는지 확인하세요. 그렇지 않다면, 연결할 수 없는 내부 서버 문제 해결과 유사하게 DNS 서버의 연결 문제를 해결하세요
  • 기본 Cato DNS 서버 10.254.254.1, 계정 정의 DNS 서버, 또는 잘 알려진 공용 DNS (8.8.8.8, 1.1.1.1 또는 9.9.9.9)가 계정에서 사용되는 경우, 다음 단계에서 DNS 전달을 문제 해결하세요.

DNS 전달 검증

내부 도메인 이름에 의존하는 트래픽 흐름 (예: pc1.domain.net)은 CMA에서 DNS 전달이 올바르게 구성되어야 합니다. Cato가 도메인 이름을 정확하게 해결할 수 있도록 DNS 흐름을 가로채는 것이 매우 중요합니다.

DNS 전달은 DNS 쿼리가 특정 DNS 서버를 대상으로 할 때만 작동할 수 있습니다. 이는 DNS 전달 문제 해결에서 설명된 대로입니다.

연결할 수 없는 내부 서버 문제 해결

Cato 라우팅 테이블 검사

라우팅 테이블은 경로 가용성, 메트릭 등을 확인하는 데 사용될 수 있습니다:

  • 검색 문자열에서 리소스 IP 주소를 검색하고 올바른 사이트를 통한 일치하는 경로가 있는지 확인하세요.
  • 경로가 발견되지 않는 경우, 이는 Cato가 이 경로를 인식하지 못하므로, 이 목적지로의 라우팅이 불가능하다는 것을 의미합니다. 이 문제를 해결하려면 라우팅 문제 해결을 참조하세요
  • 동일한 목적지로의 경로가 있는 경우, BGP 동적 범위가 다른 정적 경로와 겹치지 않는지 확인하세요. 메트릭이 낮은 경로가 선호됩니다.
  • BGP는 또한 다른 사이트에서 중복 경로를 광고할 수 있습니다. 가중치, AS 길이, 또는 MED를 포함한 낮은 메트릭을 가진 경로가 선호됩니다. 라우팅 테이블 필드 이해를 참조하세요.
  • 메트릭 문제 해결을 위해 라우팅 문제 해결을 참조하세요

IPSec 정책 기반 라우팅 점검

내부 자원이 IPSec을 통해 접근할 수 있는 경우, IPSEC 문제 해결 플레이북에서 설명한 대로 사이트의 IPSec 및 네트워크 섹션에 올바른 범위가 정의되어 있는지 확인하세요.

정책 기반 라우팅이 구성된 경우, 모든 트래픽 선택자는 내부 자원과의 연결성을 보장하기 위해 Cato와 IPSec 방화벽/라우터에서 일관되게 매치되어야 합니다.

내부 자원의 활성 상태 점검

내부 자원이 소켓 또는 vSocket 뒤에 있는 경우, 사이트의 알려진 호스트 페이지에서 최근 호스트 활동 값을 확인하십시오. 사이트에 대한 알려진 호스트 표시를 참조하십시오

사이트에서 최근에 확인되지 않은 호스트는 전원이 꺼졌거나 네트워크에 연결되어 있지 않을 수 있습니다.

WebUI에서 패킷 캡처를 실행하고 LAN 내의 가능한 문제를 확인하십시오.

TLS 플로우 점검

흥미로운 트래픽이 TLS이고 이전 단계에서 해당 트래픽이 허용되었는지 확인한 경우. Cato가 트래픽 플로우를 TLS로 검사하고 있는지 확인하십시오. 이는 TLS 검사 필드가 1로 설정된 방화벽 규칙에서 찾을 수 있습니다.

그렇다면 TLS 검사 정책 구성에서 설명한 대로 Cato 루트 인증서를 소스 디바이스에 설치해야 합니다. 그렇지 않으면 TLS 검사를 우회하여 모든 인증서 오류와 자원에 대한 잠재적인 접근 문제를 방지하십시오.

WAN 방화벽 규칙 불일치 문제 해결

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

사용자 정의 애플리케이션 확인

흥미로운 트래픽이 사용자 정의 애플리케이션과 일치해야 하고 FW 이벤트에서 발견된 애플리케이션 필드가 일치하지 않는 경우, 사용자 정의 애플리케이션이 올바르게 구성되었는지 확인하십시오. 중복 사용자 정의 애플리케이션이 있는 경우 Cato는 트래픽을 사용자 정의 애플리케이션 중 하나로만 식별한다는 점을 명심하십시오. 

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

내장된 애플리케이션/서비스 확인

흥미로운 트래픽이 내장된 애플리케이션 또는 서비스와 일치해야 하고 트래픽이 잘못된 방화벽 규칙과 일치하는 경우 다음을 확인하십시오:

  • 잘못된 일치 방화벽 규칙에 어떤 애플리케이션 또는 서비스가 구성되어 있는지 확인하십시오.
  • 이러한 애플리케이션/서비스 중 연관된 앱 필드에 나열된 것이 있는지 확인하십시오.

애플리케이션/서비스 식별은 프로토콜을 식별하는 것부터 시작하여 연관된 앱 필드에 포함된 가능한 모든 일치 애플리케이션을 식별하는 다단계 프로세스입니다. 연관된 앱으로 식별된 애플리케이션은 최종 앱(애플리케이션 필드) 결정과 관계없이 방화벽 규칙과 일치합니다.

아래 예시에서 SMB 트래픽은 규칙 #1과 규칙 #2 대신 일치합니다. 이는 규칙 #1이 연관된 앱에 포함된 TCP 서비스를 포함하기 때문입니다, 최종 애플리케이션 (애플리케이션 필드)은 SMB입니다.

이 기대된 동작을 해결하려면 방화벽 규칙 순서를 참조하십시오.

구성된 도메인 이름 확인

방화벽 규칙에 도메인 또는 정규화된 도메인 이름(FQDN) 객체가 포함된 경우, FW 이벤트에서 도메인 이름 필드의 내용을 확인하십시오. 방화벽 규칙의 도메인/FQDN 객체는 이 필드와 동일해야 합니다.

정규화된 도메인 이름(FQDN)은 완전히 적격한 도메인과 정확히 일치해야 한다는 점을 유의하십시오. 예를 들어, 정규화된 도메인 이름(FQDN) example.comexample.com.과만 일치합니다.

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

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

SDP 클라이언트가 내부 자원에 도달하지 못하는 문제 해결

이 섹션은 SDP 클라이언트가 내부 자원에 도달하지 못하는 문제에 대해 설명합니다.

사용자의 홈 네트워크 서브넷 중복 확인

SDP 클라이언트가 서버를 핑(ping)하는 것을 포함하여 내부 자원에 연결할 수 없는 경우, 사용자 홈 네트워크와 내부 자원을 가진 사이트 사이에 IP 주소 중복이 있는지 확인하십시오. 그런 경우, 클라이언트의 라우팅 테이블은 원격 카토 사이트 뒤에 위치한 내부 서버에 연결하려고 할 때 로컬 네트워크 인터페이스 카드(NIC)를 가리킬 것이며, 이로 인해 연결이 실패하게 됩니다.

192.168.0.0/24, 192.168.1.0/24, 또는 10.0.0.0/24의 IP 범위를 가진 원격 사이트는 종종 기본 DHCP 설정으로 이 IP 범위를 사용하는 홈 무선 라우터의 IP 범위와 쉽게 중복될 수 있습니다.

이 문제를 해결하려면, SDP 클라이언트가 원격 WAN 자원에 연결할 수 없음에서 설명된 과정을 따르십시오.

macOS 및 iOS 사용자가 내부 도메인을 해결하지 않음

macOS Ventura 및 iOS 사용자가 카토를 통해 내부 자원에 접근할 수 없음에서 설명한 것과 같이, SDP 클라이언트가 도메인 이름을 사용하여 내부 자원에 연결할 수 없지만 IP 주소를 사용하여 도달할 수 있는 경우, 엔드포인트에서 사용 중인 DoH (DNS over HTTPS) 또는 DoT (DNS over TLS)로 인해 DNS 전달이 실패할 수 있습니다. 카토는 현재 DoH/DoT를 지원하지 않습니다.

이 문제를 해결하려면 DNS 전달 문제 해결을 참조하십시오. 또한 CMA에서는 Cato DNS 서버 (10.254.254.1)를 엔드포인트의 유일한 DNS 서버로 정의할 수 있습니다.

안드로이드 사용자가 내부 도메인을 해결하지 않음

안드로이드 디바이스가 카토를 통해 내부 자원에 접근할 수 없음에서 설명한 것과 같이, SDP 클라이언트가 도메인 이름을 사용하여 내부 자원에 연결할 수 없지만 IP 주소를 사용하여 도달할 수 있는 경우, 디바이스에서 사용하는 자동 사설 DNS (기본 동작)로 인해 DNS 전달이 실패할 수 있습니다. 이는 현재 카토에서 지원되지 않습니다.

이 문제를 해결하려면 DNS 전달 문제 해결을 참조하십시오. 또한, 디바이스에서 사설 DNS를 비활성화할 수 있습니다.

RPF 내부 자원 문제 해결

RPF 이벤트 분석

CMA에서 RPF 프리셋을 선택하여 RPF 이벤트를 검토합니다. 외부 카토 IP가 사용 가능함을 확인할 수 있도록 이벤트가 생성되는지 확인합니다. 대상 IP 주소는 RPF 규칙에 설정된 외부 공인 IP임을 참고하십시오.

참고: 인바운드 RPF 이벤트는 때때로 표시 이름을 표시할 수 있습니다. 이는 트래픽이 사용자가 시작한 것이 아니더라도 가능합니다. 이는 예상된 동작입니다.

카토 플랫폼의 이벤트 필드는 트래픽 흐름뿐만 아니라 터널, 호스트사용자 에이전트에서의 메타데이터를 끌어옵니다. 따라서 소켓이나 터널 뒤에 있는 장치에 사용자가 매핑되어 있는 경우 이들의 이름이 인바운드 트래픽에도 이벤트에 표시될 수 있습니다.

이는 방화벽 또는 라우팅 정책이 트래픽을 방향에 따라 해석하는 방식과는 다르지만, 이벤트 상관관계에 있어서는 일반적입니다. 

 

지리적 차단 이벤트 분석

내부 서버의 내부 IP 주소를 대상으로 하는 이벤트를 검토하십시오. 지리적 차단 제한이 내부 서버에 대한 연결을 방해하지 않는지 확인하십시오. 만약 그렇다면, 소스 국가를 허용하기 위해 인바운드 방향의 지리적 제한 정책을 편집하세요.

내부 리소스의 생존 여부 확인

사이트의 알려진 호스트 페이지에서 마지막으로 알려진 활동 값을 확인하세요. 사이트의 알려진 호스트 표시하기를 참조하세요

사이트에서 최근에 확인되지 않은 호스트는 꺼져 있거나 네트워크에 연결되지 않았을 수 있습니다.

WebUI에서 패킷 캡처를 실행하고 LAN 내의 가능한 문제를 식별하세요.

도달할 수 없는 LAN 모니터링 호스트 문제 해결

연결성 이벤트 분석

CMA에서 LAN 호스트에 접근할 수 없음 사전 설정을 선택하여 연결성 이벤트를 검토하세요. 정의된 LAN 호스트에 더 이상 접근할 수 없을 때 호스트 접근 불가 이벤트가 생성됩니다.

로컬 호스트 도달성 확인

정의된 로컬 호스트가 소켓 웹UI에서 핑할 수 있는지 확인하세요. 핑이 성공하면 다음을 확인하세요:

  • LAN 모니터링 프로브는 10.254.254.1에서 소스 되는 ICMP 패킷이므로, 모니터링되는 호스트가 응답하기 위해 소켓 LAN 게이트웨이로 돌아가는 경로를 가지고 있는지 확인하는 것이 중요합니다.
  • 장치가 로컬 방화벽을 실행 중인 경우, 10.254.254.1 IP 주소에서의 ICMP를 허용해야 합니다.

WebUI에서 패킷 캡처를 실행하고 LAN 내의 가능한 문제를 식별하세요.

발견된 문제 해결

라우팅 문제 해결

라우팅 테이블에서 내부 리소스로의 경로를 찾을 수 없는 경우, 다음을 확인하고 해결하세요:

  • 사이트에 BGP가 구성되어 있는 경우, 이웃이 경로를 알리고 있는지 확인하세요. BGP 상태 보기를 참조하세요. 로컬 라우터가 광고하는 BGP 프리픽스를 검토하고, Cato가 그것들을 수신하고 있는지 확인하는 것이 중요합니다.
  • BGP 세션이 다운된 경우, 연결 문제를 해결하세요. BGP 세션이 연결이 끊어졌습니다를 참조하세요
  • 범위를 호스팅하는 사이트가 사용 가능한지 확인하세요. 사이트 연결성 문제 해결을 참조하세요

라우팅 테이블에서 보는 경로 메트릭이 잘못된 라우팅 결정을 초래하는 경우, 다음을 확인하고 해결하세요:

  • 터널 메트릭 값은 일반적으로 Cato에 의해 설정됩니다. 중복된 경로는 IPSec 또는 소켓 사이트 등 동일한 유형의 사이트에서 비롯된 경우 동일한 터널 메트릭을 가져야 합니다.
  • 가중치 값은 CMA의 네트워크 > 사이트 > 사이트 설정 > BGP에서 구성할 수 있습니다. 이 페이지에서 구성된 메트릭 값은 라우팅 테이블에서 가중치로 나타납니다. 사이트의 메트릭을 변경하면 중복된 경로에 대한 잘못된 라우팅 결정을 수정할 수 있습니다.
  • AS 길이 및 메트릭 차별화 값은 외부 라우터로부터 수신됩니다. 필요한 경우 이 장치에서 수정해야 합니다.

오탐 IPS/안티-멀웨어 차단 문제 해결

만약 흥미로운 트래픽이 IPS/AM에 의해 차단된다면, WAN의 범위로 허용 목록을 IPS와 안티맬웨어 설정에 추가할 수 있습니다.

 

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

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

방화벽 규칙 순서

방화벽 규칙은 순서에 따라 평가되므로, 더 구체적인 규칙을 더 일반적인 규칙 위에 정의하는 것이 중요합니다. 예시로, 사용자 정의 애플리케이션, 내장 애플리케이션, 도메인, 정규화된 도메인 이름(FQDN), 또는 사용자 정의 서비스를 정의하는 방화벽 규칙은 카테고리, 사용자 정의 카테고리, 또는 서비스를 포함하는 방화벽 규칙 위에 위치해야 합니다.

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

도메인 이름 불일치 문제 해결

도메인/정규화된 도메인 이름(FQDN)을 기반으로 한 방화벽 규칙 일치 문제는 다음과 같이 해결할 수 있습니다:

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

    • TLS 핸드셰이크 동안 SNI 필드

    • 도메인 이름이 DNS 쿼리와 대응에서 학습되는 DNS 해석

  • 방화벽 규칙에서 지정된 도메인이 모든 출처에 걸쳐 일관되게 유지되는 것이 중요합니다. 참고로 방화벽 이벤트에서는 최상단부터 하단까지 평가된 최상위 일치 도메인 이름만 도메인 이름으로 표시됩니다. 

  • SSH 또는 SMB 등의 기타 프로토콜에 대해, 도메인을 일반 텍스트로 보내지 않을 경우, Cato는 트래픽을 도메인 또는 정규화된 도메인 이름(FQDN)과 연결하기 위해 DNS 인터셉션에만 의존합니다. 이는 사설 DNS를 사용하는 경우 DNS 쿼리/응답이 Cato를 통과하는지 확인해야 하기 때문에 특히 중요합니다. DNS 및 Cato 계정에 대한 최적의 관행을 참조하세요
  • 도메인 이름/애플리케이션 일치를 위해서는 DoH(HTTPS를 통한 DNS)와 TLS를 통한 DNS가 지원되지 않으므로, DNS 쿼리를 UDP/53으로 이동시키기 위해 방화벽 규칙에서 차단되어야 합니다.

DNS 전달 문제 해결

DNS 쿼리가 다음 DNS 서버로 향할 때만 DNS 전달을 사용할 수 있습니다:

  • Cato의 기본 DNS 서버 10.254.254.1
  • 네트워크 > DNS 설정에서 구성된 계정 수준 DNS 서버
  • 8.8.8.8, 1.1.1.1, 그리고 9.9.9.9와 같은 잘 알려진 DNS 서버. 잘 알려진 DNS 서버의 목록은 PoP 간에 다를 수 있습니다. 예시로, 중국과 시드니입니다.

DNS 전달을 위해서는 DoH(HTTPS를 통한 DNS)와 TLS를 통한 DNS가 지원되지 않으므로, DNS 쿼리를 UDP/53으로 이동시키기 위해 방화벽 규칙에서 차단되어야 합니다. 이 솔루션은 macOS, iOS, Android의 SDP 클라이언트에 특히 적용됩니다.

 

Cato 지원에 문제 제기

위의 문제 해결 단계를 설명한 지원 티켓을 제출하세요. 티켓에 다음 정보를 포함시켜주세요:

  • 경험한 문제의 상세 정보 및 사용자에 대한 전체 영향력을 기재하세요.
  • 관련된 방화벽 이벤트 및 방화벽 규칙 구성을 포함하세요.
  • 문제를 재현하고 지원 자가 서비스를 실행하십시오. 툴에서 생성된 티켓 번호를 포함하세요.
  • 영향을 받은 사용자가 SDP 클라이언트를 사용하여 Cato에 연결하는 경우, SDP 클라이언트를 사용하여 문제를 기록하십시오
  •  

도움이 되었습니까?

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

댓글 0개