이 문서에서는 Cato Cloud와의 연결 문제의 가능성이 매우 낮은 경우에 복원력을 제공하는 소켓 사이트용 WAN 복구 기능에 대해 설명합니다.
WAN 복구 기능은 소켓 사이트가 Cato Cloud를 사용할 수 없는 경우 복원력을 제공하는 여러 복구 옵션 중 하나입니다. WAN 복구는 소켓 사이트 간 인터넷을 통한 VPN 터널을 사용하여 Cato Cloud와의 연결 문제 시 사이트 간의 WAN 트래픽 연결성을 유지합니다.
WAN 복구는 풀 메쉬 토폴로지를 기반으로 하며 모든 소켓 사이트에 기본적으로 활성화되어 있습니다. 각 소켓은 공용 인터넷을 통해 다른 모든 소켓과 직접 DTLS 터널을 생성합니다. 정기적으로 터널을 통해 유지 메시지를 보내고 복구 시간을 줄이기 위해 열린 라이브 터널을 유지합니다. 이 토폴로지는 계정의 소켓 사이트에 최대한의 복원력을 제공합니다.
다음 다이어그램은 하나의 소켓이 Cato Cloud와 연결이 끊어진 예를 보여줍니다. 이 사이트에 대해 두 소켓 간의 직접 연결을 제공하기 위해 WAN 복구가 활성화되어 있습니다.
WAN 복구는 Cato Cloud의 회복력 및 사이트 연결성 유지를 위한 중요한 구성 요소입니다. 추가 정보는 다음 비디오를 참조하십시오.
사이트에 대한 원활한 전환을 보장하기 위해, 사이트에 대해 정적 IP를 사용하고 소켓 인터페이스의 공용 IP 및 정적 포트 설정을 정의하여 사이트 간 오프클라우드 터널 수립을 개선할 수 있습니다.
모든 소켓에 대해 정적 IP 설정을 구성하기 어려운 계정의 경우, 데이터 센터와 같은 WAN 복구의 허브 역할을 하는 몇 가지 주요 사이트에 대해 정적 IP 설정을 사용하는 것이 좋습니다. 허브 사이트의 IP 주소가 PoP에 전송되어 WAN 복구가 구성된 계정의 다른 소켓으로 전파됩니다.
WAN 복구를 위한 풀 메시 토폴로지는 주로 소규모 및 중간 배포에 적합하지만, 이 행동은 불필요한 트래픽을 발생시키고 대규모 환경에서 CPU 부하를 증가시킵니다. 이러한 환경에서는 허브 & 스포크 토폴로지로 전환하여 터널 및 프로브 수를 줄이고 최적의 성능과 효율성을 유지할 수 있습니다. 더 많은 정보를 보려면 WAN 복구를 위한 허브 & 스포크 Off-Cloud 토폴로지를 참조하십시오.
소켓은 WAN 복구를 위해 열린 터널을 유지하므로 Cato Cloud와의 연결이 끊어지면 소켓은 다른 사이트와 연결을 복구하고 연결 끊김 시간을 최소화합니다. 그 후 소켓은 즉시 WAN 복구 링크로 WAN 트래픽 전송을 시작합니다.
카토 관리 애플리케이션(CMA)을 사용하여 특정 사이트 또는 전체 계정에 대해 WAN 복구를 비활성화할 수 있습니다. 자세한 내용은 계정에 대한 고급 구성 작업을 참조하십시오.
카토 클라우드에 대한 연결이 복원되면 복구가 종료되고 트래픽이 카토 클라우드를 통해 전송됩니다.
데이터 센터와 같은 WAN 복구의 허브 역할을 하는 주요 사이트에 대해 정적 IP 주소를 사용하는 것이 좋습니다. 허브 사이트의 각 WAN 링크에 대해 오프클라우드 공용 IP 및 정적 포트를 정의하십시오.
모든 사이트가 WAN 복구를 지원하도록 고급 구성 설정에서 활성화되었는지 확인하려면 모범 사례 페이지를 사용할 수 있습니다.
WAN 복구를 위한 사이트 구성 방법:
-
네비게이션 메뉴에서 Network > Sites을 선택하고 사이트를 선택합니다.
-
네비게이션 메뉴에서 Site Configuration > Socket을 선택합니다.
-
WAN 복구를 위한 WAN 링크 구성:
-
WAN 링크를 클릭합니다. 소켓 인터페이스 편집 패널이 열립니다.
-
Traffic Status를 Enabled으로 설정합니다.
-
(선택 사항) 링크에 대한 정적 공용 IP 및 정적 포트를 정의합니다.
모범 사례: 주요 허브 사이트에 이 설정을 구성할 것을 추천합니다.
-
-
모든 Socket WAN 링크에 대해 3단계를 반복합니다.
-
적용을 클릭한 다음 저장을 클릭합니다.
사이트가 WAN 복구용으로 구성됩니다.
WAN 복구 이벤트는 소켓이 Cato Cloud 대신 인터넷을 통해 DTLS 터널을 사용하여 다른 사이트로 트래픽을 전송할 때 생성됩니다. WAN 복구에 대해 CMA에서 다음 이벤트가 표시됩니다:
-
오프 클라우드 복구 활성화 - Socket이 WAN 복구 수송을 통해 WAN 트래픽을 전송하기 시작하면 이 이벤트가 생성됩니다.
-
클라우드 외부 복구 중지 - 연결이 Cato Cloud로 복원되면 이 이벤트가 생성되고, 소켓은 WAN 복구 전송을 통해 WAN 트래픽을 보내는 것을 중지합니다.
사이트가 WAN 복구를 위해 작동 중일 경우 (상태는 준비 완료), 트래픽을 복구 DTLS 터널을 통해 보내지 않는 경우 이벤트가 생성되지 않습니다.
CMA는 소켓 사이트의 WAN 복구 준비 상태를 파악할 수 있도록 제공합니다. WAN 복구를 방해하는 문제가 있는 사이트를 사전에 식별하고 WAN 탄력성을 유지하기 위한 수정 작업을 수행할 수 있습니다.
모범 사례: WAN 인터페이스 각각에 정적 또는 동적 IP 주소를 구성하여 안정적인 터널 감지와 정확한 상태 보고를 보장합니다.
WAN 복구를 네트워크 > 사이트 페이지의 WAN 복구 터널 열에서 모니터링할 수 있습니다. 각 사이트의 실시간 상태는 WAN 복구를 위한 WAN 링크 준비 상태를 나타냅니다:
-
Ready (X/X): 이 사이트는 WAN 복구를 위한 것이며 모든 Socket 사이트와 연결되어 있습니다.
-
부분적 (X/Y): 사이트가 WAN 복구에 부분적으로 준비되었습니다 (즉, 16/20은 이 사이트가 WAN 복구를 위해 20개 사이트 중 16개와 연결됨을 의미합니다)
-
Not Ready (0/Y): 이 사이트는 WAN 복구 준비가 되어 있지 않으며, Socket 사이트와 연결되어 있지 않습니다. 이 사이트는 Cato Cloud에 장애가 발생하면 WAN 연결을 잃게 됩니다.
모든 사이트에 대한 WAN 복구 상태를 검토하려면:
-
탐색 메뉴에서 네트워크 > 사이트를 선택하고, WAN 복구 터널 열에서 상태를 검토하십시오.
특정 사이트에 대한 상태를 다음 페이지에서 볼 수 있습니다:
-
Home > Topology로 이동하여 사이트를 선택합니다.
-
Site Configuration > {site name} > Socket
-
사이트가 부분 준비 또는 준비 안됨 상태를 나타내면, 완전한 복구 준비 상태를 복원하기 위해 다음 단계를 수행하십시오:
-
WAN 인터페이스 설정 확인: 각 WAN 인터페이스가 유효한 정적 또는 동적 IP 주소를 갖고 있으며 WAN 링크가 운영 중인지 확인합니다.
-
터널 설정 확인: CMA 또는 Socket WebUI를 활용해 오프 클라우드 터널이 원격 사이트와 생성 및 유지 되는지 확인합니다.
-
로컬 네트워크 문제 해결: 가능한 원인을 조사합니다:
-
인바운드/아웃바운드 방화벽 규칙이 트래픽을 차단합니다.
-
잘못된 NAT 동작 혹은 포트 제한
-
라우팅 구성 오류
-
-
모범 사례 적용: 가능한 경우 터널 안정성과 상태 정확성을 높이기 위해 중요한 사이트 (예: 데이터 센터 또는 허브)에 정적 WAN IP를 설정합니다.
모든 소켓 사이트에 대한 WAN 복구는 오프클라우드 트래픽을 사용하여 복원력을 제공하기 위해 기본적으로 활성화되어 있으며, 사용하지 않도록 설정된 경우에는 서로 통신할 수 없습니다. 예를 들어, 사이트 A와 B에 WAN 복구가 활성화되어 있지만 사이트 C에 대해서는 활성화되어 있지 않은 경우, 복구하는 동안 사이트 C는 다른 사이트와 통신할 수 없으며, 사이트 A와 B는 사이트 C와 통신할 수 없습니다.
LAN 방화벽 정책은 WAN 복구 중 영향을 받지 않고 소켓이 정책을 적용하기 때문에 정상적으로 작동을 계속합니다.
WAN 복구 중에 소켓을 재부팅하지 않도록 하십시오. 그렇지 않으면 사이트에 부정적인 영향이 있을 수 있으며 다른 사이트와의 연결을 재설정하지 못할 수 있습니다.
모든 배포에서 WAN 복구가 활성화되면 각 소켓은 오프클라우드 트래픽에 대해 활성화된 모든 WAN 인터페이스에 대해 원격 소켓 사이트로의 안전한 DTLS 터널을 설정합니다. 활성/활성 링크 구성의 경우 소켓은 WAN 복구를 위해 활성 링크 중 하나를 무작위로 선택합니다. 활성/수동의 경우 소켓은 활성 링크를 사용합니다.
Cato 관리 애플리케이션(CMA)은 PoP에 연결되어 있지 않아 영향을 받은 사이트의 상태를 인식하지 못하므로 모든 사이트 데이터를 수신하지 않습니다.
소켓 WebUI에 로그인하여 SD-WAN 탭을 사용해 트래픽과 오프 클라우드 터널을 모니터링할 수 있습니다. 소켓 WebUI를 사용하여 트래픽을 모니터링하는 예시입니다.
WAN 복구 중에는 소켓 라우팅 테이블이 고정되므로, 복구 시작 전에 존재하던 모든 BGP 범위가 다른 사이트로의 오프클라우드 트래픽을 통해 라우팅 가능합니다. WAN 복구 시작 후 도입된 BGP 범위는 소켓이 복구를 종료하고 PoP와 재연결될 때까지 도달할 수 없습니다.
WAN 복구 오프클라우드 전송을 통해 전달되는 트래픽은 Cato Cloud의 PoP에 의해 처리되지 않습니다. 이것은 다음과 같은 항목을 포함하여 WAN 복구 중에는 PoP 서비스가 트래픽에 적용되지 않음을 의미합니다:
-
보안
-
WAN 및 인터넷 방화벽 정책
-
위협 방지 서비스 (예: IPS, Anti-Malware)
-
Managed XDR 서비스
-
-
네트워킹
-
NAT 정책
-
복잡한 네트워크 규칙
-
DNS 포워딩
-
DHCP 릴레이
-
정적 범위 변환 (SRT)
-
-
액세스
-
클라이언트 액세스 (예: 클라이언트 연결 정책)
-
장치 상태
-
복구를 위한 대체 WAN 링크 를 활성화하는 계정에 대해 WAN (예: MPLS)이 사용 중입니다. 소켓이 Cato Cloud에서 연결이 끊어진 경우, 대체 WAN 링크는 WAN 복구보다 우선순위가 높습니다. 따라서 소켓은 먼저 트래픽을 대체로 이동합니다. WAN 링크. 대체 WAN 링크가 사용 가능하지 않은 경우 소켓은 WAN 트래픽을 WAN 복구 링크로 이동합니다.
WAN 복구는 사이트 간 WAN 연결을 수립하기 위해 NAT 펀칭에 의존합니다. 소켓이 카토 클라우드에 연결되면 PoP가 소켓에 다른 모든 엔드포인트를 알려주고 소켓은 각 엔드포인트에 DTLS 터널을 엽니다. 소켓은 다른 소켓과의 직접 연결을 수립하기 위해 NAT 펀칭 기술을 사용합니다.
참고: NAT 펀칭의 협상은 Cato Cloud를 통해 시작됩니다. 따라서 소켓은 NAT 펀칭을 허용하기 위해 Cato Cloud에 연결되어 있어야 합니다.
다음 다이어그램은 두 소켓 간의 직접 연결을 WAN 복구용으로 수립하는 흐름을 보여줍니다:
NAT 펀칭 기술은 다음과 같이 각 소켓 쌍에서 작동합니다:
-
PoP는 사이트 ID를 기반으로 직접 연결을 설정하기 위해 Sockets 중 하나를 발신자로 선택합니다 (높은 ID 값을 가진 사이트가 발신자가 됩니다).
-
발신자 Socket은 IP 주소 및 포트 번호에 대한 다음 세부 정보를 Cato Cloud에 요청합니다. 예를 들어, IP 주소 82.128.1.1 및 포트 번호 4444 (Step #2)
-
Cato PoP는 소스 IP 주소와 포트를 Socket 1로 전송합니다.
-
Socket 1은 IP 주소와 포트를 Cato 터널을 통해 Socket 2로 전송합니다.
-
Socket 2는 IP 주소 및 포트에 대한 다음 세부 정보를 Cato Cloud에 요청합니다.
-
Cato PoP는 소스 IP 주소와 포트를 Socket 2로 전송합니다.
-
Socket 2는 IP 주소와 포트를 Cato 터널을 통해 Socket 1로 전송합니다.
-
Socket 1은 소스 포트 범위에서 Socket 2로 각각 다른 포트 번호를 가진 32개의 패킷을 전송합니다.
-
Socket 2는 소스 포트 범위에서 Socket 1로 각각 다른 포트 번호를 가진 32개의 패킷을 전송합니다.
-
올바른 포트가 발견되면 소켓은 소스 IP 주소와 포트 번호로 DTLS 터널을 엽니다
소켓 2가 소켓 1과 연결될 때, 라우터는 NAT 항목을 라우팅 테이블에 추가합니다.
-
그 이후로, Sockets는 연결을 유지하기 위해 15초마다 계속 메시지를 보냅니다.
댓글 0개
댓글을 남기려면 로그인하세요.