GCP HA VPN weier FortiGate: plaaslike ID se tipe stem nie ooreen nie

’n AUTHENTICATION_FAILED van Google Cloud HA VPN stuur mense gewoonlik terug na die vooraf gedeelde sleutel, en die sleutel is gewoonlik korrek. Die tonnel stop in fase 1 omdat Google ook iets anders vergelyk: die identiteit wat die eweknie tydens die IKE-uitruiling beweer. Op ’n FortiGate kan daardie identiteit van tipe verander sonder dat iemand ’n adres wysig. Lees die log as ’n identiteitsbotsing sodra die sleutel twee keer weer ingevoer is.

Een fout, twee kontroles

IKE verifieer ’n eweknie in twee afsonderlike stappe. Die vooraf gedeelde sleutel bewys dat beide kante dieselfde geheim het, en ’n beweerde identiteit sê vir die ontvanger wie die eweknie voorgee om te wees. Google vergelyk daardie identiteit met die eweknie waarmee dit opgestel is. Word dit alleen gelaat, stuur ’n FortiGate ’n adresgebaseerde identiteit wat van sy uitgaande koppelvlak afgelei is, en die vergelyking slaag sonder dat iemand agterkom dit het gebeur.

Beide stappe beland in dieselfde bak in die log, wat die bekende lus verduidelik waarin die sleutel vier keer weer ingetik word voordat iemand die identiteitslading lees.

Wat ’n FortiGate in die identiteitslading sit

Die moeilikheid begin wanneer iemand ’n plaaslike ID instel om die twee kante te laat ooreenstem. Onlangse FortiOS-bouwe merk daardie identiteit as ’n ten volle gekwalifiseerde domeinnaam, selfs wanneer die waarde wat ingetik is ’n adres met punte is. Google ontvang dus ’n FQDN-identiteit terwyl dit ’n adres verwag, en dit weier die sessie. Niks in die boodskap sê watter helfte gefaal het nie, so die verslag lees as ’n verifikasiefout.

Reproduseer dit een keer met IKE-ontfouting aangeskakel en lees die identiteitslading wat die firewall werklik uitstuur.

In dieselfde pas, bevestig drie goedkoop feite: die IKE-weergawe wat beide kante gebruik, die presiese sleutel insluitend onsigbare sleepkarakters, en die eweknie-adres wat Google verwag. Hulle beantwoord aparte vrae, en ’n passende sleutel sê niks oor die identiteit.

Opsies, en wat elkeen kos

Elke uitweg herstel ’n ander laag, en nie een daarvan is vir elke ontplooiing beskikbaar nie.

Die identiteit op die firewall regstel is die skoonste antwoord waar die firmware jou die tipe laat kies en die waarde laat behou. Die veld bestaan in sommige bouwe en vul die tipe verkeerd in ander, so toets jou weergawe eerder as om op vrystellingsnotas te vertrou.

’n Routeerbare openbare adres op die onderhandelende koppelvlak is die gedokumenteerde oplossing, want die verstekidentiteit pas dan by wat Google verwag en geen oorskrywing is nodig nie. Dit is waar die meeste ontplooiings beland, as die firewall so ’n adres hoegenaamd kan hou.

Om op ’n eweknie te termineer wat valideer wat jy produseer, is ’n topologieverandering. Behandel dit as ’n ontwerpbesluit eerder as ’n oplossing met ’n vriendeliker beskrywing.

Wanneer NAT een opsie wegneem

Agter NAT verdwyn die openbare-adres-uitweg, en wat oorbly hang af van firmwaregedrag wat jy nie beheer nie. Dit is die punt om doelbewus te kies tussen opgradeer, die eweknie verskuif, of ’n ander wolkeindpunt aanvaar. Dit is drie verskillende begrotings, en om een per ongeluk te kies is hoe ’n tydelike oplossing in argitektuur verander. Skryf die keuse en sy rede langs die tonnel.

Voordat jy enigiets hiervan interpreteer, bevestig die tonneltoestand aan die Google-kant en dat IKE nie bloot onderweg laat val word nie. ’n Gevalle pakkie verloop; dit lewer nie ’n verwerping nie.

Wat om te teken terwyl dit werk

Teken die identiteitstipe, sy waarde, die firmwareweergawe en die eweknie-adres aan wat van krag was toe die tonnel laas opgekom het. ’n Firmware-opdatering kan die verstek weer verander, en die volgende fout sal presies soos ’n sleutelbotsing lyk. Met die identiteit langs die sleutel en die eweknie-adres gestoor, begin die volgende persoon by die goedkoop kontroles.

Daardie rekord is ook die enigste manier om te weet of ’n oplossing ná die volgende opgradering steeds nodig is.