필요한 것은 다음과 같습니다.
고정 1:1 NAT 뒤의 Fortigate 장치를 인터넷의 Google Cloud Platform(GCP) VPN 게이트웨이에 연결합니다.
단순화된 ASCII 다이어그램:
LOCAL_LAN ---- Fortigate ----- Fiber modem ---- Internet ---- GCP VPN Gateway ----- GCP_VPC
Fiber 모뎀은 Fortigate에 NAT 1:1을 수행하고 있으며 이 모뎀에서는 DMZ 모드가 호출됩니다.
나는 몇 가지 지침을 따랐습니다.
GCP에서 외부 게이트웨이에 대한 VPN을 만드는 방법 - Fortigate에 공개 IP가 하나만 있으므로 사용 사례 #3입니다. https://cloud.google.com/network-connectivity/docs/vpn/how-to/creating-ha-vpn#gcloud_4
Fortinet과의 상호 운용성 - Fortigate의 인터페이스당 하나씩, 2개의 고정 IP가 없습니다. https://cloud.google.com/community/tutorials/using-ha-vpn-with-fortigate
IKE v1의 결과:
1단계는 협상됐는데, 문제는 2단계는 전혀 거론되지 않는다는 점이다. Google의 문제해결 가이드:
https://cloud.google.com/network-connectivity/docs/vpn/support/troubleshooting
내용: 터널을 가져오려면 피어 ID를 공용 IP로 정의해야 합니다.
이상한 점은 FortiGate Phase 1 localid 매개변수에 공용 IP를 정의했고 이것이 GCP VPN 게이트웨이로 올바르게 전송된다는 것입니다.
아래와 같이 GCP 로그에 확인된 이벤트입니다!
{
insertId: "5abgbbg2313tdw"
labels: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:14:46.610751733Z"
resource: {2}
severity: "DEBUG"
**textPayload: "IDir '201.110.XXX.240' does not match to '201.110.XXX.240'"**
timestamp: "2021-09-01T21:14:46.592461252Z"
}
하지만 문제는 2단계가 GCP 측에서 결코 협상되지 않고 터널이 삭제된다는 것입니다. 문서화 목적으로 Fortigate의 ike 디버그 로그에 대한 출력은 다음과 같습니다.
ike 0:gcp00-0:10752: processed INITIAL-CONTACT
ike 0:gcp00-0: schedule auto-negotiate
ike 0:gcp00-0:10752: no pending Quick-Mode negotiations
[...]
ike 0:gcp00-0:10751: recv ISAKMP SA delete 14cb5d60541aaaaa/d405bbbbf6d06acb
그런 다음 ISAKMP 연결 해제가 GCP 로그에서 일치됩니다.
{
insertId: "5abgbbg2313tdx"
labels: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:14:46.610751733Z"
resource: {2}
severity: "NOTICE"
textPayload: "deleting IKE_SA vpn_201.110.XXX.240[2662] between 35.242.XXX.165[35.242.XXX.165]...201.110.XXX.240[%any]"
timestamp: "2021-09-01T21:14:46.592502955Z"
}
협상은 무한 루프에서 이 상태로 유지됩니다.
IKE v2로 테스트합니다.
IKE v2에서도 시도해 보았는데 결과는 꽤 비슷했습니다. 터널은 결코 연결되지 않습니다. 유일한 차이점은 FGT 측에서는 공개 IP를 GCP VPN 게이트웨이로 보낼 수 없다는 것입니다. IKEv2에서 localid, local-gw 및 eap 매개변수를 수정하려고 시도했지만 성공하지 못했습니다. GPC 관점의 로그는 AUTHENTICATION_FAILED입니다. PSK 인증이 완료되었지만 피어가 제대로 식별되지 않으므로 표시되지 않습니다. FGT의 local-gw 매개변수를 Fortigate 앞 모뎀의 공용 IP로 정의하면 협상 자체가 전혀 완료될 수 없습니다. 이유: FGT Phase1-인터페이스 gw에서 이 매개변수를 설정할 때 Fortigate는 local-gw 정의 IP의 SOURCE IP를 사용하여 패킷을 보냅니다. 이 IP는 모뎀에 유효하지 않으므로 패킷이 전송되지 않습니다.
테스트를 위해 ike v1과 ike v2에 하나씩 총 2개의 터널을 만들었다는 점에 유의하는 것이 중요합니다. 이로 인해 다음 터널의 IP가 다릅니다. 다음은 GCP 콘솔의 증거 로그입니다.
{
insertId: "134hqnjg23gnfib"
labels: {1}
logName: "projects/my-project-name-xxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:52:39.566968571Z"
resource: {2}
severity: "DEBUG"
textPayload: "looking for peer configs matching 35.220.XXX.31[%any]...201.110.XXX.240[201.110.XXX.240]"
timestamp: "2021-09-01T21:52:39.552310603Z"
}
{
insertId: "134hqnjg23gnfia"
labels: {1}
logName: "projects/my-project-xxxxxx/logs/cloud.googleapis.com%2Fipsec_events"
receiveTimestamp: "2021-09-01T21:52:39.566968571Z"
resource: {2}
severity: "DEBUG"
textPayload: "parsed IKE_AUTH request 1 [ IDi N(INIT_CONTACT) AUTH N(MSG_ID_SYN_SUP) SA TSi TSr ]"
timestamp: "2021-09-01T21:52:39.552287263Z"
}
질문
IP가 올바른데도 ike v1에서 GCP VPN 게이트웨이가 터널 설정(2단계)을 거부하는 이유를 아는 사람이 있나요?
Fortigate의 1단계 정의에서 IKE v2 IDi 또는 IDr을 설정하는 방법을 아는 사람이 있습니까?
전에 이 문제를 본 사람이 있나요? 어떤 제안이 있으십니까?
답변1
글쎄, 내 자신의 질문에 대답합니다. 여기 간다:
FortiOS 7.0.1에서는 ForiGate가 1:1 NAT를 수행하는 NAT 장치로 작동할 때 GCP가 설정을 위해 허용하는 방식으로 FortiGate에서 1단계 정의의 IDi 또는 IDr을 정의하는 문서화되거나 명시적인 방법이 없습니다. 터널.
FGT와 GCP VPN 게이트웨이 사이에 VPN 터널을 설정하는 유일한 방법은 FortiGate가 GCP VPN에 연결하는 인터페이스에 공용 IP를 직접 할당하도록 하는 것입니다.
이렇게 하면 FGT 1단계 정의의 공용 IP인 인터페이스에 "로컬 gw" IP를 정의할 수 있습니다. 이로써 터널 협상이 완료되고 VPN이 작동합니다.
요약하자면, FGT가 NAT 장치 뒤에 있을 때 FGT-GCP VPN 터널을 설정하려고 시도하지 마십시오. 전혀 작동하지 않습니다!
이는 IKE v2를 사용하여 FortiGate의 단일 공개 IP와 GCP VPN 측의 두 개의 IP를 사용하여 GCP VPN 중복 게이트웨이에 연결하는 FortiOS 7.0.1에서 테스트되었습니다. IKE v1은 테스트되지 않았습니다.