IPsec 사이트 연결 문제 해결

개요

연결성은 IPsec 뒤의 네트워크가 Cato 클라우드를 통해 WAN에 액세스하기 위해 매우 중요합니다． IPsec 사이트의 연결 부족은 비즈니스 기능을 방해할 수 있습니다． 이 연습 지침서는 이 시나리오에서 문제 해결을 안내하는 것을 목표로 합니다．

증상

IPsec 연결의 실패는 다음과 같은 방법으로 파악할 수 있습니다． 관리자가 다음 증상을 주목할 수 있습니다：

IPsec 사이트가 CMA에서 연결 해제됨
연결 불안정성의 역사
IPsec 연결을 통과하는 트래픽의 성능 저하

가능한 원인

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

피어 연결성
- 이는 피어 간의 L3 언더레이에서 일관되게 연결할 수 있는 능력을 포함합니다．
IPsec 구성 불일치
- 변환 세트나 인증 불일치는 터널이 전혀 형성되지 않거나 키 재설정이 완료되기 전에 실패하게 할 수 있습니다
언더레이 성능
- IPsec는 터널 내부의 만족스러운 성능을 위해 안정적인 언더레이 연결에 의존합니다．

문제를 해결하기

관리자가 직면할 수 있는 증상을 해결하기 위한 단계는 아래에 나열되어 있습니다． 이러한 단계는 직면한 문제의 가능한 원인을 식별하기 위한 것입니다． 해결 단계는 연습 지침서 후반부에 강조될 것입니다．

CMA에서 IPsec 사이트 연결 해제 또는 불안정 문제 해결

이벤트에서 정보 수집

CMA의 홈 페이지 > 이벤트 페이지를 사용하여 관리자는 계정 내 IPsec 사이트의 연결성 이벤트 기록을 빠르게 얻을 수 있습니다． 이벤트는 '사이트 연결 상태' 프리셋을 선택하거나 이벤트 유형 '연결성'과 하위 유형 '연결 해제됨'을 필터링하여 관련 이벤트로 필터링할 수 있습니다． 또한 '출처 사이트' 필드를 사용하여 문제의 사이트 이름으로 필터링하거나 터널 프로토콜 값 'IPSEC'을 사용하여 모든 IPsec 사이트를 필터링할 수 있습니다．

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

연결 해제 이벤트가 발견되지 않고 터널이 여전히 불안정하다고 보고되면, Cato와 원격 피어 사이의 매개변수 불일치로 인해 키 재설정 프로세스 시 문제가 발생할 가능성이 있습니다． 더 나은 분석을 위해 아래 단계들을 계속 진행하십시오．

사이트 IPsec 연결 기록 보기

중요: 이 파일이 CMA에서 사용 가능하지 않으면 (파일을 찾을 수 없음) 원격 피어와 단계 1 (또는 IKEv2에서 IKE_SA)가 협상되지 않은 것을 의미합니다. IKE 및 인증 매개변수가 두 피어 간에 일치하는지 확인하십시오．

네트워크 > 사이트 > 사이트 설정 > IPsec 에 제공된 타임라인은 연결 해제된 IPsec 사이트 문제 해결에 필수적입니다．

타임라인 버튼에 의해 제공된 CSV 파일은 관련 터널 로그의 역사를 제공합니다． 이 로그는 IPsec 연결의 연결성 부족을 초래할 수 있는 문제를 명확히 나타내 줄 수 있습니다． 대표적인 메시지 예시는 다음과 같습니다：

트래픽 선택기가 일치하지 않음을 나타내는 메시지는 2단계 설정 간의 구성 불일치를 증명하는 것으로, IPsec 피어링의 양측에서 사용 가능한 서브넷에 관련됩니다． 이 경우로 보여지는 오류가 보이면, IPsec 구성 불일치 해결로 이동하십시오．

위의 메시지는 인증 페이로드의 경우에도 구성 불일치가 있음을 나타냅니다. 물론, 사전 공유 키는 연결이 성공하려면 이러한 페이로드와 일치해야 합니다． 이러한 내용이 어떠한 연결 시도에서도 명백하다면, IPsec 구성 불일치 해결로 이동하십시오．

