GCP HA VPN, FortiGate 거부: 로컬 ID 유형 불일치

Google Cloud HA VPN의 AUTHENTICATION_FAILED는 보통 사람들을 사전 공유 키로 돌려보내지만, 그 키는 대개 맞습니다. 터널이 1단계에서 멈추는 이유는 Google이 IKE 교환 중 피어가 주장하는 ID도 함께 비교하기 때문입니다. FortiGate에서는 아무도 주소를 편집하지 않았는데 그 ID의 유형이 바뀔 수 있습니다. 키를 두 번 다시 입력했다면 로그를 ID 불일치로 읽으십시오.

하나의 실패, 두 가지 검사

IKE는 피어를 두 개의 별도 단계에서 검증합니다. 사전 공유 키는 양쪽이 같은 비밀을 가졌음을 증명하고, 주장된 ID는 응답자에게 피어가 자신을 누구라고 하는지 알려줍니다. Google은 그 ID를 설정된 피어와 대조합니다. 그대로 두면 FortiGate는 나가는 인터페이스에서 파생된 주소 기반 ID를 보내고, 아무도 눈치채지 못한 채 비교가 통과됩니다.

두 단계 모두 로그에서 같은 버킷에 들어가며, 이는 누군가 ID 페이로드를 읽기 전에 키를 네 번 다시 입력하는 익숙한 순환을 설명합니다.

FortiGate가 ID 페이로드에 넣는 것

문제는 누군가 양쪽을 맞추려고 로컬 ID 를 설정할 때 시작됩니다. 최근 FortiOS 빌드는 입력한 값이 점이 있는 주소여도 그 ID를 정규화된 도메인 이름으로 표시합니다. 그래서 Google은 주소를 기대하는데 FQDN ID를 받고 세션을 거부합니다. 메시지에는 어느 쪽이 실패했는지 없으므로 보고서는 인증 실패로 읽힙니다.

IKE 디버깅을 켜고 한 번 재현한 뒤 방화벽이 실제로 내보내는 ID 페이로드를 읽으십시오.

같은 과정에서 양쪽이 쓰는 IKE 버전, 보이지 않는 끝 문자까지 포함한 정확한 키, Google이 기대하는 피어 주소라는 세 가지 저렴한 사실을 확인하십시오. 이것들은 서로 다른 질문에 답하며, 키가 맞는다고 해서 ID에 대해 알려주는 것은 없습니다.

선택지와 각각의 비용

각 출구는 다른 계층을 고치며, 어느 것도 모든 배포에 쓸 수 있는 것은 아닙니다.

방화벽에서 ID를 고치는 것이 가장 깔끔한 답이며, 펌웨어가 유형을 고르고 값을 유지하게 해 줄 때 가능합니다. 이 필드는 일부 빌드에 있고 다른 빌드에서는 유형을 잘못 채우므로, 릴리스 노트를 믿지 말고 자신의 버전에서 시험하십시오.

협상 인터페이스에 라우팅 가능한 공인 주소를 두는 것이 문서화된 우회 방법이며, 그러면 기본 ID가 Google이 기대하는 것과 맞고 재정의가 필요 없습니다. 방화벽이 그런 주소를 아예 가질 수 있다면 대부분의 배포가 여기서 끝납니다.

당신이 만드는 것을 검증하는 피어에서 종료하는 것은 토폴로지 변경입니다. 더 친절한 설명이 붙은 우회 방법이 아니라 설계 결정으로 다루십시오.

NAT가 한 가지 선택지를 없앨 때

NAT 뒤에서는 공인 주소 출구가 사라지고, 남는 것은 당신이 통제하지 못하는 펌웨어 동작에 달려 있습니다. 이 지점에서 업그레이드, 피어 이전, 다른 클라우드 엔드포인트 수용 중 하나를 의식적으로 골라야 합니다. 이는 세 가지 다른 예산이며, 하나를 우연히 고르는 것이 임시 우회를 아키텍처로 바꾸는 방식입니다. 선택과 그 이유를 터널 옆에 적으십시오.

이것을 해석하기 전에 Google 쪽 터널 상태와 IKE가 단순히 도중에 버려지고 있지 않은지 확인하십시오. 버려진 패킷은 시간 초과로 끝나며 거부를 만들지 않습니다.

작동하는 동안 기록할 것

터널이 마지막으로 올라왔을 때 유효했던 ID 유형, 그 값, 펌웨어 버전, 피어 주소를 기록하십시오. 펌웨어 업데이트는 기본값을 다시 바꿀 수 있고, 다음 실패는 정확히 키 불일치처럼 보일 것입니다. ID를 키와 피어 주소 옆에 저장해 두면 다음 사람은 저렴한 검사부터 시작합니다.

그 기록은 다음 업그레이드 후에도 우회 방법이 필요한지 아는 유일한 방법입니다.