소켓 사이트 터널 연결 문제 해결

개요

사이트 연결은 소켓 뒤의 호스트가 카토 클라우드를 통해 WAN에 액세스할 수 있도록 하는 데 매우 중요합니다． 사이트의 연결이 없으면 비즈니스 기능이 중단될 수 있습니다． 이 대본은 이 시나리오를 해결하기 위한 지침을 제공하는 것을 목표로 합니다．

증상

소켓 연결의 실패는 여러 가지 방식으로 나타날 수 있습니다． 관리자는 다음과 같은 증상을 주목할 수 있습니다：

• 사이트가 CMA에서 연결해제됨 
• 사이트가 예기치 않은 PoP에 연결됨
  
• 네트워크 분석은 터널이 불안정하다는 것을 보여줍니다

가능한 원인

다음은 문제 해결 중에 식별할 수 있는 가능한 원인입니다

• 소켓 연결 없음
  
• 단방향 DTLS 트래픽만
  
• 불량한 언더레이 성능
  
• IP 지리적 위치 제한
• 부적절한 PoP 선택 설정
• 잘못된 기준선의 SLA 설정
• 소켓 앞의 NAT 장치

문제 해결

관리자가 겪을 수 있는 증상을 해결하기 위한 단계는 아래에 나열되어 있습니다． 이 단계는 직면한 문제의 가능한 원인을 식별하는 데 목적이 있습니다． 해결 단계는 이후의 대본에서 강조될 것입니다．

CMA에서 사이트 연결 해제 문제 해결

이벤트에서 정보 수집

CMA의 홈페이지 > 이벤트 페이지를 사용하여 관리자는 계정 내 사이트의 연결성 이벤트 기록을 빠르게 가져올 수 있습니다． 이벤트는 '사이트 연결 상태' 프리셋을 선택하거나 이벤트 유형 '연결성' 및 하위 유형 '연결 해제됨'을 필터링하여 관련 이벤트로 필터링할 수 있습니다 '출처 사이트' 필드로 문제 사이트의 이름을 추가로 필터링할 수 있습니다．

문제 사이트에서 관련 연결 해제 이벤트의 타임스탬프를 확인하면 조사를 집중하는 데 도움이 될 수 있습니다． 이 타임스탬프에 더 넓은 네트워크 이벤트나 로컬 전력 이벤트가 발생한 것으로 알려졌습니까？ 감사 추적에서 이와 상관관계가 있을 수 있는 변경사항이 이전에 있었나요？

소켓 연결성 검사

소켓 연결 요구 사항을 이해하기 위해 Cato Socket 연결 사전 요구사항을 참조하십시오．

소켓의 연결 상태는 해당 로컬 소켓 웹UI를 통해 확인할 수 있습니다, 로컬에서 소켓 웹UI 로그인을 참조하십시오． 소켓을 연결하려면 Cato 클라우드에 대한 연결을 서비스하는데 사용되는 WAN 포트가 녹색 상태 아이콘을 표시해야 합니다. 녹색이 아닌 표시기는 연결 문제를 의미합니다． 다른 상태 아이콘 색상의 의미는 링크 상태 아이콘 이해하기에서 설명되어 있습니다

빨간색 아이콘의 경우, 소켓과 ISP 장치 사이에 작동하는 물리적 연결이 있는지 확인하십시오． 이는 케이블이 안전하게 연결되어 있으며 포트 LED가 예상대로 켜지는 것을 포함합니다．

IP 충돌은 소켓 연결 상태에 의해 또한 감지됩니다． IP 충돌 경고는 이 KB 문서에서 설명된 대로 충돌이 처음 감지된 시점부터 24시간 동안 계속 표시됩니다．

도구 아래의 인터넷 우회를 통한 강제 복구 상태가 일반인지 확인하십시오． '우회 강제' 버튼을 누르면 모든 LAN 트래픽이 Cato를 우회하도록 강제하고, Cato 터널이 끊어지며, 사이트가 CMA에서 연결 해제됨으로 표시됩니다． 따라서, 모든 원격 구성 및 이 장치에 대한 액세스가 실패합니다. HA 설정에서 기본 소켓이 '강제 우회'로 활성화된 경우, 보조 소켓은 백업 소켓으로 남아 있으며, 소켓 뒤의 트래픽은 인터넷으로 라우팅됩니다.