위의 타임라인은 구성된 피어와의 연결 시도를 표시하며, 응답을 받지 못했습니다． 이 타임라인에서는 피어와의 상호작용이 없었고, 비활성으로 인해 SA가 종료되었음을 볼 수 있습니다． 이는 일반적으로 원격 피어에 대한 L3 도달성이 없을 때 발생합니다． 이러한 경우에는 피어 연결성 해결을 참조하세요．

IKEv1 및 IKEv2에 대한 가능한 타임라인 오류 메시지의 전체 목록은 여기에서 찾을 수 있습니다．

패킷 캡처를 사용하여 문제 해결하기

참고: 패킷 캡처를 수행할 때 터널에 대해 구성한 PoP IP는 10.x.y.z 내부 IP 뒤로 추상화됩니다.

또한 네트워크 > 사이트 > 사이트 설정 > IPsec 페이지에서 패킷 캡처 도구를 사용할 수 있습니다. 이는 피어 간의 제어 트래픽에 대한 패킷 트레이스를 제공합니다. 위에서 강조된 문제는 이 패킷 캡처에서도 나타납니다.

TS_UNACCEPTABLE

변환 세트 내에서 서브넷이 불일치하는 경우, 정보 제공 패킷은 오류를 통지합니다. 이 IKEv2 예제에서는 구성 내 변환 세트 불일치의 상징적인 증상으로 정보 메시지인 TS_UNACCEPTABLE이 나타납니다. 이 문제를 해결하려면 IPsec 구성 불일치 해소하기로 이동하십시오.

NO_PROPOSAL_CHOSEN

보안 연결 내 매개변수가 일치하지 않는 경우, 피어의 페이로드에 오류가 포함됩니다． 이 IKEv2 예제에서, 오류 NO-PROPOSAL-CHOSEN은 CMA에 구성된 알고리즘이나 DH 그룹이 원격 피어의 구성과 일치하지 않음을 명확히 나타냅니다． 이것은 터널의 초기 설정이나 재키 프로세스 동안 발생할 수 있습니다．

AUTHENTICATION_FAILED

아래 캡처는 또 다른 IKEv2 예제를 보여주며, 이번에는 인증에 사용된 PSK가 일치하지 않는 경우입니다.

원웨이 패킷

패킷 캡처는 또한 피어와의 IP 수준에서 연결 문제를 식별하는 데 도움이 될 수 있습니다． 아래 예에서, 패킷 캡처는 단방향의 아웃바운드 트래픽만을 보여주며, 이는 피어가 도달할 수 없음을 암시합니다． 문제 해결 관리자가 도달할 수 없는 피어를 보면, 피어 연결성 해결로 이동하십시오．

IKEv1이나 IKEv2에서 피어 간의 구성 불일치를 나타내는 위의 예제 또는 다른 지표들 중 어느 것이든 있는 경우, IPsec 구성 불일치 해결로 이동하십시오．

VPN에서의 열악한 성능 문제 해결

VPN에서 성능이 열악한 경우, 이는 일반적으로 패킷 손실, 높은 지연 시간, 또는 빈번한 연결 끊어짐의 형태로 나타납니다．

터널을 통과하는 트래픽에서 패킷 손실이 나타나며, 이것이 영향을 미치는 애플리케이션을 통해 확인될 수 있고, IPsec 연결을 통해 한 호스트에서 다른 호스트로 ICMP 프로브로 테스트하여 확인할 수 있습니다．

지연 시간과 터널 연결 끊김도 애플리케이션 성능에서 분명히 드러나며, 해당 사이트의 네트워크 > 사이트 모니터링 > 네트워크 분석 페이지를 통해서도 알 수 있습니다.

성능 문제가 발견되면, 언더레이 성능 해결로 이동하십시오.

Azure IPSec에서의 패킷 삭제

Azure와 IPSec을 설정할 때, 터널 처리량과 초당 패킷 수 (PPS)는 VPN 게이트웨이의 SKU와 사용된 암호화 알고리즘에 따라 결정됩니다. 예를 들어, Microsoft의 문서에 따르면, VpnGw3 Generation2 게이트웨이는 GCMAES256을 사용 시 최대 140,000 PPS까지 처리할 수 있습니다.

