Cloud VPN 상태: IKE 로그보다 리소스 상태를 먼저 읽기

Cloud VPN 터널은 두 개의 수명 주기를 동시에 돌리며, 두 주기는 같은 시계 위에 있지 않습니다. 리소스는 협상을 하기 전에 먼저 할당되고 구성되어야 하며, 그다음에 프로토콜의 IKE 메시지 순서가 따릅니다. 상태 필드는 첫 번째를 보고하면서 두 번째에 대해 유용한 것을 말하지 않을 수 있습니다. 둘을 하나로 읽는 것이 바로 키 불일치가 프로비저닝 지연의 책임을 뒤집어쓰는 방식입니다.

터널 객체 하나와 시간 창 하나로 시작하십시오.

두 개의 수명 주기, 하나의 터널 객체

리소스 수명 주기는 공급자가 터널을 준비하는 단계입니다. 주소, 구성, 용량이 포함됩니다. 프로토콜 수명 주기는 양쪽 피어가 IKE_SA_INIT, 그다음 IKE_AUTH, 그다음 자식 보안 연관을 교환할 만큼의 구성을 갖추면 시작됩니다. 아직 첫 단계에 있는 터널은 인증에 실패한 것이 아니라, 인증을 아직 시도하지 않은 것입니다.

그 구분이 문제의 전부입니다. 나머지는 무관한 메시지를 섞지 않고 그것을 관찰하는 방법입니다.

콘솔 요약이 아니라 객체를 읽으십시오

API에는 중요한 두 필드만 묻고 다른 것은 묻지 마십시오. 그래야 응답이 새벽 세 시에 읽을 수 있을 만큼 작게 유지됩니다: gcloud compute vpn-tunnels describe NAME --region REGION --format="yaml(status,detailedStatus)". status 필드는 수명 주기의 단계를 나타내고, detailedStatus는 그에 붙은 읽을 수 있는 이유를 담습니다. 전체 구성 덤프는 다른 질문에 답하며 티켓에 붙이기가 더 어렵습니다. 이런 읽기 전용 호출은 터널을 바꿀 수 없으며, 사고가 진행 중일 때 이 점이 중요합니다.

호출의 시각을 값 옆에 기록하십시오. 두 필드 모두 움직이기 때문입니다.

ALLOCATING_RESOURCES는 키 불일치가 아닙니다

터널이 ALLOCATING_RESOURCES를 보고할 때 공급자는 아직 객체를 조립하고 있습니다. 그 단계에서는 미리 공유된 키의 불일치를 관찰할 수 없고, 차단된 피어 포트도 마찬가지로 입증되지 않았습니다. 확인할 수 있는 것은 상세 메시지, 프로젝트와 서비스가 건강해 보이는지, 그리고 피어와 연락할 수 있을 만큼 터널 구성이 충분히 완전한지입니다. 지금 비밀을 교체하는 것은 한 번도 시험되지 않은 값을 바꾸는 일입니다.

구성에 대해 결론을 내리기 전에 상태가 움직이기를 기다리십시오.

ESTABLISHED는 액세스 점검의 시작입니다

터널이 성립되었다는 것은 IKE가 끝났다는 뜻이지 트래픽이 흐른다는 뜻이 아닙니다. 터널이 운반하는 경로를 확인하고, Cloud Router가 관련된 경우 BGP 세션과 그것이 학습한 프리픽스를 확인하십시오. 그다음 허용된 애플리케이션 교환을 시험하십시오. 방화벽 규칙이나 빠진 경로가 완전히 건강한 터널을 통한 트래픽을 막을 수 있기 때문입니다. 각각은 별개의 관찰이고 별개의 수정입니다.

상태는 다음에 어떤 질문을 해야 하는지 알려 줍니다. 상태가 대신 액세스 질문에 답해 주는 일은 없습니다.

하나의 객체와 하나의 시간 창을 연결하십시오

로그에 있는 오래된 인증 실패는 그 시각이 조사 중인 시간 창 안에 들어가지 않는 한 이전 시도의 것입니다. 기록한 상태와 같은 분에 대한 터널 리소스의 로그를 가져오고, 식별자를 함께 보관하십시오. 나중의 IKE 이벤트는 협상이 시작되었음을 보여 줄 수 있지만, 바라보고 있는 콘솔 메시지는 이미 낡은 것일 수 있습니다.

무엇이든 수집하기 전에 터널이 복구되었다면 그렇게 말하십시오. 원인 미정이라는 기록이 무관한 줄을 짜 맞춘 자신감 있는 이야기보다 낫습니다.

다음 단계는 언제나 같은 모양입니다. 하나의 객체, 하나의 창, 하나의 단계. 그보다 넓은 것은 요약이지 진단이 아닙니다.