아래 스크린샷은 기본 소켓에서 '강제 우회'가 활성화되고 보조 소켓은 대기 상태로 유지되는 것을 보여줍니다. 

강제 복구 상태가 활성화된 경우, 강제 우회 종료 버튼을 클릭하여 이 상태에서 벗어나십시오.

연결 문제 발생 시, 도구 탭을 사용하여 추가 테스트를 진행할 수 있습니다． Cato와 연결하려면, 소켓은 Cato의 공공 IP 주소에 대한 L3 접근 권한이 필요합니다． Ping 도구를 사용하여 이 소켓이 WAN 포트를 통해 Cato IP 주소 또는 도메인, 혹은 8.8.8.8 같은 잘 알려진 IP 도달 가능한 주소에 직접 도달할 수 있는지 확인하십시오． 아무것도 도달할 수 없는 경우에는 소켓 연결 없음 해결 섹션을 참조하십시오．

패킷 캡처 실행 중

PoP에 DTLS 터널을 설정하기 위한 소켓의 요청이 응답되는지 확인하기 위해 패킷 캡처를 수행할 수도 있습니다. 관련 WAN 포트에서 캡처할 때, PoP로의 UDP/443 양방향 패킷이 보여야 합니다. 다음 스크린샷은 성공적인 DTLS 핸드셰이크와 애플리케이션 데이터 패킷 교환을 보여줍니다.

오직 아웃바운드 DTLS 패킷만 감지되거나 DTLS 핸드셰이크가 불완전한 경우, 불완전한 DTLS 핸드셰이크 해결을 참조하십시오. 

소켓 앞의 NAT 장치로 인해 터널을 설정할 수 없음

WAN 링크를 여러 개 사용하는 소켓의 경우, 소켓과 PoP 사이에 NAT 장치가 있으면 하나 이상의 WAN 링크가 PoP에 연결할 수 없을 가능성이 있습니다. 이는 사이트의 HA 상태가 준비되지 않음과 같은 연결 문제를 일으킬 수 있습니다.

PoP는 각 들어오는 DTLS 연결의 소스 포트를 사용하여 각 WAN 링크를 동일한 논리적 터널에 연결합니다. NAT 장치는 소스 포트를 변경할 수 있으며, 다른 WAN 링크와 동일한 논리적 터널에 WAN 링크가 연결되는 것을 방지할 수 있습니다.

LTE/5G 공급업체와의 DTLS 연결 실패

이 사례 연구에서 언급했듯이, Cato에 연결하기 위해 LTE/5G 공급업체를 사용하는 경우, ISP가 포트 UDP/443에서의 DTLS 핸드셰이크를 방해할 수 있으며, 이는 핸드셰이크 과정 중에 특정 데이터(예: APN)로 나타날 수 있습니다.

양방향 DTLS 통신이 존재함에도 불구하고, 핸드셰이크가 완료되지 않아 Cato 터널이 설정되지 않습니다. 

이 문제를 해결하려면 DTLS 포트를 UDP/1337로 변경하십시오. 불완전한 DTLS 핸드셰이크 해결를 참조하세요. 

예기치 않은 PoP 선택 문제 해결

ISP의 IP 주소와 현재 선택된 PoP 확인

모니터링에서 사이트를 선택하고 사이트의 개요 창을 엽니다. 사이트 소켓 섹션에서 '로그 보기'를 클릭하여 모든 최근 연결을 확인합니다. Cato에 연결하는 ISP의 공인 IP(원격 IP)와 ISP 이름 및 위치를 찾으십시오. 'PoP' 열은 사이트가 연결된 현재 PoP를 표시합니다.

'원격 IP'와 ISP 위치가 예상대로인지 확인하고, ISP가 예기치 않은 위치를 통해 연결을 백홀링하지 않는지 확인하는 것이 중요합니다. ISP 위치(도시)는 CMA 내 사이트의 일반 설정에서 지정된 국가/도시와 일치하거나 가까워야 합니다.

CMA에서 PoP 선택 구성 확인

사이트에서 오래되거나 잘못 구성된 PoP 선호 위치는 비최적의 PoP로 연결을 강요할 수 있습니다. 네트워크 > 사이트 > 사이트 설정 > 일반 페이지를 통해 사이트별로 PoP 선택 구성을 볼 수 있습니다.