트래픽이 이러한 임계값을 초과하면 Azure는 자동으로 초과 패킷을 삭제하여 성능 저하를 일으킬 수 있습니다． 일반적인 증상 중 하나는 처리량 감소이며, 이는 CMA의 네트워크 분석에서 트래픽 볼륨 감소로 나타날 수 있습니다． 그러나, 이를 진단하는 더 정확한 방법은 Azure 포털 내에서 VPN 게이트웨이 메트릭을 직접 모니터링하는 것이며, 이는 영향을 받은 VPN 연결에 대한 터널 처리량 및 PPS 값에 대한 실시간 인사이트를 제공합니다．

이 문제를 완화하려면 더 높은 IPSec SKU로 업그레이드하거나 Azure vSocket을 배포하는 것을 고려하십시오. 둘 다 VPN 터널의 용량을 향상시키고 트래픽 과부하로 인한 패킷 손실을 방지할 수 있습니다．

문제 해결

피어 연결성 해결

IPsec 피어가 타임라인 항목이나 패킷 캡처를 통해 PoP에 패킷을 보내지 않는 시나리오에서는, 원격 피어가 CMA에 할당된 터널과 동일한 IP 주소로 연결되도록 구성되었는지 확인하십시오．

이 구성이 확인되면, 원격 피어가 NAT에 의해 제한된 연결을 포트 4500과 포트 500에서의 트래픽에 응답하여 통과할 수 있는지 확인하십시오． NAT Traversal (NAT-T)을 원격 피어에서 활성화해야 합니다．

원격 피어 장치가 인터넷을 통해 ICMP 요청에 응답하도록 구성된 경우, 장치의 공인 IP에 ICMP 요청을 테스트하여 전반적인 접근 가능성을 테스트할 수도 있습니다．

최근 상태 페이지의 건강 상태 변경 사항을 확인하십시오 - PoP에 문제가 있는 경우 IPsec 터널에 영향이 있을 수 있습니다(각 터널은 하나의 Cato PoP 위치에 연결됩니다)． 상태 페이지에서 Cato PoP 건강 상태를 모니터링할 수 있습니다．

원격 피어가 Azure 또는 AWS와 같은 클라우드 벤더라면 그들의 상태 페이지도 확인할 수 있습니다．

피어 장치가 이 IPSec 연결에 대해 여전히 도달할 수 없는 경우, 관리자에게 연락하여 IPSec 연결에 대해 공개적으로 접근 가능하도록 보장하십시오．

IPsec 구성 불일치 해결

변환 세트의 피어 구성과 사이트 > IPsec 페이지에서 구성의 일치를 확인하십시오.

피어의 특정 변환 집합과 일치하도록 Cato 피어링 측을 구성하려면, IKEv1 및 IKEv2에 대한 연결된 문서에 설명된 대로 구성을 편집하십시오．

터널 양쪽의 IP 범위 (선택자)는 일치해야 합니다. CMA에서, IP 범위를 다음과 같이 구성하는지 확인하십시오:

로컬 IP 범위 (피어 측): 사이트 설정 > 네트워크로 이동하여 IPsec 피어 뒤의 서브넷을 정의하십시오 (예: 방화벽 또는 라우터).
원격 IP 범위 (Cato 측): 사이트 설정 > IPSec > 라우팅으로 이동하여 터널을 통해 전달되는 로컬 IP 범위를 정의하십시오 (일반적으로 다른 사이트의 네트워크). 이 필드가 구성되지 않은 경우, 터널은 암시적 선택자 0.0.0.0 <> 0.0.0.0의 경로 기반 VPN으로 간주됩니다.

일부 벤더는 변환 집합에 포함된 모든 서브넷이 단일 변환 집합 메시지에만 포함되도록 요구합니다． 피어가 이런 경우라면, 관리자는 사이트 > 고급 구성 아래의 'IKEv2 각 페이로드마다 단일 TS 보내기' 고급 구성 옵션을 활용해야 합니다．

기저 성능 문제 해결

기저 성능을 해결하는 초점은 원격 피어에 대한 성능을 고립하는 것입니다．

원격 피어의 공용 웹 서버 8.8.8.8에 대한 핑 능력을 테스트하십시오． 지연이나 패킷 손실이 터널과 일관된다면, 문제는 원격 피어의 환경 내에 존재한다고 결론지을 수 있습니다．

Cato 지원에 케이스 제기

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

타임라인 항목 및 타임스탬프
관련 패킷 캡처
일치하는 변환 집합 확인, 서브넷 관련 및 인증/암호화 매개변수 포함