GCP HA VPN malakceptas FortiGate: malsama tipo de loka ID
Google komparas la identecon, kiun FortiGate asertas, ne nur la antaŭe dividitan ŝlosilon. Loka ID de tipo FQDN malsukcesas tiun kontrolon dum la protokolo ankoraŭ diras aŭtentigo.
AUTHENTICATION_FAILED de Google Cloud HA VPN kutime sendas homojn reen al la antaŭe dividita ŝlosilo, kaj la ŝlosilo normale estas ĝusta. La tunelo haltas en fazo 1 ĉar Google komparas ankaŭ ion alian: la identecon, kiun la kunulo asertas dum la IKE-interŝanĝo. Sur FortiGate tiu identeco povas ŝanĝi tipon sen ke iu redaktu adreson. Legu la protokolon kiel malkongruon de identeco post kiam la ŝlosilo estis reenmetita dufoje.
Unu fiasko, du kontroloj
IKE kontrolas kunulon en du apartaj paŝoj. La antaŭe dividita ŝlosilo pruvas, ke ambaŭ flankoj havas la saman sekreton, kaj asertita identeco diras al la respondanto, kiu la kunulo pretendas esti. Google kontrolas tiun identecon kontraŭ la kunulo, kun kiu ĝi estis agordita. Lasita sola, FortiGate sendas adres-bazitan identecon derivitan de sia elira interfaco, kaj la komparo pasas sen ke iu rimarkas.
Ambaŭ paŝoj falas en la saman korbon en la protokolo, kio klarigas la konatan buklon de retajpado de la ŝlosilo kvar fojojn antaŭ ol iu legas la identecan utilŝarĝon.
Kion FortiGate metas en la identecan utilŝarĝon
La problemo komenciĝas kiam iu agordas lokan ID por ke la du flankoj konsentu. Lastatempaj FortiOS-konstruoj markas tiun identecon kiel plene kvalifikitan domajnan nomon eĉ kiam la entajpita valoro estas adreso kun punktoj. Google do ricevas identecon de tipo FQDN dum ĝi atendas adreson, kaj ĝi rifuzas la seancon. Nenio en la mesaĝo diras, kiu duono malsukcesis, do la raporto legiĝas kiel fiasko de aŭtentigo.
Reproduktu ĝin unufoje kun IKE-sensalutigo ŝaltita kaj legu la identecan utilŝarĝon, kiun la fajroŝirmilo efektive elsendas.
En la sama paŝo, konfirmu tri malmultekostajn faktojn: la IKE-version, kiun uzas ambaŭ flankoj, la precizan ŝlosilon inkluzive de nevideblaj finaj signoj, kaj la kunulan adreson, kiun Google atendas. Ili respondas al malsamaj demandoj, kaj kongrua ŝlosilo diras nenion pri la identeco.
Opcioj kaj kion ĉiu kostas
Ĉiu eliro riparas malsaman tavolon, kaj neniu el ili estas disponebla por ĉiu deplojo.
| Option | When it works | What it costs |
|---|---|---|
| Set an address identity on the firewall | Your firmware lets you choose the type | Behaviour you must retest per release |
| Put a public address on the negotiating interface | The firewall can hold a routable address | Not possible behind NAT |
| Terminate on a peer that accepts your identity | Another endpoint validates what you produce | A topology change |
Korekti la identecon sur la fajroŝirmilo estas la plej pura respondo, kie la firmaro lasas vin elekti la tipon kaj konservi la valoron. La kampo ekzistas en iuj konstruoj kaj plenigas la tipon malĝuste en aliaj, do testu vian version anstataŭ fidi la eldonnotojn.
Enirebla publika adreso sur la intertraktanta interfaco estas la dokumentita provizora solvo, ĉar tiam la defaŭlta identeco kongruas kun tio, kion Google atendas, kaj neniu anstataŭigo necesas. Tie finiĝas la plej multaj deplojoj, se la fajroŝirmilo entute povas teni tian adreson.
Fini sur kunulo, kiu validigas tion, kion vi produktas, estas ŝanĝo de topologio. Traktu ĝin kiel dezajnan decidon, ne kiel provizoran solvon kun pli afabla priskribo.
Kiam NAT forigas unu opcion
Malantaŭ NAT la eliro per publika adreso malaperas, kaj tio, kio restas, dependas de firmara konduto, kiun vi ne regas. Tio estas la punkto por konscie elekti inter ĝisdatigo, translokigo de la kunulo aŭ akcepto de alia nuba finpunkto. Tiuj estas tri malsamaj buĝetoj, kaj elekti unu hazarde estas kiel provizora solvo fariĝas arkitekturo. Skribu la elekton kaj ĝian kialon apud la tunelo.
Antaŭ ol interpreti ion ajn el tio, konfirmu la staton de la tunelo ĉe la Google-flanko kaj ke IKE simple ne estas forĵetata survoje. Forĵetita paketo tempas; ĝi ne produktas malakcepton.
Kion noti dum ĝi funkcias
Notu la tipon de identeco, ĝian valoron, la firmaran version kaj la kunulan adreson, kiuj validis kiam la tunelo laste ekfunkciis. Firmara ĝisdatigo povas denove ŝanĝi la defaŭlton, kaj la sekva fiasko aspektos ekzakte kiel malkongruo de ŝlosilo. Kun la identeco konservita apud la ŝlosilo kaj la kunula adreso, la sekva persono komencas per la malmultekostaj kontroloj.
Tiu registro ankaŭ estas la sola maniero scii, ĉu provizora solvo ankoraŭ necesas post la sekva ĝisdatigo.