여기 구성된 위치가 최적의 연결에 적합하지 않거나 Cato PoP 선택 메커니즘이 최적의 PoP를 결정하도록 허용하는 것이 더 좋다면, 부적절한 PoP 선택 구성 해결 섹션을 참조하십시오.

소켓에서 PoP 선택 구성 확인 

오래되거나 적합하지 않은 PoP 선택 구성은 소켓 구성에서도 있을 수 있습니다. 이 경우인지 확인하려면 소켓의 웹UI에서 클라우드 연결 설정으로 이동하십시오. 소켓 웹UI 사용을 참조하세요.

여기에 구성이 존재하고 Cato PoP 선택 메커니즘이 최적의 PoP를 결정하도록 허용하는 것이 좋다면, 부적절한 PoP 선택 구성 해결 섹션을 참조하십시오.

PoP 상태 확인

가장 가까운 지리적 PoP가 유지보수 또는 기타 문제로 인해 영향을 받을 수 있어 소켓이 예상치 못한 PoP에 연결될 수 있습니다. PoP 상태 페이지를 통해 이러한 경우인지 확인해 보십시오. 

지리적 위치에 대한 위치 제약 확인

Cato MSA에 따르면 일부 지리적 위치의 소켓 사이트는 다른 위치의 PoP에 연결이 제한됩니다. MSA는 Cato 서비스를 구매할 때 개략적으로 설명됩니다.

일부 지리적 위치의 소켓 사이트는 사용 가능한 PoP의 풀에 제한되며，예를 들어 중국의 소켓 사이트는 중국 내 PoP에 연결되고，베트남의 소켓 사이트는 아시아 내 PoP 풀에 연결됩니다．

이에 대한 자세한 내용은 MSA를 참조하십시오．

PoP 간 소켓 이동 징후 확인

이벤트 페이지를 사용하여 연결 문제로 인해 소켓이 처음 결정된 최적의 PoP에 있지 않을 가능성을 확인할 수 있습니다． 필드 선택을 사용하여 소켓의 다양한 PoP 연결 타임라인을 봅니다．

'사이트 재연결' 이벤트 프리셋을 사용하고 문제의 사이트로 추가 필터링하며 'event_message' 필드 값을 '성능 문제 감지, Cato Cloud의 다른 서비스 노드로 재연결'로 설정하면 터널 연결 매개변수가 구성된 SLA 임계값을 초과하여 소켓 사이트가 PoP을 이동한 모든 사례를 볼 수 있습니다． 소켓 사이트가 여러 PoP에 대한 SLA 임계값을 위반하는 경우, 문제가 해결될 때까지 문제 해결 흐름을 계속해서 연결 SLA 설정을 확인하십시오．

연결 SLA가 너무 엄격하지 않은지 확인

연결 SLA 는 특히 ISP 인터넷 연결과 같은 공용 언더레이가 있는 동적 네트워크 환경에서 사이트가 최적의 PoP에 연결되도록 보장하는 데 중요한 역할을 합니다． 그러나 연결 SLA가 너무 엄격하면 관리자가 선호하는 위치 외의 다른 PoP로 불필요한 재연결을 발생시킬 수 있습니다．

사이트별 연결 SLA 구성은 네트워크 > 사이트 > 사이트 설정 > 연결 SLA에서 확인할 수 있습니다．

네트워크 분석을 사용하여 최종 구간 성능 메트릭의 기준선을 작성하고, 해당 메트릭이 해당 사이트에 적합한지 고려하십시오．

이 매개변수가 적합하지 않은 경우, 잘못된 기준설정에서 SLA 구성을 해결하는 방법을 참조하십시오

매개변수가 적합하지만 여전히 여러 PoP에서 PoP 재최적화 이벤트가 정기적으로 발생하면 열악한 언더레이 성능 해결 섹션을 확인하십시오．

위의 단계를 따라도 소켓이 여전히 부적절한 PoP에 연결된 경우，지원 티켓을 열고 현재 및 예상 PoP를 강조하십시오．

불안정한 터널 문제 해결

최종 구간과 사이트 연결 성능 간의 상관 관계 확인

주어진 사이트가 PoP에 연결 성능이 낮다는 것을 알게 되었을 때，이러한 패킷 손실이 기본적인 ISP 라인의 성능 때문인지 파악하는 것이 중요합니다．

이 작업은 주어진 성능 문제를 일정 시간 동안 최종 구간 내에서 관찰된 성능과 일치시키고 패턴을 찾는 방법으로 수행할 수 있습니다．

이를 수행하는 데 네트워크 분석을 사용할 수 있습니다．

위의 예는 사이트 터널에 대한 PoP으로의 상향 패킷 손실을 보여줍니다． 우리는 여러 개의 ~10% 스파이크와 전체 기간 동안 일정한 낮은 패킷 손실률을 볼 수 있습니다．

같은 기간 동안 최종 구간 성능을 비교할 때 다음을 확인할 수 있습니다：

최종 구간에서 성능에 약간의 변동을 볼 수 있지만 약 ~10-20%의 일정한 패킷 손실이 확인됩니다． 이로부터 소켓에서 Cato PoP까지의 터널에서의 패킷 손실이 기본적인 성능 부족의 징후일 가능성이 높다는 것을 알 수 있습니다.

이에 따라 성능 문제를 해결할 때 열악한 언더레이 성능 해결을 참조하십시오.

유사한 사이트 간의 교차 참조

사이트 간 공유 속성은 특정 문제에 대한 사실을 추론하는 시도로 사용될 수 있습니다. 예를 들어, 아래의 사이트가 연결성 문제를 겪고 있습니다. 참고로 연결된 PoP는 런던입니다：

이 정보는 런던에 연결된 다른 사이트와 교차 참고하여 문제를 공유하고 있는지 확인하는 데 사용할 수 있습니다． 이는 아래 스크린샷에서 확인할 수 있습니다：

교차 참고가 문제의 원인이 Cato PoP에 있다고 제시하면, PoP 상태 확인 섹션을 확인하세요．

교차 참고는 또한 공유 ISP를 가진 사이트에서도 유용합니다． 이는 아래 예시에서 수행됩니다：

이 교차 참고가 ISP가 연결 문제를 겪고 있음을 암시한다면, 열악한 배경 성능 해결 섹션을 참조하세요．

연결 SLA가 너무 관대하지 않은지 확인하기

연결 SLA 는 특히 ISP 인터넷 연결과 같은 공용 언더레이가 있는 동적 네트워크 환경에서 사이트가 최적의 PoP에 연결되도록 보장하는 데 중요한 역할을 합니다． 그러나 연결 SLA가 과도하게 관대하다면, 소켓이 PoP에 대한 비최적 연결을 관리자 의도보다 오래 유지하게 되어 민감한 애플리케이션에 영향을 미칠 수 있습니다．

사이트별 연결 SLA 설정은 네트워크 > 사이트 > 사이트 설정 > 연결 SLA에서 확인할 수 있습니다．

네트워크 분석을 사용하여 최종 구간 성능 지표의 기준선을 구축하고, 이러한 SLA 메트릭이 이 사이트에 적합한지 고려하십시오．

이 파라미터가 적합하지 않다면, 잘못된 기준선에서 SLA 구성 해결을 참조하십시오．

발견된 문제 해결

소켓 연결성 문제 해결

연결성 문제가 소켓에만 영향을 미치는지 격리하는 것이 중요합니다． 같은 ISP 연결에 랩톱을 연결하면 DNS 해상도 문제나 주소를 핑할 때 동일한 문제가 발생합니까？ 그렇다면, 문제를 진행시키기 위해 ISP에 연락하세요．

테스트 랩톱에서 IPv6을 비활성화하고, 정적 IP 주소 할당 시 테스트할 때 소켓과 동일한 IP를 할당하십시오．

연결성 문제가 소켓에 제한된다면, WebUI의 네트워크 설정 탭에서 IP 설정이 올바른지 확인하십시오：

불완전한 DTLS 핸드셰이크 해결

공급업체에게 UDP 포트 443의 DTLS 트래픽이 인터넷으로 송신될 수 있도록 허용되어 있는지 확인하십시오． 필요한 경우 이 포트를 Cato PoP에 연결할 다른 포트 설정에 설명된 대로 UDP/1337로 변경할 수 있습니다．

열악한 배경 성능 해결

열악한 배경 성능은 그 배경에서 구축된 모든 터널에 영향을 미칩니다． 비록 배경은 ISP의 영역이지만, 성능 문제가 도입되는 위치를 식별하고 가능하다면 성능 문제를 완화하려는 몇 가지 도구가 있습니다．

소켓의 WebUI에는 ISP 연결을 통해 공개적으로 접근 가능한 호스트에 핑을 보낼 수 있는 트레이스라우트 도구가 있습니다． 공개적으로 접근 가능한 호스트명을 핑할 때, 소켓과 서비스 사이의 l3 경로에서 손실이나 과도한 지연이 발생하는 홉을 확인할 수 있습니다.

위의 예시에서, 패킷 손실은 명확히 ISP가 제공하는 L3 경계로부터 직접 발생하고 있습니다.

궁극적으로는 모든 배경 문제를 ISP에 제출해야 하지만, CMA의 설정이 정확한지 확인하면 성능 문제의 영향을 완화하는 데 도움을 줄 것입니다. 소켓 인터페이스의 대역폭 구성이 라인이 제공하는 대역폭에 대해 정확한지 확인하세요. 소켓 웹UI 속도 테스트 도구는 연결을 벤치마크할 수 있습니다． 또한, 연결의 버스트성 매개변수를 줄이면 Cato가 더 빨리 QoS 엔진을 작동시킬 수 있으며, 더 중요한 애플리케이션을 위해 우선순위가 낮은 트래픽을 드롭할 수 있습니다． 

부적절한 PoP 선택 구성 해결

수동 PoP 선택 구성을 되돌리고 Cato가 소켓 연결에 최적의 PoP를 선택하도록 허용하려면, 먼저 CMA에서 수동 PoP 위치 구성이 없는지 확인한 후 소켓에서도 동일하게 수행합니다．

CMA에서는 네트워크 > 사이트 > 일반 > 선호하는 PoP 위치에서 이 작업을 수행할 수 있습니다．

'자동'이 선택되었는지 확인하십시오．

소켓 웹UI에서 클라우드 연결 설정으로 이동합니다．

목적지가 'Steering'으로 설정되었는지 확인하십시오．

잘못된 기준선에서의 SLA 구성 해결

SLA 구성이 적절한지 확인하는 첫 번째 단계는 사이트에서 사용하는 중요한 애플리케이션의 임계값이나 요구사항을 이해하는 것입니다．

이를 위해 두 가지 예시를 고려하십시오．

• 애플리케이션 A는 낮은 수준의 패킷 손실에 관대하며 패킷 재정렬 능력이 우수하지만, 서비스가 작동하려면 세션이 유지되어야 합니다． 흐름을 중단하고 재생성하면 애플리케이션 내에 문제가 발생합니다．
• 애플리케이션 B는 간헐적인 패킷 손실에 매우 민감합니다． 심지어 낮은 수준의 손실도 데이터 전송을 중단시킬 수 있으며 전송은 처음부터 다시 시작해야 할 수 있습니다． 어쨌든, 제어 채널은 세션 종료 및 재연결에 매우 강력합니다．

애플리케이션 A의 프로필을 사용할 경우, 우리는 장기간의 시간창에서도 낮은 수준의 손실을 허용하는 SLA 구성을 생성할 것입니다． 손실이 서비스에 영향을 미치더라도 세션 유지를 위해 PoP와의 연결을 유지하는 것이 더 중요합니다．

대조적으로, 애플리케이션 B는 더 엄격한 SLA 구성이 필요합니다． 전송의 무결성을 보호하기 위해서는 소량의 패킷 손실이 감지되면 PoP를 이동하는 것이 좋습니다．

사이트는 분명히 다른 프로필과 요구사항을 가진 애플리케이션들을 혼합하여 사용합니다． 관리자는 적절한 SLA 정책을 위해 이러한 요구를 전략적으로 균형 있게 다루어야 합니다． 

Cato 지원에 요청 제기

이 플레이북을 따르더라도 문제가 해결되지 않는 경우, 지원 티켓을 제출하십시오． 요청에 대한 가장 유용한 대응을 받으려면 관리자는 이 플레이북을 사용하는 동안 수행한 문제 해결 단계의 결과를 제공해야 합니다． 예를 들어 포함되는 사례들：

• 특정 이벤트에 주목하기 위한 관련 필터．
• 웹UI 테스트의 결과．
• 네트워크 분석 결과．
• SLA 구성 요구사항．